Back
[07:08:54] <KGB-linuxcnc> 03Robert W. Ellenberg 05feature/reverse-run-master2 bef8d9d 06linuxcnc 10src/emc/tp/tc.c 10src/emc/tp/tp.c tp: partial revert of target calculation changes (had it right the first time) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bef8d9d
[10:42:51] <seb_kuzminsky> rtai 5.0-test1 was officially released:
http://mail.rtai.org/pipermail/rtai/2015-December/027021.html
[10:49:50] <Roguish> seb: is it good?
[10:50:03] <Roguish> shall we test it?
[11:24:34] <jepler> a new go AI "darkfores1" wins 62% of games played against players ranked 3d (only 29 matches at that ranking so far at time of publication though)
http://arxiv.org/pdf/1511.06410v1.pdf
[11:32:28] <jepler> seb_kuzminsky: what would the procedure be if we wanted to put a binary package from snapshot.debian.org on linuxcnc.org's package server? (the debian jessie rt kernel image)
[11:32:43] <jepler> can we just copy files or do we rebuild it nmu-style?
[14:31:20] <skunkworks> zlog
[15:31:58] <seb_kuzminsky> jepler: we could do either
[15:32:15] <seb_kuzminsky> the rtai kernel-building infrastructure we have would lend itself well to building rt-preempt kernels too, i think
[15:32:52] <seb_kuzminsky> but just copying the debs should work fine too
[16:33:29] <jepler> hm
[16:33:45] <jepler> in a way just copying seems like a good idea, because it means we know we didn't introduce bugs ourselves
[16:33:56] <jepler> but then we have to be sure we copy the right stuff
[16:35:19] <jepler> http://snapshot.debian.org/package/linux-latest/67~bpo8%2B1/
[16:35:57] <jepler> or is that just metapackage stuff
[16:37:24] <jepler> http://snapshot.debian.org/package/linux/4.1.3-1/
[16:38:12] <jepler> but without a "changes" file you can't dput it
[16:39:05] <jepler> so yeah I guess we'd want to feed our packaging infrastructure those source packages
[16:41:08] <jepler> or just instruct users to use snapshot.debian.org
[16:49:30] <jepler> I'll test instructions based on using snapshot.debian.org and see how that works out
[16:57:04] <seb_kuzminsky> cool, that sounds like a good idea
[16:57:30] <seb_kuzminsky> if later we decide we want our users to have a newer rt-preempt kernel, we can always build from source then
[17:20:57] <skunkworks> the last push from rob in the reverse run rebase seems to have fixed the last problem I was seeing
[17:32:34] <jepler> skunkworks: I appreciate you testing all the branches that you do
[18:21:47] <skunkworks> I really only test the ones that are interesting to me... Sorry. I still haven't tested the m98/99 branch.
[18:48:32] <seb_kuzminsky> heh
[18:49:26] <seb_kuzminsky> skunkworks: that's perfectly ok, as far as i'm concerned - we're just lucky that the things that interest you benefit us all
[19:35:23] <seb_kuzminsky> rtai debs for amd64 are done, i'll push them to wlo later tonight :-)
[19:42:02] <skunkworks> really?
[19:42:48] <skunkworks> I could test that on the systems I was having issues
[21:01:58] <jepler> seb_kuzminsky: roguish will be tickled
[21:02:06] <jepler> you've boot-tested 'em?
[21:02:30] <seb_kuzminsky> yep
[21:02:58] <seb_kuzminsky> i ran the rtai latency test in an amd64 vm, it got shitty numbers of course, but it ran
[21:48:03] <seb_kuzminsky> in order to build rtai-modules.deb for both flavors of the linux-image.deb (686-pae and amd64), i had to remove the kernel flavor from the rtai-modules name
[21:48:24] <seb_kuzminsky> so now it's just "rtai-modules-3.16.0-9", indicating the kernel version and abi number
[21:49:03] <seb_kuzminsky> the featureset "rtai" is implied, and the flavor is implicitly determined by whether you're fetching it from jessie/base/binary-i386 (686-pae) or from jessie/base/binary-amd64 (amd64)
[21:49:26] <seb_kuzminsky> it's the simplest way i found to support multiple kernel flavors from a single rtai.dsc
[22:17:30] <jepler> seems fine to me
[22:18:00] <jepler> thanks for working on this
[22:19:27] <seb_kuzminsky> crap, the amd64 liblxrt isnt getting compiled with -fpic so its hosed
[22:19:52] <jepler> oops, that's important
[22:20:08] <jepler> actually I wish there was a .so version of it so it could be dlopen()ed but that's another thing altogether
[22:20:28] <jepler> sounds dirty but isn't:
[22:20:31] <jepler> Subject: Poor mans soft turnon
[22:20:53] <jepler> 'night and afk