Back
[03:14:14] <archivist> I need ops to ban a spammer in #linuxcnc
[03:19:26] <ikcalB> jepler: regarding the timing issue, I observed the following: Besides several errors in the igh EtherCAT master, which led to different (re-)start behavior depending on the previous conditions, all timing functions seem unharmful.
[03:21:22] <ikcalB> yet idk which timebase RTAI is actually using, because the resolution is sth. in tens / hundreds of ns (otherwise the rounding error of set-period to actual period had to be smaller)
[03:21:58] <ikcalB> additionally this source seems to need synchronisation - at least I get diffrent actual cycle times when restarting my system.
[03:23:29] <ikcalB> what's more, the time base is diffrent from the one used by `gettimeofday()`, as these diverge rather strongly.
[03:25:37] <ikcalB> From what I can say, the `gettimeofday()` timebase is more accurate than the RTAI one, because it matches external clocks better - at least on this mobo. because of the large drift, I ran into correcting variable limitiations of the EtherCAT time sync (PLL / PI. idk) mechanism, which showed incomprehensible behavior, up to now
[03:30:07] <ikcalB> FREEZES on recent hardware (intel haswell, Pentium G3258) with wheezy (kernel 3.4.9-rtai): my research led me to believe, that some bug in the kernel (mentioned for 3.2.x and Ivy Bridge) causes random system freezes (no magic sysrq). I've read, that someone prepared new kernel - are they ready for deploying / testing? Available from a repo to install over linuxcnc 2.7.4?
[05:29:46] <trasz> jepler: hi. no hurry with that PR. however, could you tell me if there are any patches in my current pull request you still plan to merge?
[05:31:30] <trasz> in other news:
https://www.freshports.org/cad/linuxcnc-devel/
[07:11:01] <jepler> trasz: wow nice
[07:11:16] <jepler> trasz: I think that I should take these specific two commits:
[07:11:17] <jepler> 7a15bf1 Use pgrep(1) as an alternative to Linux-specific pidof(1).
[07:11:20] <jepler> 1de498f Remove the '-' from shebang strings.
[07:11:29] <jepler> oh and this one
[07:11:30] <jepler> d1f9fa6 Fix typo.
[07:12:03] <jepler> the issue that this commit is about is complicated now, because with uspace+rtai on linux we do modprobe/insmod/rmmod: 44e7080 Don't test for insmod/rmmod/lsmod when building with uspace.
[07:13:01] <jepler> and as I already noted I don't think this one is correct, and I'd rather unconditionally switch away from using fsuid in any case: cfd3d99 Don't use setfsuid(2) on non-Linux.
[07:13:35] <jepler> and as you noted that code is sorely in need of error checking
[07:17:31] <jepler> ikcalB: ah yes I refuse to look at ethercat due to the terms of the "Beckhoff EtherCAT Master license" which conflict with the GPL and are likely to make any binaries that include both portions of LinuxCNC and portions of the ethercat library non-distributable.
[07:18:01] <jepler> ikcalB: in any case you've gone beyond my knowledge of RTAI and timing as well. you will have better luck inquiring in an RTAI-specific venue.
[07:18:36] <jepler> of course, over in RTAI they are likely to be uninterested in what may just be bugs in old software
[07:19:57] <ikcalB> jepler: complete agreement. this was just fyi - maybe this comes in helpful, when debugging other, maybe timing related, issues
[07:29:45] <KGB-linuxcnc> 03Edward Tomasz Napierala 05master 17d1207 06linuxcnc 10(6 files in 4 dirs) Remove whitespace after shebang (#!). * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=17d1207
[07:29:45] <KGB-linuxcnc> 03Edward Tomasz Napierala 05master 018fe2e 06linuxcnc 10(36 files in 16 dirs) Make Python shebangs portable. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=018fe2e
[07:29:45] <KGB-linuxcnc> 03Edward Tomasz Napierala 05master 0a926fc 06linuxcnc 10(8 files in 2 dirs) Remove the '-' from shebang strings. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0a926fc
[07:29:46] <KGB-linuxcnc> 03Edward Tomasz Napierala 05master e455c3f 06linuxcnc 10scripts/linuxcnc_info Fix typo. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e455c3f
[07:33:28] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler closed pull request #84: Another push of FreeBSD-specific changes. (06master...06master) 02
https://github.com/LinuxCNC/linuxcnc/pull/84
[07:33:43] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #84: I look forward to your next PR :+1: 02
https://github.com/LinuxCNC/linuxcnc/pull/84#issuecomment-232335539
[07:59:05] <trasz> jepler: hm, so is the pidof change ok or not?
[08:00:01] <trasz> jepler: also - is there a way to just disable the modprobe checks under !linux?
[08:06:22] <jepler> trasz: I think we should use pgrep unconditionally
https://github.com/LinuxCNC/linuxcnc/pull/88
[08:13:48] <jepler> trasz: I'd rather put off consideration of how to fix the linux kernel module related stuff in configure until after uspace-plus is merged, or it becomes clear it will not be merged for 2.8.
[08:14:19] <jepler> in practice we actually hard-code insmod and rmmod as being in /sbin in module_helper.c, the detection in configure is just distracting fluff
[08:14:33] <jepler> we do use the detected value of lsmod
[08:17:41] <trasz> jepler: hm, ok.
[08:17:47] <trasz> jepler: what's uspace-plus?
[08:18:50] <jepler> trasz: it allows a single linuxcnc (rtapi_app) binary to support any of linux preempt-rt, rtai lxrt, and xenomai posix-skin for real-time
[08:19:05] <trasz> jepler: ah.
[08:19:22] <jepler> .. and rtai lxrt does need to insert/remove kernel modules at start/end, unlike uspace rtapi_app realtime before now
[08:19:22] <trasz> jepler: ok, regarding that pidof/pgrep change - i hadn't tested it, but it looks like it should work.
[08:19:39] <trasz> jepler: one question, though - why are you using 'pgrep -x' in one place, and plain 'pgrep' in the other?
[08:19:45] <jepler> no idea
[08:19:57] <jepler> hmmm "pidof -x" means "scripts too"
[08:20:18] <trasz> scripts?
[08:21:04] <jepler> ok this needs more work
[08:23:05] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler closed pull request #88: configure: use (more) portable pgrep (06master...06jepler/master/pgrep) 02
https://github.com/LinuxCNC/linuxcnc/pull/88
[08:23:51] <jepler> so `pgrep` is really a lot like grep, so `pgrep wat` shows a process called "watchdog" or a process with "mailwatch" in its argv
[08:24:40] <trasz> yeah.
[08:24:44] <jepler> er I guess the full program name is /usr/lib/x86_64-linux-gnu/xfce4/panel-plugins/xfce4-mailwatch-plugin so it's still looking in argv[0]
[08:25:09] <trasz> hm.
[08:26:09] <trasz> well, i did this:
[08:26:23] <trasz> [trasz@victim:~]% ps auxww | grep cat
[08:26:24] <trasz> trasz 69205 0,0 0,0 8336 2240 1 S+ 14:58 0:00,00 /bin/cat
[08:26:30] <trasz> [trasz@victim:~]% pgrep -x cat
[08:26:31] <trasz> 69205
[08:26:45] <trasz> so I suppose 'pgrep -x' does what it's supposed to do, ie ignores the path prefix.
[08:28:24] <jepler> http://paste.ubuntu.com/19270179/
[08:29:12] <jepler> on linux there's a caveat about searching only the first 15 characters, but I guess it is the portion after the last slash
[08:30:03] <jepler> as for finding scripts, it looks like 'pgrep -x' does OK.
http://paste.ubuntu.com/19270294/
[08:31:43] <jepler> the longest thing we pass to pidof right now is "linuxcncpanel" at 13 chars
[08:31:53] <jepler> so .. pidof -x everywhere?
[08:33:19] <trasz> yeah, i believe that's how it should work.
[08:33:57] <jepler> ttyl, $DAY_JOB time
[10:00:36] <skunkworks> xlog
[10:00:39] <skunkworks> zlog
[10:41:01] <seb_kuzminsky> trasz: that's very cool!
[11:19:11] ChanServ changed topic of
#linuxcnc-devel to:
http://linuxcnc.org | Latest releases: 2.7.5 and 2.6.12 | (this channel is logged by the zlog robot)
[11:19:25] <jepler> woohoo
[11:19:53] <seb_kuzminsky> at long last :-)
[11:24:33] <jepler> seb_kuzminsky: we had discussed putting the ethernet packet loss stuff in 2.7 and the conclusion I recall was that it was OK after you did 2.7.5. Do you still feel that way?
[11:36:27] <KGB-wlo> push to master branch:
http://linuxcnc.org/
[11:36:33] -linuxcnc-github:#linuxcnc-devel- [13wlo] 15SebKuzminsky pushed 3 new commits to 06master: 02
https://github.com/LinuxCNC/wlo/compare/473173a57dcd...48c350c3fc1f
[11:36:33] -linuxcnc-github:#linuxcnc-devel- 13wlo/06master 1445e4397 15Sebastian Kuzminsky: fix a spelling error
[11:36:33] -linuxcnc-github:#linuxcnc-devel- 13wlo/06master 1426c9818 15Sebastian Kuzminsky: LinuxCNC 2.7.5!
[11:36:33] -linuxcnc-github:#linuxcnc-devel- 13wlo/06master 1448c350c 15Sebastian Kuzminsky: update Release data with 2.7.5
[11:36:44] <seb_kuzminsky> jepler: i remember that
[11:37:04] <seb_kuzminsky> i think i looked at it and it looked better than what we have now
[11:37:26] <seb_kuzminsky> i appreciate you waiting for 2.7.5, feel free to push it now if you're ready
[11:37:36] <seb_kuzminsky> i promise i won't wait another 6 months for 2.7.6...
[11:38:02] <jepler> I know how it goes
[11:38:41] <seb_kuzminsky> it does go that way, doesn't it
[11:41:03] <pcw_home> I have been running eth-packet-loss on three machines for a month or two, it does not seem to cause any issues
[11:41:34] <KGB-wlo> push to master branch:
http://linuxcnc.org/
[11:41:44] -linuxcnc-github:#linuxcnc-devel- [13wlo] 15SebKuzminsky pushed 1 new commit to 06master: 02
https://github.com/LinuxCNC/wlo/commit/c600b7920702d2be92325b075fca2d9dd148d2b4
[11:41:44] -linuxcnc-github:#linuxcnc-devel- 13wlo/06master 14c600b79 15Sebastian Kuzminsky: 2.7.5 release: fixup markdown syntax
[12:04:40] <KGB-wlo> push to master branch:
http://linuxcnc.org/
[12:04:46] -linuxcnc-github:#linuxcnc-devel- [13wlo] 15jepler pushed 1 new commit to 06master: 02
https://github.com/LinuxCNC/wlo/commit/39eaf5f2ff5ddb7945a265c0d7853d909b962c39
[12:04:46] -linuxcnc-github:#linuxcnc-devel- 13wlo/06master 1439eaf5f 15Jeff Epler: hi andy...
[12:14:54] <seb_kuzminsky> i really like the showcase on the front page
[14:48:42] <seb_kuzminsky> pcw_home: thanks for testing the packet-loss changes, that makes me confident
[14:50:33] <seb_kuzminsky> has anyone tried this?
http://camotics.org/
[15:06:27] <mozmck> seb_kuzminsky: I like the new name of that project better than the old...
[15:09:21] <seb_kuzminsky> heh yeah
[15:09:37] <seb_kuzminsky> at first i thought "openSCAM" was some kind of snarky parody
[15:10:47] <mozmck> I would think CAM is much more important that simulation.
[15:11:35] <mozmck> than
[15:12:08] <seb_kuzminsky> when making the 2.7.5 release i updated the ReleaseCheckList wiki page, some minor things had changed
[15:12:24] <seb_kuzminsky> specifically, where the new release is announced
[15:16:21] <KGB-linuxcnc> 03Jeff Epler 052.7 79189c8 06linuxcnc Merge remote-tracking branch 'origin/jepler/2.7/eth-packet-loss' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=79189c8
[15:16:35] <seb_kuzminsky> thanks jeff
[15:16:59] <jepler> it was a challenging project. I hope the result is good.
[16:23:28] <mozmck> Hey seb, the guy with CAMotics also has dockbot:
https://github.com/CauldronDevelopmentLLC/dockbot
[16:25:56] <seb_kuzminsky> neat
[16:25:59] <seb_kuzminsky> buildbot is the bee's knees
[17:16:05] <jepler> I like it a lot, when I'm not repeatedly crashing it and blaming the VM software!
[17:20:50] <seb_kuzminsky> i think it's the preempt-rt kernel that's to blame for most or all of the crashes
[17:21:04] <seb_kuzminsky> the vanilla-kerneled VMs run fine
[17:22:01] <seb_kuzminsky> oh speaking of which, did you notice if there have been any crashes since i upgraded to 4.1.6-rt?
[17:47:09] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 80c6adb 06linuxcnc 10debian/changelog 10src/configure.in 10src/hal/drivers/mesa-hostmot2/hostmot2.c Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=80c6adb
[18:07:19] <jepler> seb_kuzminsky: maybe it scrolled by while you weren't lookking, but I reproduced a hang with kernel 4.4 on bare metal with maxcpus=2 and worked around it. the whole system was hanging when I called pthread_cancel on a RT thread...
[18:07:27] <jepler> which was something that I introduced in this uspace-plus branch
[18:07:56] <jepler> so ... the problem may or may not be in the kernel, but it was in 4.1 and 4.4 at least, and I've changed what I do to avoid triggering it
[18:08:04] <jepler> https://github.com/LinuxCNC/linuxcnc/issues/109
[18:08:56] <seb_kuzminsky> i think we need two numbers to identify the Preempt-RT kernel: the kernel.org version and the preempt-rt patch version
[18:09:28] <jepler> I'm not sure the debian-built kernels provide both those numbers in uname..
[18:09:43] <jepler> in fact I'm pretty confident they don't
[18:10:53] <seb_kuzminsky> i agree :-(
[18:12:40] <seb_kuzminsky> jepler: looking in the dsc for the 4.1.6-1 kernel deb i think it's using -rt3
[18:17:55] <seb_kuzminsky> https://www.kernel.org/pub/linux/kernel/projects/rt/4.1
[18:18:14] <seb_kuzminsky> there's a -rt30 now...
[18:18:52] <seb_kuzminsky> i wonder how much work it would be to take the debian packaging of linux 4.1.6 and preempt-rt 3 and move it forward to 4.1.27 and rt30...
[18:19:23] * seb_kuzminsky backs away from the computer
[18:20:23] <jepler> 30 is a lot more than 3
[18:20:45] <seb_kuzminsky> and 27 > 6
[18:21:21] <seb_kuzminsky> i had an unpleasant couple of weeks trying to debug rtai crashes, but surely preempt-rt is in better shape
[18:45:30] <skunkworks_> I just installed 4.6.4.. so far so good
[18:46:07] <skunkworks_> rt
[18:46:08] <skunkworks_> 6
[19:18:32] <jepler> I don't think I tried my crashing program with 4.6-anything
[19:18:35] <jepler> I suppose I should
[19:18:51] <skunkworks_> Could I do it here?
[19:21:29] <jepler> eh don't bother
[19:22:10] <jepler> I'd be more interested in news from someone trying uspace+rtai AKA uspace+lxrt
[19:25:07] <jepler> https://www.instagram.com/p/BH0ahlxAqkh/
[19:29:40] <skunkworks_> starting with the livecd - what more would you have to install to try the lxrt?
[19:29:49] <skunkworks_> (other than building your branch)
[19:30:28] <skunkworks_> just rtai-modules?
[19:33:35] <jepler> if you can build and run a traditional rtai kernel-model realtime linuxcnc, you should be able to build and run my branch.
[19:34:08] <jepler> you have to configure --with-realtime=uspace, and look for rtai in this line from configure: checking for realtime API(s) to use... uspace+lxrt+xenomai
[19:34:16] <jepler> (you probably won't have +xenomai)
[19:54:26] <cradek> jepler: do you think it will run on rtai now? recently it didn't.
[19:54:45] <cradek> (I'd have to move a cat to go try it)
[19:56:29] <jepler> cradek: it does here, jessie with seb's latest kernel from highlab.com.
[19:58:05] <jepler> linux-image-3.18.0-1-rtai-amd64 + rtai-modules-3.18.0-1
[19:58:20] <jepler> so when you tried it the other day, it worked properly zero times? hmph.
[19:58:36] <cradek> lemme try again
[19:58:55] <jepler> sorry cat
[19:59:35] <cradek> jepler/master/uspace-plus, right?
[19:59:40] <jepler> yes
[19:59:49] <jepler> you're on .. wheezy?
[20:00:09] <cradek> yes, Linux emc 3.4-9-rtai-686-pae #1 SMP PREEMPT Debian 3.4.55-4linuxcnc i686 GNU/Linux
[20:00:22] <cradek> I think this is the setup our users all use
[20:00:49] <jepler> you think they're as predictable as all that? :-P
[20:00:56] <cradek> wellll
[20:01:01] <cradek> most? many?
[20:01:11] <cradek> (I bet actually a lot use lucid)
[20:01:13] <jepler> it's the one that comes from that install image we promote
[20:01:18] <cradek> yeah that
[20:02:04] <Tom_itx> lucid ftw! ... if it ain't broke don't fix it
[20:03:24] <jepler> I guess I have a wheezy rtai vm image here, I should boot it.
[20:03:49] <cradek> Error: could not insert module /home/chris/emc/rtlib/rtapi.ko: Invalid module format
[20:04:00] <cradek> yeah it still has a fundamental problem of some kind
[20:04:37] <cradek> that's from stderr upon runtests tests/flipflop.0
[20:04:53] <jepler> can you pastebin your configure output?
[20:05:57] <cradek> http://paste.ubuntu.com/19323423/
[20:06:08] <jepler> it doesn't even build for me
[20:06:11] <jepler> rtapi/uspace_rtai.cc:4:28: fatal error: rtai/rtai_lxrt.h: No such file or directory
[20:06:57] <jepler> how did you invoke configure?
[20:07:03] <cradek> ahem
[20:07:11] <cradek> ./configure --enable-non-distributable=yes
[20:07:19] <cradek> I need to specify uspace somehow don't I
[20:07:39] <jepler> yeah but now I wonder why buildbot didn't detect me breaking rtai builds!
[20:08:30] <jepler> --with-realtime=uspace
[20:08:54] <cradek> yeah same build failure now
[20:09:14] <cradek> although I do seem to have that include in another place or two
[20:09:33] <jepler> yes
[20:09:43] <cradek> sorry for the invalid reports earlier
[20:09:45] <jepler> looks like my code is wrong, it should just be <rtai_lxrt.h>
[20:09:56] <jepler> that's OK, but now I know I broke real rtai at least on wednesdays
[20:12:57] <jepler> -#include <rtai/rtai_lxrt.h>
[20:12:57] <jepler> +#include <rtai_lxrt.h>
[20:13:14] <jepler> but yes it builds and works for me on wheezy i386 with this
[20:13:30] <cradek> yay!
[20:13:44] <jepler> now trying a build with rtai
[20:13:50] <jepler> er you know
[20:13:54] <jepler> with old style
[20:14:31] <jepler> is it possible you just need to build clean or something?
[20:14:35] <jepler> git clean even?
[20:14:45] <cradek> no, I did all that carefully
[20:14:47] <jepler> ok ok
[20:14:56] <jepler> waiting on my build..
[20:16:30] <jepler> hm that wfm too
[20:18:50] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler closed pull request #108: Preview: uspace+RTAI+xenomai (06master...06uspace-rtai) 02
https://github.com/LinuxCNC/linuxcnc/pull/108
[20:19:55] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened pull request #110: "uspace plus": uspace with support for preempt-rt, rtai, and xenomai (06master...06jepler/master/uspace-plus) 02
https://github.com/LinuxCNC/linuxcnc/pull/110
[20:20:37] <mozmck> cradek: you still have the bridgeport r2e3?
[20:20:47] <cradek> nope, seb has it now
[20:20:59] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #99: 2.7.5 has been released. 02
https://github.com/LinuxCNC/linuxcnc/issues/99#issuecomment-232528234
[20:21:05] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler closed issue #99: After Update to 2.7.4 error warning when using "Run From Line" in Gmoccapy 02
https://github.com/LinuxCNC/linuxcnc/issues/99
[20:21:08] <mozmck> I see! My boss just bought one - it's in a garage.
[20:22:01] <mozmck> So I think I'll have to take the top off like you did - how bad a job was that?
[20:23:14] <cradek> not bad, but the oil lines are easy to break
[20:23:22] <jepler> (ugh lxrt-config --rtai-cflags is stupid, it specifies -I.!)
[20:23:30] <cradek> you can take it apart, push it indoors, and put it back together in a day
[20:23:42] <cradek> probably need two people
[20:24:18] <mozmck> I have to take it out and on a trailer. It will then go in a shop which has a tall enough door.
[20:24:26] <cradek> jepler: still fails for me, and I nuked my typescript with git clean
[20:24:40] <mozmck> That's good to know. We've been scratching our heads, but it was a pretty good deal we think.
[20:24:43] <jepler> cradek: that's distressing.
[20:24:44] <cradek> mozmck: there's a lifting point on the head casting where it balances
[20:26:10] <cradek> jepler: building/logging again
[20:26:16] <jepler> linux-image-3.4-9-rtai-686-pae 3.4.55-4linuxcnc
[20:26:20] <mozmck> I have an A-frame with a 2-ton chain hoist, so getting it on the trailer should not be hard.
[20:26:20] <jepler> rtai-modules-3.4-9-rtai-686-pae 3.9.265.gd99c55e
[20:26:36] <jepler> (hums at 3.4.9 vs 3.9.265.g...)
[20:27:00] <cradek> those are the versions I have
[20:27:24] <jepler> ./configure and ./configure --with-realtime=uspace
[20:27:45] <cradek> er no
[20:27:48] <jepler> make, sudo make setuid, runtests
[20:27:50] <cradek> do I have a mess?
[20:27:52] <cradek> ii linux-headers-3.4-9-common-rtai 3.4.87-1~linuxcnc.1 i386 Common header files for Linux 3.4-9-rtai
[20:27:55] <cradek> ii linux-headers-3.4-9-rtai-686-pae 3.4.87-1~linuxcnc.1 i386 Header files for Linux 3.4-9-rtai-686-pae
[20:27:58] <cradek> ii linux-headers-3.4.55-rtai-2 3 i386 Header files related to Linux kernel, specifically,
[20:28:26] <jepler> linux-headers-3.4-9-common-rtai 3.4.55-4linuxcnc
[20:28:30] <jepler> linux-headers-3.4-9-rtai-686-pae 3.4.55-4linuxcnc
[20:30:39] <cradek> http://paste.ubuntu.com/19324915/
[20:30:48] <cradek> clearly I should try building master
[20:31:04] <cradek> I don't know what all this machine has been through
[20:31:23] <jepler> apt-cache policy for linux-headers...:
http://paste.debian.net/781071/
[20:31:45] <jepler> I wonder what 3.4.87 is .. or 3.4.55 for that matter
[20:31:54] <jepler> but yes, building master might be informative
[20:32:01] <jepler> also looking at dmesg for the actual insmod error
[20:32:19] <cradek> [24056294.624233] rtapi: disagrees about version of symbol module_layout
[20:34:36] <cradek> sorry, it's my box
[20:34:37] <cradek> jeez
[20:34:42] <jepler> np
[20:34:48] <cradek> I use it all the time - but I guess I always run packages
[20:35:01] <jepler> I bet it'll build once you put those modules back
[20:35:03] <jepler> er headers
[20:35:48] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus c604616 06linuxcnc 10(7 files in 3 dirs) uspace: add uspace+rtai realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c604616
[20:35:48] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus c253da8 06linuxcnc 10(6 files in 2 dirs) uspace: add uspace+xenomai realtime * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c253da8
[20:35:48] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus c8db46f 06linuxcnc 10(8 files) packaging: rtai, xenomai are sub-packages of uspace * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c8db46f
[20:35:50] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/uspace-plus f6dbd09 06linuxcnc 10docs/src/code/building-linuxcnc.txt docs: document new RTOS support * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f6dbd09
[20:50:17] <jepler> > Is NASA hiding clear video evidence of a UFO descending to Earth? To paraphrase what a spokesperson from the space agency told me when I asked: "Uh, no."
[20:50:21] <jepler> thank you journalism
[21:06:07] <skunkworks_> That just proves it!
[21:58:55] <seb_kuzminsky> 3.4.55 is the version of the kernel (from kernel.org) that the linux-image-3.4-9 debian package packages
[21:59:15] <seb_kuzminsky> 3.4.87 was another one i tried at some point that didnt work out well
[22:01:49] <seb_kuzminsky> cradek, jepler: i might have done a bad thing with the rtai kernel debs at highlab...
[22:02:29] <jepler> seb_kuzminsky: uh oh
[22:02:38] <jepler> the jessie ones?
[22:02:38] <seb_kuzminsky> i was chasing problems with rtai 5.0-test2 and rebuilt the kernel with lock tracing and debugging turned on, and i didn't bump the version number
[22:02:44] <jepler> ouch
[22:02:52] <cradek> oh noooo
[22:02:53] <seb_kuzminsky> yeah, the 3.18-rtai kernel
[22:03:02] <cradek> restore from backups?
[22:03:05] <seb_kuzminsky> i should know better by now
[22:03:10] <seb_kuzminsky> well
[22:03:13] <jepler> dput usually stops me from doing that
[22:03:41] <seb_kuzminsky> i should look into using dput, it's all a big pile of make right now
[22:03:48] <jepler> ah ugh
[22:03:56] <jepler> fwiw I have the amd64 kconfig here if that helps
https://emergent.unpythonic.net/files/sandbox/config-3.18.0-1-rtai-amd64
[22:04:04] <jepler> I sure didn't snag the source package though
[22:04:13] <seb_kuzminsky> that part is no problem
[22:04:31] <seb_kuzminsky> it all builds out of git repos so i can just check out the commit y'all are used to and build that
[22:04:55] <jepler> it'll all work out in the end
[22:04:59] <seb_kuzminsky> then i'll go back to the branch tip where i turned on debugging, add another commit to bump the version number, and build that
[22:05:01] <jepler> you didn't do it on an important, well-publicized repo
[22:05:07] <cradek> looks like I have the packages in varcacheapt
[22:05:22] <seb_kuzminsky> yeah, sorry for wasting your time with extra stupid debugging
[22:05:50] <cradek> no I mean the old ones if you want to put them back manually
[22:07:16] <jepler> hm somebody needs to write a MIDI driver for linuxcnc
[22:08:07] <jepler> .. not really midi, but "firmata", this protocol that is apparently implemented on a bunch of tiny micros and can read/write analog and digital values plus do board-specific tricks
https://github.com/firmata/protocol
[22:09:22] <seb_kuzminsky> rebuilding now... sorry for the noise
[22:09:47] <jepler> which I now know a little bit about because I stuck one of these under my desk to light up the keyboard tray, and I easily wrote a little python program to turn the light up when the screen is on and down when the screen is off (X dpms state)
[22:09:51] <jepler> https://www.adafruit.com/products/3000
[22:14:37] <seb_kuzminsky> the folks at the hackspace are all atwitter about the esp8622
[22:15:28] <seb_kuzminsky> 8266? something like that
[22:15:34] <jepler> I have heard of the ESPs
[22:15:49] <jepler> there's a new one, I know that
[22:15:56] <jepler> I ordered some of the old ones and they are gathering dust somewhere
[22:16:50] <seb_kuzminsky> kerry and i have been talking about an art project with wifi and those spi led strips
[22:17:13] <seb_kuzminsky> little lights scattered around, that all talk to each other and synchronize their little light show
[22:17:36] <seb_kuzminsky> because what we need is another project
[22:23:57] <seb_kuzminsky> jepler: dput uploads to a deb archive, what do you run on the receiving side to update the Packages files etc there?
[22:24:06] <jepler> seb_kuzminsky: mini-dinstall
[22:24:48] <seb_kuzminsky> thx
[22:25:16] <jepler> one thing about mini-dinstall, it seems to immediately delete old versions
[22:25:28] <jepler> I think the scripts we've inherited involving ftparchive do not
[22:25:56] <seb_kuzminsky> hmm yeah
[22:26:06] <jepler> ah maybe keep_old (not the default)
[22:26:14] <jepler> cradek: we should change this at $DAY_JOB
[22:26:36] <seb_kuzminsky> my makepile uses apt-ftparchive
[22:26:49] <cradek> hahaha makepile
[22:27:01] <seb_kuzminsky> :-)
[22:27:20] <jepler> 'night guys
[22:27:27] <seb_kuzminsky> g'night jeff
[22:27:33] <jepler> time to press the "pause" key and watch the LED dim one last time, not for testing :-P