Back
[00:10:03] <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....
[00:12:34] <KimK> Hi zultron, thanks for the insight. Sorry if that seemed like a rant earlier.
[00:14:18] <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.
[00:18:45] <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.
[00:20:42] <zultron> Yeah, I've used that trick too! Agh. Or yellow on white, that bugs you non-colorblind folk too, right?
[08:14:27] <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
[08:51:58] <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>
[08:53:17] <mozmck> heh, seb_kuzminsky, your build is a complete: Failure!
[08:55:40] <skunkworks> I always read it that way too :)
[09:07:00] <zultron> seb_kuzminsky, can comps be compiled from the installed .deb packages?
[09:07:35] <cradek> the -dev package lets you build comps, external guis, etc
[09:07:44] <zultron> Love Austin: 1/2" of snow, and both the university and school district call off classes!
[09:07:57] <zultron> Thanks, cradek.
[09:08:50] <cradek> anytime (the question is easy enough)
[09:09:49] <zultron> I'm idly wondering how hard it would be to run unit tests against packages.
[09:10:30] <cradek> you mean our existing tests? that's only a packaging problem, isn't it? they just run sai and hal and stuff.
[09:13:17] <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>
[09:13:52] <zultron> Yeah, existing tests. Hope it's just a packaging problem. There was some other problem I've forgotten after this minor fix:
[09:13:55] <zultron> https://github.com/zultron/linuxcnc/commit/d0dcbacee503fa0f2756a43e73d76d6cea706075
[09:14:44] <zultron> (That's not a general fix, more of a proof of concept)
[09:15:09] <cradek> I didn't realize some of them compile
[09:15:17] <zultron> Just ones with comps.
[09:15:19] <cradek> perhaps that test could use comp, which knows paths already
[09:15:33] <zultron> Ah ha!
[09:16:17] <cradek> or (with more infrastructure changes) you could build the test correctly when making the package
[09:16:35] <cradek> but if you use comp, you get the side benefit of testing comp
[09:16:44] <zultron> Yeah, that would be ok, but I like your comp idea.
[09:17:49] <cradek> maybe: comp --compile --userspace bitops.c
[09:18:46] <cradek> (I wonder how many people in the world are still using mh)
[09:35:59] <skunkworks> mh?
[09:40:37] <cradek> sorry, there are connections that are only obvious in my own head
[09:40:51] <zultron> Wasn't there a mail client by that name?
[09:40:55] <cradek> mh is an old mail user agent that was popular(?) in the early 90s(?)
[09:41:12] <cradek> comp is the name of the program in mh that you'd use to send (compose) an email
[09:41:24] <skunkworks> heh
[09:41:26] <cradek> so that conflicts with our program comp
[09:42:13] <cradek> you'd need to have been using unix a pretty long time to know to avoid using the name "comp" for your program...
[09:44:59] <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.
[09:46:01] <cradek> the modern maildir takes the primary ideas of mh, which are now a lot more appropriate
[09:46:57] <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
[09:47:26] <cradek> but today with huge mailboxes (attachments) it's a big win
[09:49:46] <zultron> ext fs inodes are still determined at mkfs time, no? What fs do you use for your maildirs?
[09:49:58] <cradek> zfs
[09:50:13] <cradek> ext4 can't expand inodes? doh.
[09:50:33] <zultron> Not automatically, I don't think.
[09:50:36] <cradek> over time I'm having less and less patience for anything but zfs
[09:51:05] <zultron> Does zfs come standard on most distros?
[09:51:16] <cradek> on freebsd yes, on linux not really
[09:51:35] <skunkworks> isn't there major bugs with it on everyting but bsd?
[09:51:43] <zultron> I take it you're using freebsd, at least at work.
[09:52:00] <cradek> zfs is not gpl compatible so linux people have to jump through hoops, so consequently support is poor
[09:52:30] <cradek> yes my important servers are freebsd at work and at home both
[09:52:51] <cradek> have been for a very long time
[09:52:56] <zultron> Nice.
[09:53:07] <cradek> I wouldn't use anything else
[09:53:26] <cradek> git.linuxcnc.org is freebsd
[09:54:45] <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.
[09:55:01] <cradek> it's sure easy to get used to a distro
[09:55:48] <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
[09:58:02] <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.
[10:00:29] <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....
[10:01:17] <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)
[10:01:43] <zultron> I'm generally quite impressed with Debian, except for partman in the installer.
[10:01:45] <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
[10:02:30] <zultron> Yeah, we have yum now, much better. But actually apt seems a lot faster, which is a big pain of yum.
[10:03:02] <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.
[10:03:28] <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
[10:03:30] <cradek> so it boots from PXE and does the full install with no input
[10:03:41] <cradek> ooh, yuck
[10:04:05] <zultron> If you preseed the installer, then you're using partman to partition the disks, albeit in an automated mode.
[10:04:11] <cradek> right
[10:04:28] <cradek> also I'm using lvm, so it's a step more tricky
[10:04:30] <zultron> Try preseeding a dual boot installation sometime.
[10:04:44] <cradek> I have no interest in dual boot systems :-)
[10:04:59] <cradek> they're for wishy-washy people and I'm not one, haha.
[10:05:18] <zultron> I don't normally, but I wanted to set up a lab to test linuxcnc on real hardware.
[10:06:38] <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.
[10:06:59] <zultron> That also causes problems if you want to reinstall the OS, but keep a data partition.
[10:07:31] <cradek> preseeding an install to keep some partitions and nuke others seems both hard and risky
[10:07:44] <zultron> It's definitely hard on Debian. ;)
[10:07:52] <cradek> you could preseed everything but partitioning, so it would stop and do that step manually
[10:09:09] <zultron> You mean with a human at the console? Or escaping to some sort of script?
[10:09:10] <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?
[10:09:19] <zultron> (I guess the latter isn't technically 'manual')
[10:09:35] <cradek> you could do either - I think there is escape-to-script ability but I'm not sure
[10:10:02] <cradek> maybe extN does keep track of "last mounted on" and you could pay attention to that
[10:10:55] <zultron> Well, in Anaconda, the partition specification can include a '--onpart=sdc3' argument.
[10:11:55] <zultron> Anaconda can also reuse LVM volume groups and mount existing logical volumes.
[10:12:00] <cradek> oh you mean you know where all the partitions are already, and you write the rules for one particular machine
[10:12:08] <zultron> Yeah.
[10:12:15] <cradek> surely preseed/partman can do that!
[10:12:38] <zultron> It can't. Surprised me, too.
[10:13:18] <cradek> bizarre
[10:13:31] <zultron> I ended up hacking it to do so. The debian installer devs told me that partman has been unmaintained for many years.
[10:14:09] <zultron> I suppose that's to its credit that its design is solid enough to not need major maintenance in the meantime.
[10:14:34] <cradek> I'm surprised it even handles lvm then
[10:15:03] <zultron> It does, but it handles it the same way, by wiping everything.
[10:15:30] <cradek> haha, the end of partman-auto-recipe.txt has advice for minimal sizes in 2004
[10:15:44] <zultron> Note that partman *can* set up dual-boot systems in manual mode; this is just something missing from the partman-auto portion.
[10:16:41] <cradek> does debian not have gpt support yet?
[10:17:35] <zultron> I don't know about that. Not much of my hardware is that new. ;)
[10:17:55] <cradek> heh I know that feeling
[10:18:19] <cradek> and the only big disks I have are in freebsd systems (which of course supports gpt)
[10:19:43] <zultron> Is gpt needed at all by non-EFI machines?
[10:20:04] <zultron> I guess for >2TB partitions.
[10:20:09] <cradek> I think it's more a very big disk thing
[10:20:18] <cradek> yeah
[10:20:33] <cradek> there might be non-gpt workarounds for those disks but it's probably sucky
[10:21:02] <cradek> I have bee able to totally avoid UEFI so far
[10:21:17] <cradek> been
[10:21:50] <zultron> My understanding (with no experience) is msdog partition tables can handle >2TB disks, but partitions must be smaller than 2TB.
[10:22:10] <cradek> aha
[10:22:28] <zultron> So if you're using LVM, the workaround isn't too sucky.
[10:22:47] <cradek> heh I remember lots and lots of 32MB dos partitions
[10:22:51] <cradek> some things never change
[10:23:10] <zultron> That may be wrong, though, that >2TB disks are ok.
[10:24:27] <zultron> I sort of remember that, but luckily never really had to work on M$ systems.
[10:24:55] <cradek> I can't find a disk size limit with zfs, but the maximum size of a pool is supposedly 256 zebibytes
[10:25:42] <zultron> Which is the 'z' in 'zfs', is that right?
[10:25:44] <cradek> single file, 16 exbibytes
[10:26:36] <cradek> I am not sure what the Z stands for
[10:31:03] <cradek> (looks like debian partman can do gpt)
[10:37:37] <zultron> I was actually looking at what freebsd RT capabilities exist a few days ago, but couldn't find anything concrete.
[10:37:56] <zultron> (Lucky thing, since a LinuxCNC port would require the project be renamed.)
[10:38:20] <skunkworks> Because if has linux in the name?
[10:39:42] <zultron> Yep! j/k, j/k!
[10:39:52] <skunkworks> heh
[10:45:42] <cradek> zultron: yeah, I don't know of any
[10:46:03] <cradek> zultron: even if so, I don't think porting to freebsd would gain us anything important to justify the work
[10:46:40] <zultron> Isn't freebsd popular on embedded devices?
[10:46:58] <cradek> I guess I don't nkow
[10:46:59] <cradek> know
[10:47:31] <zultron> I don't either. Anyway, even if it were, Linux is too.
[10:47:35] <cradek> right
[10:48:23] <cradek> for a while, openbsd supported a wider number of platforms than anyone else, but I bet linux is catching up
[10:48:43] <cradek> you could run openbsd on your 68040 or your PA-RISC machine
[10:49:12] <seb_kuzminsky> zultron: about testing packages... i played a bit with that the other night (since i'm rototilling our packaging anyway)
[10:49:25] <zultron> Oh yeah? Cool!
[10:49:33] <seb_kuzminsky> a problem i ran into is that our runtests script pretty well expects to be in a rip directory
[10:49:54] <zultron> Yep.
[10:49:56] <seb_kuzminsky> it'll need to be fixed, and all our devs will need to learn to run (source ../scripts/rip-environment; runtests)
[10:49:59] <seb_kuzminsky> no biggie
[10:50:29] <seb_kuzminsky> bbl!
[10:51:44] <zultron> Wait, I didn't get the thing we'll need to learn. Looks similar to what we do now.
[10:55:04] <seb_kuzminsky> ok back, had to switch busses
[10:55:15] <pcw_home> Can anyone hazzard a guess as to why the latency test is borked in ubc? (at least in Preemt_RT)
[10:55:32] <seb_kuzminsky> pcw_home: if only zultron was here... oh wait!
[10:56:11] <seb_kuzminsky> zultron: i meant, devs will need to re-train their fingers to source rip-environment before running runtests, that's all
[10:56:38] <zultron> Umm, don't have a guess, but I can test it out. What're you seeing, pcw_home?
[10:57:02] <zultron> I see. I didn't realize that was optional anyway.
[10:57:14] <pcw_home> the max latency number goes down occasionally :-(
[10:57:45] <zultron> Wow, I certainly haven't heard of that before!
[10:58:15] <skunkworks> I have also seen this.. (only on rt_preempt..) it will pop up to sa 80us -then back down to 60us..
[10:58:23] <skunkworks> *say
[10:58:40] <zultron> Thanks for the report. I'll investigate.
[10:59:02] <zultron> logger[mah], bookmark, plz
[10:59:02] <logger[mah]> zultron: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-01-24.html
[11:01:21] <zultron> pcw_home, skunkworks, issue logged here:
https://github.com/zultron/linuxcnc/issues/72
[11:02:40] <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
[11:02:59] <cradek> amazing.
[11:03:34] <seb_kuzminsky> the bigger problem with this testing deb is all the changes we're going to need to our CI infrastructure
[11:04:06] <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
[11:04:10] <seb_kuzminsky> bbl, work
[11:04:58] <cradek> I wish I could do something other than cheerlead you to help with that
[11:05:42] <skunkworks> heh - join the club...
[11:06:12] <cradek> especially with so many better and more-attractive cheerleaders around
[11:06:53] <skunkworks> cradek, thanks for noticing!
[11:12:35] <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!
[11:14:27] <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.
[11:15:55] <cradek> I think I agree with that
[11:17:00] <cradek> failures in installed but not in rip runtests are going to be rare
[11:18:56] <zultron> Ought to be rare, but I'm not so sure with this schizophrenic build system.
[11:21:00] <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?)
[11:21:39] <cradek> I guess you've waded in it the most recently
[11:22:10] <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)
[11:23:11] <cradek> at work for a while here we printed and posted 80% awards (looked like a pie chart) for badly or incompletely-implemented things
[11:23:28] <cradek> we stopped when we saw customers wondering what they meant
[11:23:31] <zultron> It's not a joke that I did reimplement a lot of it a year ago, but mothballed it.
[11:24:00] <zultron> Yeah, I definitely did the 20% to get 80% there. :)
[11:25:33] <cradek> to my memory, the recursion due to kbuild limitations is the ickiest part of what we have now
[11:25:47] <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.
[11:25:48] <cradek> and I don't think you can fix that...?
[11:26:51] <zultron> No, I think my kbuild hack is along the right lines, with one exception. That's not the big problem.
[11:27:02] <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)
[11:27:32] <cradek> sorry, I'm not familiar with your kbuild hack
[11:27:54] <zultron> Well, I think RIP builds should be like all builds, but with ${prefix} set to the source directory, or similar.
[11:28:17] <cradek> what kinds of problems does that solve?
[11:28:24] <zultron> And that sort of RIP build should be made to continue working for all of us.
[11:29:47] <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.
[11:30:29] <cradek> that's true, since you'd have something like an install step
[11:30:55] <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
[11:30:56] <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.
[11:31:06] <cradek> what recursion problem?
[11:31:32] <zultron> Sorry, the single expansion of e.g. ${prefix} in autoconf.
[11:32:09] <cradek> oh you're talking about autoconf limitations, not make limitations
[11:32:10] <zultron> That normally expands to ${exec_prefix}, which then expands to '/usr'.
[11:32:26] <cradek> I'm much less familiar with autoconf than with make
[11:33:25] <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.
[11:34:10] <cradek> but this is orthogonal to replacing make with cmake, right?
[11:34:24] <cradek> I thought that's what you were talking about
[11:34:25] <zultron> There's also the matter of portability, which I realize I'm one of about two who has expressed interest in recently.
[11:34:52] <cradek> or does cmake have autoconf-replacing features?
[11:34:58] <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.
[11:35:28] <zultron> cmake could replace autoconf, but autoconf is fine, as long as it's used as intended.
[11:35:55] <cradek> ok then I truly don't know what cmake is
[11:36:06] <zultron> It's an autoconf alternative.
[11:36:18] <cradek> autoconf is "run some tests, including some test compiles, and set some variables accordingly"
[11:36:33] <cradek> ok, I thought it was a make alternative, that is the root of my misunderstanding
[11:37:04] <zultron> Yeah, I thought the same before using it on another project.
[11:37:55] <zultron> It generates Makefiles, as autoconf does (esp. when using Makefile.ac), and then the user runs regular GNU make to build from them.
[11:38:00] <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?
[11:38:11] <cradek> ok you answered my question while I was typing it
[11:38:14] <zultron> :)
[11:38:55] <zultron> Anyway, my impression with emc2 is that there must have been an original, non-autoconf build system that centered around EMC2_HOME.
[11:38:58] <cradek> thanks for the new understanding, if you propose something on the list I'll go read more with an open mind.
[11:39:43] <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.
[11:39:46] <cradek> yes autoconf was added in emc2 days, as was the single nonrecursive (except for kbuild, later) make build
[11:40:39] <cradek> also automatic dependency generation
[11:41:14] <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.
[11:42:08] <zultron> And the Makefile.ac stuff was never used at all, since the original Makefile was adapted.
[11:43:10] <zultron> That should be 'Makefile.am' and 'configure.ac'. :)
[11:43:23] <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
[11:44:31] <zultron> I admit I don't know much about automake (but know more than I wish about autoconf!).
[11:45:36] <cradek> if it builds recursive makefiles (and I don't nkow if it still does) I am totally against using it
[11:45:53] <cradek> that would be 10 steps backward
[11:46:15] <zultron> Sure.
[11:46:51] * zultron isn't sure whether he should bring up that UBC3 introduces a level of recursion for 'make modules'....
[11:47:10] <cradek> because kbuild?
[11:47:25] <cradek> we do have that one recursion and I think it's unavoidable
[11:48:21] <zultron> No, one recursion for each make modules threads=${flavor}.
[11:48:50] <cradek> hmm I don't like the sound of that...
[11:49:40] <zultron> Take a look at Makefile.inc. The idea is that ${threads} controls which of those enumerated flavor variables are selected.
[11:50:07] <cradek> did you manage to dependencies work?
[11:50:17] <cradek> to have
[11:50:20] <cradek> (jeez can't type)
[11:50:41] <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.
[11:50:58] <zultron> Yeah, dependencies work.
[11:53:25] <zultron> Anyway, I gotta run.
[11:53:51] <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.
[11:54:09] <cradek> ok, will do
[12:07:29] <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>
[12:07:33] <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_*
[12:07:37] <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>
[12:07:57] <cradek> this works on my glacially slow master+rtai test machine
[12:08:35] <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>
[12:08:36] <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>
[12:09:55] <cradek> also, in master+sim I'm getting hal_parport.so built, which is wrong, but I guess a separate problem
[12:10:19] <zultron> cradek, I assume that's a kernel flavor?
[12:10:32] <cradek> I don't understand
[12:10:50] <zultron> Read my mind better! ;)
[12:10:54] <zultron> You wrote: touching hal_parport.h causes nothing to be rebuilt -- it should rebuild hal_parport, hal_ppmc, hm2_7i43, pluto_*
[12:11:09] <zultron> Are you building a kernel-threads flavor?
[12:11:33] <zultron> (It may not make a difference for your problem, but I'm collecting data)
[12:11:34] <cradek> um I'm not sure. this is not a special kernel at all.
[12:11:44] <cradek> how do I find the answer to your question?
[12:12:04] <zultron> No, that's a fine answer. Let me think.
[12:13:37] <cradek> I am getting rtlib-posix and rtlib-rtpreempt
[12:13:58] <cradek> spelled correctly: rtlib/posix and rtlib/rt-preempt
[12:14:35] <cradek> Making modules for flavor posix
[12:14:38] <cradek> Making modules for flavor rt-preempt
[12:15:13] <cradek> also, touching hal/components/streamer.h does not cause any of those modules to relink
[12:15:17] <zultron> So, this might actually be related to the 'hack'. To confirm/deny, which hal_parport.h are you touching?
[12:15:25] <cradek> I don't think dependencies are right across this recursion at all
[12:15:46] <zultron> So not objects/<something>/hal/hal_parport.h, correct?
[12:15:50] <cradek> src/hal/hal_parport.h
[12:15:56] <cradek> right
[12:17:40] <cradek> Reading 0/161 realtime dependency files
[12:17:40] <cradek> Done reading realtime dependencies
[12:18:01] <cradek> heh, this is a bit of a smoking gun isn't it
[12:18:19] <zultron> Ok, yes, my hack shouldn't affect that, so you're right, broken deps.
[12:18:30] <cradek> I will try to look harder at this after lunch
[12:19:43] <zultron> Ok, thanks. Kernel thread flavors need to be investigated separately as well, to be sure the kbuild hack is doing the right thing.
[12:20:40] <cradek> I think I don't have the setup to do that - I need to get me some more hardware
[12:31:01] <zultron> Just install a kernel -devel or -headers package. No need to actually run, just build.
[12:31:54] <zultron> Should be if you touch hal/hal_parport.h, all flavors of modules will be updated.
[12:32:23] <zultron> My fear is that even if we fix the userland flavors, that kthreads may remain broken.
[12:56:20] <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
[13:05:20] <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>
[13:16:48] <cradek> arg, stupid rsyslog
[13:17:14] <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
[13:17:14] <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
[13:17:14] <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
[13:17:16] <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
[13:17:20] <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
[13:17:32] <cradek> rules like $FileCreateMode apply not per file, but for the whole system, including later-included files
[13:17:55] <cradek> so you can't usefully use the rsyslog.d directory because they influence one another
[13:18:21] <cradek> same for log rate limiting, which we've disabled for all system logs, which is a bad idea
[13:19:08] <seb_kuzminsky> crap
[13:19:33] <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)
[13:20:00] <cradek> which of course is stupid -- only some of them should be protected from being read by users like that
[13:20:33] <seb_kuzminsky> the ubc debs install the (broken, it sounds like) rsyslogd.conf file, but do not restart the rsyslog service
[13:20:41] <seb_kuzminsky> i still need to add that to a postinst script
[13:21:16] <cradek> well it's not our fault, but yeah it seems like logging by rsyslog is not going to work easily/well
[13:21:41] <cradek> there's something about advanced rulesets I'm trying to decipher
[13:24:36] <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.
[13:24:53] <cradek> I suspect someone added directory.d/ handling without thinking any of this through
[13:26:55] <cradek> traditional syslog refuses to create logfiles, so it's up to you to set permissions and maintain them correctly with logrotate etc
[13:29:44] <cradek> lucid also uses 0640/adm so will have unreadable logfiles
[13:39:17] <skunkworks> is this what you're talking about?
http://static.mah.priv.at/public/html/common/UnifiedBuild.html#_preparing_linux_logging
[13:39:40] <cradek> yes related to that
[13:49:07] <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>
[13:53:52] <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>
[13:57:48] <cradek> rsyslog has encryption and databases but you can't set a logfile's permissions
[13:57:51] <cradek> it's absurd
[14:02:02] <seb_kuzminsky> that lucid-amd64-sim failure is due to the posix threads preemption change that ubc introduced
[14:02:21] <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
[14:08:00] <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
[14:09:22] <cradek> many other programs just punt and write their log files directly (apache, apt, cups, dpkg, exim, ntp, samba, xorg, surely more)
[14:09:34] <cradek> I guess we should probably just do that
[14:09:53] <cradek> I suppose nobody is going to want to remotely log linuxcnc messages
[14:21:20] <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.
[14:22:04] <zultron> msgd might be able to write log files....
[14:23:13] <cradek> I was also not sure syslog was the right approach for linuxcnc, but I didn't want to paint that particular bike-shed.
[14:23:44] <cradek> to me rsyslogd looks pretty broken, and that really makes me grumble
[14:24:23] <cradek> they added a zillion features but broke things traditional syslog has done right forever
[14:24:27] <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.
[14:25:32] <cradek> well wait, I take that back, it's only the 80%-done directory.d/ support that really breaks it
[14:27:03] <zultron> The 20%-undone that breaks 80% of users? ;)
[14:27:31] <cradek> pretty much
[14:27:47] <cradek> but I'd argue having all the system log files unreadable by users is broken for 100% of users
[14:28:07] <cradek> oh well
[14:28:27] <cradek> I meant to work on make, and got stuck on this crap instead
[14:28:44] <cradek> (the make was printing a warning about my logs every invocation)
[14:39:58] <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.
[14:40:30] <zultron> (and me, too. :P)
[14:42:59] <seb_kuzminsky> should we open a bug ticket for this rsyslogd problem?
[14:43:14] <seb_kuzminsky> and the dependency rebuild thing too i guess
[14:44:02] <cradek> probably yes to both
[14:45:41] <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.
[14:46:24] <cradek> sorry that was not very clear
[16:35:57] <skunkworks> logger[mah]:
[16:35:57] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-01-24.html
[22:54:27] <KGB-linuxcnc> 03Dewey Garrett 05master dc00d06 06linuxcnc 10configs/sim/axis/ini_hal_pins.tcl 10src/emc/ini/inihal.cc 10src/emc/ini/inihal.hh ini: add hal pin for ini max_acceleration * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dc00d06