Back
[00:27:25] -!- Nick001 has quit [Ping timeout: 252 seconds]
[00:36:58] -!- thomaslindstr_m has quit [Quit: Leaving...]
[00:39:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb cf12f38 06linuxcnc 10(12 files) deb: new debian/configure and debian/control* * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cf12f38
[00:39:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 6c321d1 06linuxcnc 10debian/configure deb/conf: accept -a to mean -r * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6c321d1
[00:39:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 85147b3 06linuxcnc 10debian/control.in deb/control: get rid of ancient Provides in control * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=85147b3
[00:39:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 5bc002d 06linuxcnc 10debian/control.posix.in 10debian/control.rtai.in 10debian/control.rtpreempt.in deb/control: relax the Conflicts * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5bc002d
[00:39:50] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 4bd7ae9 06linuxcnc 10debian/rules.in deb/rules: dont use cpio when cp will do * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4bd7ae9
[00:39:54] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 950343f 06linuxcnc 10debian/linuxcnc.files.in 10src/Makefile install rsyslogd.conf file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=950343f
[00:39:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 9cf76a5 06linuxcnc 10src/configure.in 10src/rtapi/ulapi_autoload.c give dlopen the path to the ulapi library * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9cf76a5
[00:40:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 78981f9 06linuxcnc 10src/Makefile 10src/rtapi/Submakefile put ulapi-$flavor.so straight into rtlib/, not lib, so the dlopen can look in EMC2_RTLIB_DIR * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=78981f9
[00:40:06] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 21b487f 06linuxcnc 10(6 files) deb: add xenomai support * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=21b487f
[00:43:11] -!- rob_h has quit [Ping timeout: 260 seconds]
[00:43:57] -!- lyzidiamond has quit [Quit: lyzidiamond]
[00:44:37] -!- jfire has quit [Quit: Leaving.]
[00:48:58] -!- lyzidiamond has quit [Client Quit]
[00:54:49] -!- arvidkahl has quit [Ping timeout: 272 seconds]
[01:01:53] -!- uwe_ has quit [Ping timeout: 252 seconds]
[01:03:48] -!- toastydeath has quit [Read error: Connection reset by peer]
[01:07:10] -!- patrickarlt has quit [Remote host closed the connection]
[01:15:55] -!- zumba_addict has quit [Quit: zumba_addict]
[01:21:23] -!- lyzidiamond has quit [Quit: lyzidiamond]
[01:29:13] -!- Valen has quit [Quit: Leaving.]
[01:33:27] -!- uwe_ has quit [Ping timeout: 272 seconds]
[01:40:08] -!- Tecan has quit [Ping timeout: 245 seconds]
[01:45:51] -!- NickParker has quit [Read error: Connection reset by peer]
[01:48:30] -!- skorasaurus has quit [Client Quit]
[01:49:49] <linuxcnc-build> build #26 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/26 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>
[01:49:55] <linuxcnc-build> build #26 of deb-precise-xenomai-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-x86/builds/26 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>
[01:52:03] <linuxcnc-build> build #26 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/26 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>
[01:52:08] <linuxcnc-build> build #26 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/26 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>
[01:59:09] -!- uwe_ has quit [Ping timeout: 272 seconds]
[02:06:45] -!- Valen has quit [Quit: Leaving.]
[02:12:32] -!- almccon has quit [Quit: Leaving.]
[02:15:04] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[02:15:13] -!- Servos4ever has quit [Quit: ChatZilla 0.9.90.1 [SeaMonkey 2.23/20131210201646]]
[02:20:12] <KimK> (Note to forum maintainers) Re: link
http://www.linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/27266-g92-vs-keyboard-end-key#43110 pasted above, I seldom look at the forum at all, so don't go by me, but do "code blocks" *have* to be highlighted bright yellow? Yikes, my eyes are still blinking! How about 10% gray? Or some pale color?
[02:21:57] -!- c-bob|afk has quit [Ping timeout: 272 seconds]
[02:26:06] -!- micges has quit [Quit: Wychodzi]
[02:36:48] -!- uwe_ has quit [Ping timeout: 245 seconds]
[02:41:45] <linuxcnc-build> build #1317 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1317 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>
[02:44:02] -!- sirdancealot has quit [Ping timeout: 264 seconds]
[02:58:45] -!- wboykinm has quit [Remote host closed the connection]
[03:02:09] -!- patrickarlt has quit [Remote host closed the connection]
[03:10:20] -!- Tecan has quit [Changing host]
[03:19:26] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[03:22:17] -!- pcw_home has quit [Remote host closed the connection]
[03:25:37] -!- pcw_home [pcw_home!~chatzilla@c-50-174-121-10.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[03:29:03] -!- uwe_ has quit [Ping timeout: 252 seconds]
[03:40:49] -!- gazprom has quit [Ping timeout: 240 seconds]
[03:53:19] -!- patrickarlt has quit [Remote host closed the connection]
[04:04:29] -!- AR_ has quit [Ping timeout: 240 seconds]
[04:37:01] -!- patrickarlt has quit [Quit: Leaving...]
[04:40:40] -!- arkgis has quit [Remote host closed the connection]
[04:47:40] -!- psha [psha!~psha@213.208.162.93] has joined #linuxcnc-devel
[05:05:05] -!- Jeebiss has quit [Ping timeout: 272 seconds]
[05:20:42] -!- krusty_ar has quit [Ping timeout: 265 seconds]
[05:41:15] -!- ve7it has quit [Remote host closed the connection]
[05:44:37] -!- KimK has quit [Ping timeout: 272 seconds]
[05:45:26] -!- KimK [KimK!~Kim__@ip24-255-223-153.ks.ks.cox.net] has joined #linuxcnc-devel
[05:50:57] -!- wboykinm has quit [Remote host closed the connection]
[05:53:34] <zultron> Ah, sometimes I feel sorry for the non-colorblind. To us, it's very simple: everything's brown. Grass brown, lemon brown, fire-engine brown, sky brown....
[05:56:04] <KimK> Hi zultron, thanks for the insight. Sorry if that seemed like a rant earlier.
[05:56:57] -!- wboykinm has quit [Ping timeout: 253 seconds]
[05:57:49] <zultron> :) No, just kidding, I don't read the forums much either. I just hate it when the colors are blue and purple, or green and (real) brown, that's when I start ranting.
[05:59:49] -!- paideia has quit [Ping timeout: 272 seconds]
[06:00:08] -!- patrickarlt has quit [Quit: Leaving...]
[06:02:15] <KimK> The one that always gets me (and it *still* appears from time to time) is dark blue characters on a black background. How they can think that's a good idea is beyond me. I have to highlight their page to be able to read it.
[06:02:21] -!- Fox_Muldr has quit [Ping timeout: 272 seconds]
[06:04:13] <zultron> Yeah, I've used that trick too! Agh. Or yellow on white, that bugs you non-colorblind folk too, right?
[06:12:38] -!- amiri has quit [Read error: Operation timed out]
[06:42:24] -!- ries has quit [Quit: ries]
[06:56:30] -!- kwallace [kwallace!~kwallace@smb-90.sonnet.com] has parted #linuxcnc-devel
[06:56:58] -!- uw has quit [Quit: Leaving]
[07:19:35] -!- terabyte- has quit [Quit: terabyte-]
[07:21:09] -!- Cylly has quit [Ping timeout: 272 seconds]
[07:45:41] -!- zultron has quit [Ping timeout: 248 seconds]
[08:07:44] -!- The_Ball has quit [Remote host closed the connection]
[08:19:08] -!- jnaour_ has quit [Remote host closed the connection]
[08:23:47] -!- tjb1 has quit [Ping timeout: 260 seconds]
[08:32:02] -!- GJdan has quit [Quit: WeeChat 0.4.2]
[08:33:24] -!- pjm_ has quit [Read error: Connection reset by peer]
[08:41:20] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[08:50:44] -!- rob_h [rob_h!~robh@90.203.219.139] has joined #linuxcnc-devel
[09:34:37] -!- lyzidiamond has quit [Client Quit]
[09:47:30] -!- jthornton has quit [Ping timeout: 245 seconds]
[09:48:06] -!- JT-Shop has quit [Ping timeout: 252 seconds]
[09:53:09] -!- JT-Shop [JT-Shop!~john@75.106.20.181] has joined #linuxcnc-devel
[09:53:35] -!- jthornton [jthornton!~john@75.106.20.181] has joined #linuxcnc-devel
[09:54:15] -!- harmonia has quit [Remote host closed the connection]
[10:08:37] -!- syyl- has quit [Ping timeout: 248 seconds]
[10:21:39] -!- balestrino has quit [Ping timeout: 272 seconds]
[10:32:25] -!- kludge` has quit [Ping timeout: 252 seconds]
[10:38:14] -!- lyzidiamond has quit [Quit: lyzidiamond]
[10:53:04] -!- Reventlov has quit [Read error: Operation timed out]
[11:00:43] Reventlov is now known as Guest58384
[11:06:40] -!- lenoil has quit [Client Quit]
[11:07:49] -!- gazprom has quit [Ping timeout: 240 seconds]
[11:12:37] -!- b_b has quit [Changing host]
[11:30:08] -!- skunkworks has quit [Ping timeout: 245 seconds]
[11:39:15] -!- psha has quit [Read error: Connection reset by peer]
[11:41:04] -!- thomaslindstr_m has quit [Remote host closed the connection]
[11:43:27] -!- psha [psha!~psha@213.208.162.93] has joined #linuxcnc-devel
[11:46:59] -!- sumpfralle has quit [Ping timeout: 240 seconds]
[11:55:58] -!- FreezingCold has quit [Ping timeout: 245 seconds]
[12:23:20] -!- MattyMatt has quit [Ping timeout: 252 seconds]
[12:24:26] -!- skunkworks [skunkworks!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[12:29:47] -!- thomaslindstr_m has quit [Remote host closed the connection]
[13:02:13] -!- wboykinm has quit [Remote host closed the connection]
[13:05:08] -!- skunkworks has quit [Ping timeout: 245 seconds]
[13:06:34] -!- chillly has quit [Remote host closed the connection]
[13:27:19] -!- Valen has quit [Quit: Leaving.]
[13:29:33] -!- krusty_ar_ has quit [Client Quit]
[13:31:54] -!- mle has quit [Read error: Connection reset by peer]
[13:32:33] -!- balestrino has quit []
[13:43:05] -!- jef79m has quit [Ping timeout: 252 seconds]
[13:43:09] -!- aude has quit [Ping timeout: 246 seconds]
[13:43:21] -!- tjb11 has quit [Ping timeout: 265 seconds]
[13:43:26] -!- hm2-buildmaster has quit [Ping timeout: 264 seconds]
[13:43:28] -!- jst has quit [Ping timeout: 245 seconds]
[13:44:02] -!- `Nerobro has quit [Ping timeout: 264 seconds]
[13:44:11] -!- t12 has quit [Ping timeout: 246 seconds]
[13:44:38] -!- seb_kuzminsky has quit [Ping timeout: 264 seconds]
[13:48:28] -!- PCW has quit [Ping timeout: 245 seconds]
[13:57:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb 110ea3a 06linuxcnc 10debian/rules.in dont clean setuid bit on rtapi_app_xenomai * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=110ea3a
[14:00:29] -!- md-2 has quit [Remote host closed the connection]
[14:01:19] -!- seb_kuzminsky [seb_kuzminsky!~seb@184-96-165-188.hlrn.qwest.net] has joined #linuxcnc-devel
[14:02:18] -!- hm2-buildmaster [hm2-buildmaster!~hm2-build@184-96-165-188.hlrn.qwest.net] has joined #linuxcnc-devel
[14:03:39] -!- zumba_addict has quit [Quit: zumba_addict]
[14:23:04] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[14:34:51] -!- zultron [zultron!~zultron@99-190-134-148.lightspeed.austtx.sbcglobal.net] has joined #linuxcnc-devel
[14:35:28] <linuxcnc-build> build #786 of precise-amd64-xenomai-rip is complete: Failure [4failed apt-get-update compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-xenomai-rip/builds/786 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:36:21] -!- md-2 has quit [Ping timeout: 248 seconds]
[14:36:47] <mozmck> heh, seb_kuzminsky, your build is a complete: Failure!
[14:39:10] <skunkworks> I always read it that way too :)
[14:50:30] <zultron> seb_kuzminsky, can comps be compiled from the installed .deb packages?
[14:51:06] <cradek> the -dev package lets you build comps, external guis, etc
[14:51:14] <zultron> Love Austin: 1/2" of snow, and both the university and school district call off classes!
[14:51:27] <zultron> Thanks, cradek.
[14:52:21] <cradek> anytime (the question is easy enough)
[14:53:20] <zultron> I'm idly wondering how hard it would be to run unit tests against packages.
[14:54:00] <cradek> you mean our existing tests? that's only a packaging problem, isn't it? they just run sai and hal and stuff.
[14:56:47] <linuxcnc-build> build #1707 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1707 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:57:22] <zultron> Yeah, existing tests. Hope it's just a packaging problem. There was some other problem I've forgotten after this minor fix:
[14:57:25] <zultron> https://github.com/zultron/linuxcnc/commit/d0dcbacee503fa0f2756a43e73d76d6cea706075
[14:58:15] <zultron> (That's not a general fix, more of a proof of concept)
[14:58:40] <cradek> I didn't realize some of them compile
[14:58:47] <zultron> Just ones with comps.
[14:58:50] <cradek> perhaps that test could use comp, which knows paths already
[14:59:04] <zultron> Ah ha!
[14:59:48] <cradek> or (with more infrastructure changes) you could build the test correctly when making the package
[15:00:05] <cradek> but if you use comp, you get the side benefit of testing comp
[15:00:15] <zultron> Yeah, that would be ok, but I like your comp idea.
[15:01:20] <cradek> maybe: comp --compile --userspace bitops.c
[15:02:17] <cradek> (I wonder how many people in the world are still using mh)
[15:12:23] -!- tinkerer [tinkerer!~tinkerer@mail.play-pla.net] has joined #linuxcnc-devel
[15:19:30] <skunkworks> mh?
[15:22:45] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[15:24:07] <cradek> sorry, there are connections that are only obvious in my own head
[15:24:21] <zultron> Wasn't there a mail client by that name?
[15:24:25] <cradek> mh is an old mail user agent that was popular(?) in the early 90s(?)
[15:24:43] <cradek> comp is the name of the program in mh that you'd use to send (compose) an email
[15:24:55] <skunkworks> heh
[15:24:57] <cradek> so that conflicts with our program comp
[15:25:43] <cradek> you'd need to have been using unix a pretty long time to know to avoid using the name "comp" for your program...
[15:25:46] -!- R2E4 has quit [Read error: Connection reset by peer]
[15:28:30] <zultron> Yeah, that sounds familiar from when I used to run the UT Math Dept.'s old Sun systems, back when Sun OS was based on BSD.
[15:29:31] <cradek> the modern maildir takes the primary ideas of mh, which are now a lot more appropriate
[15:30:27] <cradek> back when you had to pick the number of inodes when you made your filesystem, mh (and innd) using one file per message were kind of a bad idea
[15:30:57] <cradek> but today with huge mailboxes (attachments) it's a big win
[15:33:17] <zultron> ext fs inodes are still determined at mkfs time, no? What fs do you use for your maildirs?
[15:33:29] <cradek> zfs
[15:33:44] <cradek> ext4 can't expand inodes? doh.
[15:34:03] <zultron> Not automatically, I don't think.
[15:34:07] <cradek> over time I'm having less and less patience for anything but zfs
[15:34:36] <zultron> Does zfs come standard on most distros?
[15:34:47] <cradek> on freebsd yes, on linux not really
[15:35:05] <skunkworks> isn't there major bugs with it on everyting but bsd?
[15:35:13] <zultron> I take it you're using freebsd, at least at work.
[15:35:30] <cradek> zfs is not gpl compatible so linux people have to jump through hoops, so consequently support is poor
[15:36:01] <cradek> yes my important servers are freebsd at work and at home both
[15:36:22] <cradek> have been for a very long time
[15:36:27] <zultron> Nice.
[15:36:38] <cradek> I wouldn't use anything else
[15:36:57] <cradek> git.linuxcnc.org is freebsd
[15:38:15] <zultron> I'm committed to Red Hat for perhaps one similar reason: always used it at work, and so use it for my extra-work stuff.
[15:38:32] <cradek> it's sure easy to get used to a distro
[15:39:19] <cradek> for a while I only used freebsd because I was used to it (and it didn't ever bite me like linux distros sometimes do), but now zfs is a very real reason to prefer it that's not based on just familiarity
[15:41:33] <zultron> Switching between distros is very painful. I've probably told this theory before, that's a major reason for distro wars. If someone actually comes up with a valid reason to switch distros, it would cause those on other distros a lot of pain. So folks argue strenuously that their distro is the best, even to the point of sounding like dogma.
[15:43:50] -!- kwallace [kwallace!~kwallace@tmb-216.sonnet.com] has joined #linuxcnc-devel
[15:44:00] <zultron> I have a lot locking me into Red Hat, but Fedora's lack of many, many packages needed for CAD/CAM/CNC is starting to balance out that lock-in....
[15:44:47] <cradek> I have not used redhat since 9, but switching from rpm to apt was such a relief. I bet rpm is better today (like it can surely automatically install dependencies by now)
[15:45:14] <zultron> I'm generally quite impressed with Debian, except for partman in the installer.
[15:45:16] <cradek> used to be, you'd say install B, it says nope that depends on A which you haven't installed, when A was right in that same directory
[15:46:00] <zultron> Yeah, we have yum now, much better. But actually apt seems a lot faster, which is a big pain of yum.
[15:46:32] <cradek> I'm currently installing dozens of debian machines, and I use the preseed feature of the installer to do all the work (including partitioning) so I haven't seen partman much.
[15:46:59] <zultron> The yum metadata expires every 90 minutes, and after that, you have to wait for it to download a whole bunch of crap before you can even e.g. list packages beginning with the string 'linuxcnc'. :P
[15:47:00] <cradek> so it boots from PXE and does the full install with no input
[15:47:12] <cradek> ooh, yuck
[15:47:35] <zultron> If you preseed the installer, then you're using partman to partition the disks, albeit in an automated mode.
[15:47:42] <cradek> right
[15:47:59] <cradek> also I'm using lvm, so it's a step more tricky
[15:48:00] <zultron> Try preseeding a dual boot installation sometime.
[15:48:15] <cradek> I have no interest in dual boot systems :-)
[15:48:29] <cradek> they're for wishy-washy people and I'm not one, haha.
[15:48:33] -!- ries has quit [Quit: ries]
[15:48:48] <zultron> I don't normally, but I wanted to set up a lab to test linuxcnc on real hardware.
[15:50:09] <zultron> Apparently, the Debian folk didn't imagine there could be an actual use for multi-boot systems, so preseeded partman insists on wiping the partition table at every install.
[15:50:30] <zultron> That also causes problems if you want to reinstall the OS, but keep a data partition.
[15:51:02] <cradek> preseeding an install to keep some partitions and nuke others seems both hard and risky
[15:51:14] <zultron> It's definitely hard on Debian. ;)
[15:51:22] <cradek> you could preseed everything but partitioning, so it would stop and do that step manually
[15:52:40] <zultron> You mean with a human at the console? Or escaping to some sort of script?
[15:52:41] <cradek> well I meant it's fundamentally hard. how do you even make a list? you don't even know the mountpoints at that stage do you?
[15:52:49] <zultron> (I guess the latter isn't technically 'manual')
[15:52:53] -!- mal`` has quit [Ping timeout: 272 seconds]
[15:53:06] <cradek> you could do either - I think there is escape-to-script ability but I'm not sure
[15:53:32] <cradek> maybe extN does keep track of "last mounted on" and you could pay attention to that
[15:54:26] <zultron> Well, in Anaconda, the partition specification can include a '--onpart=sdc3' argument.
[15:55:25] <zultron> Anaconda can also reuse LVM volume groups and mount existing logical volumes.
[15:55:31] <cradek> oh you mean you know where all the partitions are already, and you write the rules for one particular machine
[15:55:39] <zultron> Yeah.
[15:55:46] <cradek> surely preseed/partman can do that!
[15:56:08] <zultron> It can't. Surprised me, too.
[15:56:49] <cradek> bizarre
[15:56:56] -!- mal`` [mal``!~mal``@li125-242.members.linode.com] has joined #linuxcnc-devel
[15:57:01] <zultron> I ended up hacking it to do so. The debian installer devs told me that partman has been unmaintained for many years.
[15:57:39] <zultron> I suppose that's to its credit that its design is solid enough to not need major maintenance in the meantime.
[15:58:05] <cradek> I'm surprised it even handles lvm then
[15:58:33] <zultron> It does, but it handles it the same way, by wiping everything.
[15:59:00] <cradek> haha, the end of partman-auto-recipe.txt has advice for minimal sizes in 2004
[15:59:14] <zultron> Note that partman *can* set up dual-boot systems in manual mode; this is just something missing from the partman-auto portion.
[15:59:31] -!- Loetmichel has quit [Remote host closed the connection]
[16:00:11] <cradek> does debian not have gpt support yet?
[16:00:18] -!- mackerski has quit [Ping timeout: 252 seconds]
[16:00:18] mackerski_ is now known as mackerski
[16:01:06] <zultron> I don't know about that. Not much of my hardware is that new. ;)
[16:01:26] <cradek> heh I know that feeling
[16:01:49] <cradek> and the only big disks I have are in freebsd systems (which of course supports gpt)
[16:03:14] <zultron> Is gpt needed at all by non-EFI machines?
[16:03:34] <zultron> I guess for >2TB partitions.
[16:03:39] <cradek> I think it's more a very big disk thing
[16:03:49] <cradek> yeah
[16:04:03] <cradek> there might be non-gpt workarounds for those disks but it's probably sucky
[16:04:33] <cradek> I have bee able to totally avoid UEFI so far
[16:04:48] <cradek> been
[16:05:21] <zultron> My understanding (with no experience) is msdog partition tables can handle >2TB disks, but partitions must be smaller than 2TB.
[16:05:40] <cradek> aha
[16:05:58] <zultron> So if you're using LVM, the workaround isn't too sucky.
[16:06:18] <cradek> heh I remember lots and lots of 32MB dos partitions
[16:06:22] <cradek> some things never change
[16:06:40] <zultron> That may be wrong, though, that >2TB disks are ok.
[16:07:57] <zultron> I sort of remember that, but luckily never really had to work on M$ systems.
[16:08:26] <cradek> I can't find a disk size limit with zfs, but the maximum size of a pool is supposedly 256 zebibytes
[16:09:13] <zultron> Which is the 'z' in 'zfs', is that right?
[16:09:15] <cradek> single file, 16 exbibytes
[16:10:07] <cradek> I am not sure what the Z stands for
[16:14:34] <cradek> (looks like debian partman can do gpt)
[16:17:57] -!- krusty_ar has quit [Ping timeout: 272 seconds]
[16:21:08] <zultron> I was actually looking at what freebsd RT capabilities exist a few days ago, but couldn't find anything concrete.
[16:21:26] <zultron> (Lucky thing, since a LinuxCNC port would require the project be renamed.)
[16:21:50] <skunkworks> Because if has linux in the name?
[16:23:13] <zultron> Yep! j/k, j/k!
[16:23:22] <skunkworks> heh
[16:25:23] -!- mackerski has quit [Quit: mackerski]
[16:29:13] <cradek> zultron: yeah, I don't know of any
[16:29:34] <cradek> zultron: even if so, I don't think porting to freebsd would gain us anything important to justify the work
[16:30:11] <zultron> Isn't freebsd popular on embedded devices?
[16:30:28] <cradek> I guess I don't nkow
[16:30:29] <cradek> know
[16:31:01] <zultron> I don't either. Anyway, even if it were, Linux is too.
[16:31:06] <cradek> right
[16:31:54] <cradek> for a while, openbsd supported a wider number of platforms than anyone else, but I bet linux is catching up
[16:32:14] <cradek> you could run openbsd on your 68040 or your PA-RISC machine
[16:32:43] <seb_kuzminsky> zultron: about testing packages... i played a bit with that the other night (since i'm rototilling our packaging anyway)
[16:32:56] <zultron> Oh yeah? Cool!
[16:33:04] <seb_kuzminsky> a problem i ran into is that our runtests script pretty well expects to be in a rip directory
[16:33:25] <zultron> Yep.
[16:33:26] <seb_kuzminsky> it'll need to be fixed, and all our devs will need to learn to run (source ../scripts/rip-environment; runtests)
[16:33:30] <seb_kuzminsky> no biggie
[16:33:59] <seb_kuzminsky> bbl!
[16:35:14] <zultron> Wait, I didn't get the thing we'll need to learn. Looks similar to what we do now.
[16:38:35] <seb_kuzminsky> ok back, had to switch busses
[16:38:45] <pcw_home> Can anyone hazzard a guess as to why the latency test is borked in ubc? (at least in Preemt_RT)
[16:39:02] <seb_kuzminsky> pcw_home: if only zultron was here... oh wait!
[16:39:40] -!- maximilian_h [maximilian_h!~bonsai@130.255.104.21] has joined #linuxcnc-devel
[16:39:42] <seb_kuzminsky> zultron: i meant, devs will need to re-train their fingers to source rip-environment before running runtests, that's all
[16:40:08] <zultron> Umm, don't have a guess, but I can test it out. What're you seeing, pcw_home?
[16:40:33] <zultron> I see. I didn't realize that was optional anyway.
[16:40:44] <pcw_home> the max latency number goes down occasionally :-(
[16:41:16] <zultron> Wow, I certainly haven't heard of that before!
[16:41:45] <skunkworks> I have also seen this.. (only on rt_preempt..) it will pop up to sa 80us -then back down to 60us..
[16:41:54] <skunkworks> *say
[16:42:10] <zultron> Thanks for the report. I'll investigate.
[16:42:32] <zultron> logger[mah], bookmark, plz
[16:42:33] <logger[mah]> zultron: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-01-24.html
[16:44:14] -!- maximilian_h has quit [Client Quit]
[16:44:51] <zultron> pcw_home, skunkworks, issue logged here:
https://github.com/zultron/linuxcnc/issues/72
[16:46:11] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb f971eee 06linuxcnc 10(5 files in 2 dirs) add a linuxcnc-test.deb, with all the tests in it * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f971eee
[16:46:29] <cradek> amazing.
[16:47:04] <seb_kuzminsky> the bigger problem with this testing deb is all the changes we're going to need to our CI infrastructure
[16:47:36] <seb_kuzminsky> i think we'll want to stage the debs in a place where users can't find them, install them on a bunch of VMs, run the tests, and only if they all pass move the debs to the public archive
[16:47:40] <seb_kuzminsky> bbl, work
[16:48:29] <cradek> I wish I could do something other than cheerlead you to help with that
[16:49:12] <skunkworks> heh - join the club...
[16:49:43] <cradek> especially with so many better and more-attractive cheerleaders around
[16:50:24] <skunkworks> cradek, thanks for noticing!
[16:53:19] -!- mackerski has quit [Quit: mackerski]
[16:55:57] -!- sumpfralle has quit [Quit: Leaving.]
[16:56:06] <zultron> seb_kuzminsky, this is the day I've dreamt about: just wish for something, and plop, have it land in a public git repo!
[16:57:57] <zultron> I think it's ok to make failed debs accessible so devs can grab them for further scrutiny. It makes sense not to move them to e.g. a 'bleeding edge' debian archive, of course.
[16:59:25] <cradek> I think I agree with that
[17:00:30] <cradek> failures in installed but not in rip runtests are going to be rare
[17:01:39] -!- thomaslindstr_m has quit [Quit: Leaving...]
[17:02:26] <zultron> Ought to be rare, but I'm not so sure with this schizophrenic build system.
[17:04:30] <zultron> I'll try to compose an email to emc-dev about that so that it doesn't look like I'm just ranting. (Or maybe looks like I'm ranting more?)
[17:05:09] <cradek> I guess you've waded in it the most recently
[17:05:41] <cradek> to be honest, I wasn't sure if you were making a joke when you said you were 80% done reimplementing it (a joke about the 80/20 rule)
[17:06:42] <cradek> at work for a while here we printed and posted 80% awards (looked like a pie chart) for badly or incompletely-implemented things
[17:06:59] <cradek> we stopped when we saw customers wondering what they meant
[17:07:01] <zultron> It's not a joke that I did reimplement a lot of it a year ago, but mothballed it.
[17:07:31] <zultron> Yeah, I definitely did the 20% to get 80% there. :)
[17:09:03] <cradek> to my memory, the recursion due to kbuild limitations is the ickiest part of what we have now
[17:09:18] <zultron> Really, though, it's not that I think we ought to throw out autoconf for cmake, but that we ought to throw out EMC2_HOME and differently-built RIP builds.
[17:09:18] <cradek> and I don't think you can fix that...?
[17:10:21] <zultron> No, I think my kbuild hack is along the right lines, with one exception. That's not the big problem.
[17:10:33] <cradek> oh you want to stop having RIP? that would be a hard sell (you're not the first to try to convince people of this)
[17:11:03] <cradek> sorry, I'm not familiar with your kbuild hack
[17:11:24] <zultron> Well, I think RIP builds should be like all builds, but with ${prefix} set to the source directory, or similar.
[17:11:48] <cradek> what kinds of problems does that solve?
[17:11:54] <zultron> And that sort of RIP build should be made to continue working for all of us.
[17:13:17] <zultron> Well, it would make it much harder to make a change to the build system that would break system installs but not RIP builds, for one.
[17:14:00] <cradek> that's true, since you'd have something like an install step
[17:14:25] <seb_kuzminsky> i think it's a good goal, i don't know enough about our build system to know how easy it would be to do
[17:14:26] <zultron> There's that awful recursion problem (that I don't know how to fix right now) that's bitten both me (badly) and Seb, and necessitates a bunch of ugliness.
[17:14:37] <cradek> what recursion problem?
[17:15:02] <zultron> Sorry, the single expansion of e.g. ${prefix} in autoconf.
[17:15:40] <cradek> oh you're talking about autoconf limitations, not make limitations
[17:15:40] <zultron> That normally expands to ${exec_prefix}, which then expands to '/usr'.
[17:15:57] <cradek> I'm much less familiar with autoconf than with make
[17:16:31] -!- mackerski has quit [Quit: mackerski]
[17:16:56] <zultron> Yes, and also why RIP builds, which don't use a lot of autoconf variables, can work perfectly at the same time system installs are badly broken.
[17:17:41] <cradek> but this is orthogonal to replacing make with cmake, right?
[17:17:54] <cradek> I thought that's what you were talking about
[17:17:55] <zultron> There's also the matter of portability, which I realize I'm one of about two who has expressed interest in recently.
[17:18:23] <cradek> or does cmake have autoconf-replacing features?
[17:18:29] <zultron> Yeah, from above: <zultron> Really, though, it's not that I think we ought to throw out autoconf for cmake, but that we ought to throw out EMC2_HOME and differently-built RIP builds.
[17:18:59] <zultron> cmake could replace autoconf, but autoconf is fine, as long as it's used as intended.
[17:19:25] <cradek> ok then I truly don't know what cmake is
[17:19:37] <zultron> It's an autoconf alternative.
[17:19:49] <cradek> autoconf is "run some tests, including some test compiles, and set some variables accordingly"
[17:20:04] <cradek> ok, I thought it was a make alternative, that is the root of my misunderstanding
[17:20:35] <zultron> Yeah, I thought the same before using it on another project.
[17:21:26] <zultron> It generates Makefiles, as autoconf does (esp. when using Makefile.ac), and then the user runs regular GNU make to build from them.
[17:21:30] <cradek> in a project does it replace both (say) autoconf and gnu-make? or do you use cmake like autoconf, and then still regular make to build?
[17:21:42] <cradek> ok you answered my question while I was typing it
[17:21:45] <zultron> :)
[17:22:25] <zultron> Anyway, my impression with emc2 is that there must have been an original, non-autoconf build system that centered around EMC2_HOME.
[17:22:28] <cradek> thanks for the new understanding, if you propose something on the list I'll go read more with an open mind.
[17:23:14] <zultron> I'm not going to propose cmake, just that there are big problems with the current system that will take a refactor to fix.
[17:23:17] <cradek> yes autoconf was added in emc2 days, as was the single nonrecursive (except for kbuild, later) make build
[17:24:10] <cradek> also automatic dependency generation
[17:24:44] <zultron> That's what I suspected. And EMC2_HOME is similar to ${prefix} in many cases, so instead of rewriting everything to be more autoconf-like, it was sort of mashed together.
[17:25:38] <zultron> And the Makefile.ac stuff was never used at all, since the original Makefile was adapted.
[17:26:40] <zultron> That should be 'Makefile.am' and 'configure.ac'. :)
[17:26:53] <cradek> well I think at the time (or still?) autoconf/automake built a recursive-make based system, which is problematic, and we smartly avoided that because we'd been down that painful road already
[17:28:01] <zultron> I admit I don't know much about automake (but know more than I wish about autoconf!).
[17:29:06] <cradek> if it builds recursive makefiles (and I don't nkow if it still does) I am totally against using it
[17:29:24] <cradek> that would be 10 steps backward
[17:29:46] <zultron> Sure.
[17:30:21] * zultron isn't sure whether he should bring up that UBC3 introduces a level of recursion for 'make modules'....
[17:30:41] <cradek> because kbuild?
[17:30:55] <cradek> we do have that one recursion and I think it's unavoidable
[17:31:51] <zultron> No, one recursion for each make modules threads=${flavor}.
[17:32:05] Guest58384 is now known as Reventlov
[17:32:16] -!- Reventlov has quit [Changing host]
[17:32:21] <cradek> hmm I don't like the sound of that...
[17:33:11] <zultron> Take a look at Makefile.inc. The idea is that ${threads} controls which of those enumerated flavor variables are selected.
[17:33:38] <cradek> did you manage to dependencies work?
[17:33:48] <cradek> to have
[17:33:51] <cradek> (jeez can't type)
[17:34:12] <zultron> You're more familiar with make than I am, so maybe you can suggest how the 'modules' target can be replicated once per flavor with the right ${threads} variable set.
[17:34:28] <zultron> Yeah, dependencies work.
[17:35:53] -!- jnaour has quit [Remote host closed the connection]
[17:36:55] <zultron> Anyway, I gotta run.
[17:37:21] <zultron> But please take a look. I think everything's plumbed well enough that it shouldn't be a big deal to remove the recursion for someone who's better with make.
[17:37:40] <cradek> ok, will do
[17:47:49] -!- frahtos has quit [Quit: Konversation terminated!]
[17:50:09] -!- Jeebiss has quit [Ping timeout: 272 seconds]
[17:51:00] <linuxcnc-build> build #27 of deb-precise-xenomai-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-amd64/builds/27 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[17:51:04] <cradek> I don't think dependencies are right in ubc3. touching hal_parport.h causes nothing to be rebuilt -- it should rebuild hal_parport, hal_ppmc, hm2_7i43, pluto_*
[17:51:08] <linuxcnc-build> build #27 of deb-precise-xenomai-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-xenomai-binary-x86/builds/27 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[17:51:28] <cradek> this works on my glacially slow master+rtai test machine
[17:52:05] <linuxcnc-build> build #27 of deb-precise-rtpreempt-binary-x86 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-x86/builds/27 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[17:52:07] <linuxcnc-build> build #27 of deb-precise-rtpreempt-binary-amd64 is complete: Failure [4failed apt-get-update shell_2] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-precise-rtpreempt-binary-amd64/builds/27 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[17:53:25] <cradek> also, in master+sim I'm getting hal_parport.so built, which is wrong, but I guess a separate problem
[17:53:49] <zultron> cradek, I assume that's a kernel flavor?
[17:54:03] <cradek> I don't understand
[17:54:20] <zultron> Read my mind better! ;)
[17:54:24] <zultron> You wrote: touching hal_parport.h causes nothing to be rebuilt -- it should rebuild hal_parport, hal_ppmc, hm2_7i43, pluto_*
[17:54:39] <zultron> Are you building a kernel-threads flavor?
[17:55:04] <zultron> (It may not make a difference for your problem, but I'm collecting data)
[17:55:05] <cradek> um I'm not sure. this is not a special kernel at all.
[17:55:15] <cradek> how do I find the answer to your question?
[17:55:34] <zultron> No, that's a fine answer. Let me think.
[17:55:37] -!- dway has quit [Quit: NOOOOOOooooooooo……]
[17:57:07] <cradek> I am getting rtlib-posix and rtlib-rtpreempt
[17:57:29] <cradek> spelled correctly: rtlib/posix and rtlib/rt-preempt
[17:58:05] <cradek> Making modules for flavor posix
[17:58:08] <cradek> Making modules for flavor rt-preempt
[17:58:43] <cradek> also, touching hal/components/streamer.h does not cause any of those modules to relink
[17:58:47] <zultron> So, this might actually be related to the 'hack'. To confirm/deny, which hal_parport.h are you touching?
[17:58:56] <cradek> I don't think dependencies are right across this recursion at all
[17:59:17] <zultron> So not objects/<something>/hal/hal_parport.h, correct?
[17:59:21] <cradek> src/hal/hal_parport.h
[17:59:26] <cradek> right
[18:01:10] <cradek> Reading 0/161 realtime dependency files
[18:01:10] <cradek> Done reading realtime dependencies
[18:01:32] <cradek> heh, this is a bit of a smoking gun isn't it
[18:01:49] <zultron> Ok, yes, my hack shouldn't affect that, so you're right, broken deps.
[18:02:00] <cradek> I will try to look harder at this after lunch
[18:03:14] <zultron> Ok, thanks. Kernel thread flavors need to be investigated separately as well, to be sure the kbuild hack is doing the right thing.
[18:04:10] <cradek> I think I don't have the setup to do that - I need to get me some more hardware
[18:08:48] -!- lyzidiamond has quit [Quit: lyzidiamond]
[18:14:32] <zultron> Just install a kernel -devel or -headers package. No need to actually run, just build.
[18:15:24] <zultron> Should be if you touch hal/hal_parport.h, all flavors of modules will be updated.
[18:15:25] -!- md-2 has quit [Quit: Leaving...]
[18:15:54] <zultron> My fear is that even if we fix the userland flavors, that kthreads may remain broken.
[18:21:19] -!- gimps_ has quit [Client Quit]
[18:29:16] -!- tinkerer has quit [Quit: Leaving.]
[18:36:27] -!- crank has quit [Ping timeout: 260 seconds]
[18:39:50] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/ubc3-deb e46eddd 06linuxcnc 10debian/rules.in linuxcnc-test.deb: don't compress or clear execute permissions on the tests * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e46eddd
[18:44:46] -!- amiri_ has quit [Quit: leaving]
[18:44:53] -!- rob_h has quit [Ping timeout: 272 seconds]
[18:48:50] <linuxcnc-build> build #1318 of deb-lucid-rt-binary-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/deb-lucid-rt-binary-i386/builds/1318 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[18:54:54] -!- dgarr [dgarr!~dgarrett@184.101.133.27] has joined #linuxcnc-devel
[19:00:18] <cradek> arg, stupid rsyslog
[19:00:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05xhc-hb04 18d1047 06linuxcnc 10(7 files) this is the contents of the tarball fredercic rible sent me * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=18d1047
[19:00:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05xhc-hb04 3ad76bc 06linuxcnc 03src/hal/user_comps/xhc-hb04.cc xhc-hb04 driver by Frederic Rible * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3ad76bc
[19:00:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05xhc-hb04 f50897a 06linuxcnc 10debian/control.in 10src/Makefile.inc.in 10src/configure.in 10src/hal/user_comps/Submakefile xhc-hb04: integrate with build system * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f50897a
[19:00:47] <KGB-linuxcnc> 03Sebastian Kuzminsky 05xhc-hb04 81f031a 06linuxcnc 10src/hal/user_comps/xhc-hb04.cc xhc-hb04: updates so it compiles in-tree * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=81f031a
[19:00:51] <KGB-linuxcnc> 03Sebastian Kuzminsky 05xhc-hb04 24f5eac 06linuxcnc 10src/hal/user_comps/xhc-hb04.cc xhc-hb04: simplify #include now that include path is set correctly * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=24f5eac
[19:01:03] <cradek> rules like $FileCreateMode apply not per file, but for the whole system, including later-included files
[19:01:25] <cradek> so you can't usefully use the rsyslog.d directory because they influence one another
[19:01:52] <cradek> same for log rate limiting, which we've disabled for all system logs, which is a bad idea
[19:02:38] <seb_kuzminsky> crap
[19:03:04] <cradek> I found this because I can't read the linuxcnc log file on my debian system (ALL log files written by syslog are 0640 group adm)
[19:03:30] <cradek> which of course is stupid -- only some of them should be protected from being read by users like that
[19:04:03] <seb_kuzminsky> the ubc debs install the (broken, it sounds like) rsyslogd.conf file, but do not restart the rsyslog service
[19:04:12] <seb_kuzminsky> i still need to add that to a postinst script
[19:04:46] <cradek> well it's not our fault, but yeah it seems like logging by rsyslog is not going to work easily/well
[19:05:12] <cradek> there's something about advanced rulesets I'm trying to decipher
[19:08:06] <cradek> $FileCreateMode may be specified multiple times. If so, it specifies the creation mode for all selector lines that follow until the next $FileCreateMode directive. Order of lines is vitally important.
[19:08:23] <cradek> I suspect someone added directory.d/ handling without thinking any of this through
[19:10:26] <cradek> traditional syslog refuses to create logfiles, so it's up to you to set permissions and maintain them correctly with logrotate etc
[19:13:15] <cradek> lucid also uses 0640/adm so will have unreadable logfiles
[19:15:17] -!- tronwizard has quit [Ping timeout: 248 seconds]
[19:16:39] -!- gonzo__ has quit [Ping timeout: 260 seconds]
[19:21:24] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[19:22:47] <skunkworks> is this what you're talking about?
http://static.mah.priv.at/public/html/common/UnifiedBuild.html#_preparing_linux_logging
[19:23:10] <cradek> yes related to that
[19:26:19] -!- skorasaurus has quit [Ping timeout: 272 seconds]
[19:31:13] -!- psha has quit [Quit: Lost terminal]
[19:32:37] <linuxcnc-build> build #1708 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1708 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:33:38] -!- tjtr33 has quit [Read error: Connection reset by peer]
[19:35:09] -!- skorasaurus2 has quit [Read error: Operation timed out]
[19:37:06] -!- terabyte- has quit [Quit: terabyte-]
[19:37:22] <linuxcnc-build> build #1709 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1709 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:38:43] -!- chillly has quit [Ping timeout: 272 seconds]
[19:41:19] <cradek> rsyslog has encryption and databases but you can't set a logfile's permissions
[19:41:22] <cradek> it's absurd
[19:45:22] -!- rob_h [rob_h!~robh@90.203.219.139] has joined #linuxcnc-devel
[19:45:32] <seb_kuzminsky> that lucid-amd64-sim failure is due to the posix threads preemption change that ubc introduced
[19:45:51] <seb_kuzminsky> michael said he has a fix in some other branch, i've asked him to push it to ubc but he hasn't yet
[19:51:31] <cradek> I don't think I can fix the syslog problems. There might be a new kind of rules that would work in rsyslog v7, but debian7 uses v5 and u10 uses v4
[19:52:53] <cradek> many other programs just punt and write their log files directly (apache, apt, cups, dpkg, exim, ntp, samba, xorg, surely more)
[19:53:05] <cradek> I guess we should probably just do that
[19:53:20] -!- skunkworks has quit [Quit: Leaving]
[19:53:24] <cradek> I suppose nobody is going to want to remotely log linuxcnc messages
[19:54:33] -!- garfong has quit [Ping timeout: 265 seconds]
[20:04:50] <zultron> I really don't like packages messing with my syslog settings, anyway. I understand the purpose here is to give newbies a default that captures debug information.
[20:05:35] <zultron> msgd might be able to write log files....
[20:06:28] -!- lyzidiamond has quit [Quit: lyzidiamond]
[20:06:44] <cradek> I was also not sure syslog was the right approach for linuxcnc, but I didn't want to paint that particular bike-shed.
[20:07:03] -!- paideia has quit [Ping timeout: 260 seconds]
[20:07:15] <cradek> to me rsyslogd looks pretty broken, and that really makes me grumble
[20:07:53] <cradek> they added a zillion features but broke things traditional syslog has done right forever
[20:07:57] <zultron> msgd would have to be taught to write log files, looks like. But at least that's possible now that kmods send their messages to user space.
[20:09:02] <cradek> well wait, I take that back, it's only the 80%-done directory.d/ support that really breaks it
[20:10:33] <zultron> The 20%-undone that breaks 80% of users? ;)
[20:11:01] <cradek> pretty much
[20:11:18] <cradek> but I'd argue having all the system log files unreadable by users is broken for 100% of users
[20:11:37] <cradek> oh well
[20:11:58] <cradek> I meant to work on make, and got stuck on this crap instead
[20:12:14] <cradek> (the make was printing a warning about my logs every invocation)
[20:16:02] -!- terabyte- has quit [Quit: terabyte-]
[20:23:28] <zultron> I agree about unreadable logs. Worse, on newer Fedora releases, logs aren't even group-readable. That just encourages newbies to run around as root all the time.
[20:24:00] <zultron> (and me, too. :P)
[20:26:29] <seb_kuzminsky> should we open a bug ticket for this rsyslogd problem?
[20:26:44] <seb_kuzminsky> and the dependency rebuild thing too i guess
[20:27:32] <cradek> probably yes to both
[20:29:12] <cradek> for the dependency thing I'm not sure what the way forward is - ideally we'd avoid the new recursions, so I'd hesitate to spend effort on fixing the current setup, but if that's easier I wouldn't call the recursion a show-stopper.
[20:29:19] -!- jbr has quit [Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]]
[20:29:36] -!- KimK has quit [Ping timeout: 252 seconds]
[20:29:54] <cradek> sorry that was not very clear
[20:31:26] -!- KimK [KimK!~Kim__@ip24-255-223-153.ks.ks.cox.net] has joined #linuxcnc-devel
[20:34:12] -!- Blorb has quit [Ping timeout: 252 seconds]
[20:35:00] -!- skorasaurus2 has quit [Ping timeout: 245 seconds]
[20:37:21] -!- Jeebiss has quit [Ping timeout: 272 seconds]
[20:43:08] -!- terabyte- has quit [Quit: terabyte-]
[21:02:46] -!- wboykinm has quit [Remote host closed the connection]
[21:03:23] -!- ekolojik has quit [Changing host]
[21:11:24] -!- terabyte- has quit [Quit: terabyte-]
[21:12:16] -!- wboykinm has quit [Remote host closed the connection]
[21:18:08] -!- heathmanc has quit [Ping timeout: 245 seconds]
[21:20:58] -!- zumba_addict has quit [Quit: zumba_addict]
[21:28:08] -!- heathmanc_ has quit [Ping timeout: 245 seconds]
[21:28:43] -!- skorasaurus2 has quit [Ping timeout: 260 seconds]
[21:38:57] -!- lyzidiamond has quit [Quit: lyzidiamond]
[21:46:42] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:55:31] -!- motioncontrol has quit [Quit: Sto andando via]
[22:06:39] -!- FinboySlick has quit [Quit: Leaving.]
[22:07:14] -!- lyzidiamond has quit [Quit: lyzidiamond]
[22:07:18] -!- heathmanc has quit [Ping timeout: 245 seconds]
[22:17:49] -!- zumba_addict has quit [Quit: zumba_addict]
[22:19:18] -!- jbr has quit [Ping timeout: 245 seconds]
[22:19:27] <skunkworks> logger[mah]:
[22:19:27] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-01-24.html
[22:26:18] -!- Deejay has quit [Quit: bye]
[22:26:41] -!- toxx has quit [Read error: Operation timed out]
[22:30:43] -!- wboykinm has quit [Remote host closed the connection]
[22:32:50] -!- Tecan has quit [Ping timeout: 252 seconds]
[22:34:13] -!- chillly has quit [Quit: Leaving]
[22:44:29] -!- Tecan has quit [Changing host]
[22:56:25] -!- crank has quit [Remote host closed the connection]
[23:02:57] -!- cwmma has quit [Quit: cwmma]
[23:03:40] thomasli_ is now known as thomaslindstr_m_
[23:04:23] -!- jthornton_ [jthornton_!~john@75.106.20.181] has joined #linuxcnc-devel
[23:04:24] -!- jthornton has quit [Read error: Connection reset by peer]
[23:05:50] -!- thomaslindstr_m has quit [Ping timeout: 245 seconds]
[23:17:17] -!- syyl-- has quit [Read error: No route to host]
[23:19:51] -!- `Nerobro has quit [Quit: Leaving]
[23:37:13] -!- micges [micges!~captain_p@aboz52.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[23:38:39] -!- Tom_L has quit [Changing host]
[23:39:16] -!- Tom_L has quit [Client Quit]
[23:49:52] -!- ekolojik has quit [Quit: Konversation terminated!]