#linuxcnc-devel Logs

Jul 07 2017

10:24 AM KGB-linuxcnc: 03Jeff Epler 05master f841cbc 06linuxcnc 10debian/control.top.in packaging: bump standards-version * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f841cbc
10:26 AM KGB-linuxcnc: 03Jeff Epler 05master 017a304 06linuxcnc 10debian/compat packaging: bump debhelper compat level * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=017a304
10:26 AM KGB-linuxcnc: 03Jeff Epler 05master ddb14e9 06linuxcnc Merge branch 'freebsd2' of https://github.com/trasz/linuxcnc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ddb14e9
11:17 AM cradek: is there anything I can do to help with the git move?
11:20 AM jepler: cradek: I think seb_kuzminsky and I agreed informally that he would get 2.7.10 out before we started working in earnest on that
11:20 AM jepler: 2.7.10 being mainly for debian stretch support
11:22 AM seb_kuzminsky: i was hoping to hear back about a hy_vfd feature i did for Handy8000 on the forum, but i think i'm going to time out and just merge it
11:22 AM seb_kuzminsky: https://forum.linuxcnc.org/38-general-linuxcnc-questions/32903-huanyang-vfd-inverter-modbus-base-frequency?start=10
11:23 AM jepler: as far as the migration goes, I think we need to flesh out the steps more carefully, create a timeline, and post the timeline on the mailing list by later this month
11:24 AM seb_kuzminsky: i'm all for steps, but i'm wary of timelines
11:28 AM jepler: developers need to know the date we'll switch in advance, so that they can push to the right place
11:28 AM jepler: giving a fuzzy date is fine
11:29 AM jepler: "looks like this'll take about 8 hours" -> 2 weeks from now
11:29 AM jepler: hah this forum confirmation e-mail's first link says "DO NOT VISIT THE FOLLOWING LINK. IT WILL DELETE YOUR ACCOUNT. It is a protection against spammers"
11:30 AM seb_kuzminsky: that's pretty good :-)
11:31 AM seb_kuzminsky: i think my next step is to teach the buildbot to notice when we get a PR on github, and build it in some reduced way that never invokes sudo
11:31 AM seb_kuzminsky: then teach it to do full builds of anything pushed to our github repo, then turn off the building of stuff from glo
11:43 AM jepler: I think building PRs would be "cute" but I don't think it's a prerequisite to moving our git
11:43 AM jepler: it could be done before, during, or after
11:44 AM mozmck: hmm, lscpu -p shows 2 cores both having core id 0 on a pentium 4 pc
11:44 AM mozmck: But I bet I don't want to isolate both of them :-)
11:51 AM jepler: yeah your algorithm should never suggest isolating CPU 0
11:52 AM mozmck: yeah
11:53 AM mozmck: what cpu was it that had a higher top processor number than the number of cores with HT turned off?
11:54 AM seb_kuzminsky: jepler: you're right, it'd be a new feature, not a prereq for moving
11:54 AM seb_kuzminsky: we have travis for testing PRs
11:55 AM seb_kuzminsky: and travis even runs the tests, so that's good
11:56 AM seb_kuzminsky: the buildbot can test on multiple platforms...
11:56 AM seb_kuzminsky: ok, i'll focus on building new pushes to our main github instead
11:57 AM jepler: mozmck: on your AMD box I wonder if this does any better at finding the isolcpus numbers that are "related" units
11:57 AM jepler: $ for CPUSET in 0,11 5,11 10,11; do printf '%s ' $CPUSET; yes 50000 | head -2 | time -f '%U' taskset -c $CPUSET xargs -P4 -n1 python -mtest.pystone > /dev/null; done
11:57 AM jepler: fwiw I have https://github.com/LinuxCNC/linuxcnc/issues/289 where I would like to track github transition issues
11:58 AM jepler: you and cradek should consider it a whiteboard to add items or check off items
11:58 AM mozmck: jepler: if lscpu -p is accurate I would think that would be simpler? I'm trying it on different cpus to see if it seems accurate.
11:59 AM jepler: mozmck: oh I wasn't familiar with lscpu yet. what's its information saying?
11:59 AM mozmck: # CPU,Core,Socket,Node,,L1d,L1i,L2,L3
11:59 AM mozmck: 0,0,0,0,,0,0,0,0
11:59 AM mozmck: 1,0,0,0,,1,0,0,0
11:59 AM mozmck: 2,1,0,0,,2,1,1,0
11:59 AM mozmck: 3,1,0,0,,3,1,1,0
11:59 AM mozmck: 4,2,0,0,,4,2,2,0
11:59 AM mozmck: 5,2,0,0,,5,2,2,0
11:59 AM mozmck: 6,3,0,0,,6,3,3,0
11:59 AM mozmck: 7,3,0,0,,7,3,3,0
11:59 AM jepler: that's on your AMD?
11:59 AM mozmck: yes
12:00 PM jepler: so your algorithm would isolcpus=6,7 ?
12:00 PM mozmck: I believe so.
12:01 PM mozmck: 0,7 0.79
12:01 PM mozmck: 3,7 0.78
12:01 PM mozmck: 6,7 1.02
12:01 PM mozmck: Those are the numbers returned by your script after I modified it for 8 cores instead of 12
12:01 PM jepler: OK that result implies 6,7 share resources which matches lscpu
12:02 PM mozmck: Yes, and unlike the hackbench test, it is consistent across runs.
12:02 PM mozmck: what does lscpu -p show for you machine where 3,7 are "related" units?
12:06 PM jepler: 5,5,0,0,,5,5,5,0
12:06 PM jepler: 11,5,0,0,,5,5,5,0
12:06 PM linuxcnc-build: build #145 of 4025.deb-jessie-armhf is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4025.deb-jessie-armhf/builds/145 blamelist: Jeff Epler <jepler@unpythonic.net>, Edward Tomasz Napierala <trasz@FreeBSD.org>
12:06 PM jepler: $ lscpu -p | tac | awk -F, '{if(FNR==1) { lastcore=$2; block=$1; } else if($2 == lastcore) {block = block "," $1} } END {print block}'
12:06 PM jepler: 11,5
12:07 PM mozmck: hey! I am still a newbie at bash and awk, and have been reading up to figure out how to do that!
12:08 PM jepler: I'm a showoff
12:08 PM jepler: want me to walk you through it?
12:08 PM mozmck: Well, that will help me, and yes, a walk through would be nice!
12:08 PM Tom_itx: jepler, you do this stuff for a living don't you?
12:08 PM jepler: tac reverses lines (it's cat backwards), so the first line awk will see is the last (highest numbered) one
12:08 PM jepler: Tom_itx: write awk scripts? not exactly
12:09 PM mozmck: Does it matter if isolcpus has them in 11,5 order instead of 5,11?
12:09 PM jepler: mozmck: I don't *think* so
12:09 PM jepler: -F, makes awk split "words" on commas instead of whitespace, and $1 $2 etc have the shell-like meaning of 1st word, 2nd word etc
12:09 PM jepler: so $1 gets the CPU and $2 gets the core
12:10 PM jepler: FNR counts the line number within the input file and starts with 1, so on the first line we store the last core number in a variable, and put that CPU number as the first item in the list of cpus
12:10 PM jepler: otherwise if the core number matches, we add it on to the list. awk concatenates just by putting strings next to each other
12:10 PM jepler: at the END of the whole input, we just print the list of stuff to block
12:11 PM mozmck: Ok, I think I follow that.
12:11 PM jepler: $ lscpu -p | tac | awk -F, '{if(FNR==1) { lastcore=$2; block=$1 } else if($2 == lastcore) { block = $1 "," block } } END {print "isolcpus=" block}'
12:12 PM jepler: this one puts them in the opposite order and prepends isolcpus= to be helpful
12:12 PM jepler: does that one print 6,7 on your AMD?
12:12 PM mozmck: It does
12:12 PM mozmck: That's great!
12:14 PM jepler: the case of having just 1 or 2 threads needs work
12:16 PM mozmck: yes, I think I can probably figure that one out. using tac is neat - I was planning on doing a compare and looking for the highest number in $1, then going back through $2 looking for another one of those.
12:19 PM mozmck: lscpu -p | tac | awk -F, '{if(FNR==1) { lastcore=$2; block=$1 } else if($2 == lastcore && $1 != 0) { block = $1 "," block } } END {print "isolcpus=" block}'
12:21 PM mozmck: That works to eliminate core 0 from isolcpus - but I guess that might not work if some cpu has 0,7 or similar. I bet it is only needed for cpus with 2 cores.
12:24 PM jepler: $ lscpu -p | head -6 | tac | awk -F, '{if(FNR==1) { if($2==0) { print "# Only one core, cannot use isolcpus"; exit 1; } print "X"; lastcore=$2; block=$1 } else if($2 == lastcore && $1 != 0 ) { block = $1 "," block } } END {print "isolcpus=" block }'
12:24 PM jepler: er take out the |head|, that was for testing
12:25 PM jepler: er it should probably be if($1==0), i.e., the highest numbered thread is 0
12:26 PM jepler: '{if(FNR==1) { if($1==0) { print "# Only one thread, cannot use isolcpus"; exit 1; } print "X"; lastcore=$2; block=$1 } else if($2 == lastcore && $1 != 0 ) { block = $1 "," block } } END {print "isolcpus=" block }'
12:32 PM mozmck: Looks like that works, except that I think if there are more than 2 cores my && $1 != 0 should not be used.
12:49 PM mozmck: lscpu -p | tac | awk -F, '{if(FNR==1) { if($1==0) { print "# Only one core, cannot use isolcpus"; exit 1; } lastcore=$2; block1=$1 } else if ($2 == lastcore) {block2 = $1} } END {if(block1>1) {print "isolcpus=" block2 "," block1} else if(block1==1) {print "isolcpus=" block1} }'
12:50 PM mozmck: Hmm, probably don't need the if($1==0) test since I take care of that in the END part now.
12:50 PM mozmck: by not printing anything
01:44 PM jepler: mozmck: on your AMD, what's the contents of /sys/devices/system/cpu/cpu7/topology/thread_siblings_list ?
01:45 PM mozmck: 6-7
01:47 PM mozmck: jepler: that's interesting - there's a lot of stuff in there if you know where to find it.
01:54 PM jepler: .. which suggests the following totally different isolcpus detection script .. https://emergent.unpythonic.net/files/sandbox/isolcpus-detector.sh
02:03 PM mozmck: That does seem cleaner in some respects - although I kinda like the one-liner
02:24 PM jepler: forgive me if I've said this before, but somebody needs to sponsor a "Winter of Documentation" where people are sponsored to write and improve documentation for free and open source software.
02:29 PM KGB-linuxcnc: 03Sebastian Kuzminsky 052.7 09fc042 06linuxcnc Merge remote-tracking branch 'origin/2.7-hy-vfd-base-freq' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=09fc042
02:29 PM KGB-linuxcnc: 052.7-hy-vfd-base-freq 4e66ee1 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4e66ee1
03:50 PM seb_kuzminsky: huh, 2.7 doesn't allow asciidoc manpages, even though we added that back in March 2015
03:55 PM KGB-linuxcnc: 03Sebastian Kuzminsky 052.7 528d86d 06linuxcnc 10docs/src/man/man1/hy_gt_vfd.1.txt hy_gt_vfd manpage: add a note about the manual frequency offset... * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=528d86d
03:57 PM KGB-linuxcnc: 03Sebastian Kuzminsky 052.7-asciidoc-manpages f6ddca3 06linuxcnc 10docs/src/Submakefile docs: teach buildsystem to generate manpages from asciidoc source * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f6ddca3
03:57 PM KGB-linuxcnc: 03Jeff Epler 052.7-asciidoc-manpages 29a6d2f 06linuxcnc 10docs/src/Submakefile build: ensure asciidoc manpages are built before checklink is run * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=29a6d2f
03:57 PM KGB-linuxcnc: 03Jeff Epler 052.7-asciidoc-manpages 912444c 06linuxcnc 10docs/src/Submakefile build: don't fail when requested not to build documentation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=912444c
03:57 PM KGB-linuxcnc: 03Jeff Epler 052.7-asciidoc-manpages 03fb4ad 06linuxcnc 10docs/src/Submakefile build: fix building linuxcnc.1 when docs not requested * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=03fb4ad
03:58 PM seb_kuzminsky: that's cherry-picking a bunch of commits from master that add asciidoc manpage support
03:58 PM seb_kuzminsky: can anyone think of something bad that could happen if i merge that into 2.7?
04:06 PM jepler: seb_kuzminsky: even though I wrote it, I don't get commit 03fb4ad89bab4924b2373cd7d49d706f145db0b3
04:07 PM jepler: since this is a purely build-time activity, we can be confident we've got good coverage of it on buildbot
04:07 PM jepler: I don't have any particular concern to raise
04:08 PM jepler: seb_kuzminsky: ^^^ here ends my review, of the commits related to manpage building in particular
04:11 PM seb_kuzminsky: okie dokie
04:35 PM pcw_mesa: hmm strange sserial bug, if you have 2 ports (port 0 and port 1) and no devices on port 0
04:35 PM pcw_mesa: the port1 devices fail with a "remote fault" error (works fine if there are devices on port 0)
04:39 PM pcw_mesa: I suspect somehow the initialization sequence ignores port1 for long enough after starting it
04:39 PM pcw_mesa: that the remote WDs bite
05:01 PM seb_kuzminsky: pcw_mesa: can you open an issue on github?
05:02 PM pcw_mesa: Yeah, I want to test on 2.7.x first
05:07 PM pcw_mesa: I know there were some recent sserial drive changes to support floating point data
05:07 PM pcw_mesa: so I want to see if something got broken there or if this is a long standing bug
05:07 PM pcw_mesa: it could be a long standing bug because if you have 2 sserial ports, its because port0 is fully
05:07 PM pcw_mesa: utilized so you would not normally run into this
05:37 PM andypugh: motion-logger. What is it? How important is it that it work properly?
05:38 PM andypugh: I am trying to re-base multispindle on master, and the motion-logger is the current file causing headaches.
05:39 PM andypugh: I need to work out whether just assuming spindle-0 is OK, or whether to log all the spindles, or whether to log the “active” spindle.
05:47 PM jepler: andypugh: I bet you should make it log information about the lowest-numbered spindle
05:47 PM jepler: motion-logger is only used in a test anyhow, so its interface can change
05:47 PM andypugh: That would be easiest, so is my preferred option.
05:49 PM jepler: I assume that until you command otherwise, it will be the lowest-numbered spindle that the S-word will control. An old test won't have the new spindle-selecting command in it, so that'll be fine
05:49 PM andypugh: Yes, that’s right.
05:50 PM andypugh: I keep mentioniong this, but have not yet had anything back, but what do you chaps think of M3 $4 as the command to turn on the 5th spindle?
05:50 PM andypugh: ($ looks like an S with a milling cutter in it….)
05:51 PM andypugh: That fixes the problem of E-everywhere-except-G76-where-it-is-D and means that D in G76 gets to be used as taper angle. (as worked on my Kim(?)
05:52 PM jepler: hm this source uses M90 / M91 / M93 to select one of three spindles. ugh
05:54 PM jepler: not finding a lot of references to selecting an alternate spindle fwiw
05:54 PM andypugh: No, I looked and didn’t find much
05:55 PM jepler: M3 M3.1 M3.2 ... ?
05:55 PM jepler: I guess there aren't fractional M codes yet are there
05:55 PM andypugh: We don’t support dotted M-codes
05:55 PM andypugh: And would that be G76.1 ? G33.1.1 ?
05:57 PM jepler: G96 P- / G97 P- ?
05:58 PM andypugh: You can feel free to make it all work a different way..
05:58 PM jepler: afk
05:58 PM andypugh: But at the moment I have it all done with an E-word modifier to all the spindle-rleated codes and canned cycles.
06:25 PM mozmck: If motion.feed-inhibit is asserted while a G4 dwell is in effect, does the G4 timer continue to run?
06:34 PM andypugh: Maybe easiest to determine by experiment
06:35 PM andypugh: But I would expect that the pause is a wait-for-timestamp so it probably carries on running.
06:38 PM mozmck: That's my thought as well. How does the system know to stop running code? Looks like motion.feed-inhibit just sets the feedrate to zero - so that must get fed back to the interpreter or something?
06:41 PM cradek: mozmck: G4 is not queued past; motion just stops there and then waits for the timeout before it starts sending lines to the interpreter again
06:42 PM cradek: the wait is not done in realtime at all
06:42 PM cradek: so in our implementation G4 is more like "pause at least this long"
06:45 PM mozmck: cradek: I figured if the G4 happens after feed-inhibit is already asserted, that it would not be executed until after feed-inhibit is de-asserted. But it looks like if G4 is already running the timeout when feed-inhibit is asserted, then the timeout will continue and when feed-inhibit is de-asserted the G4 timeout may already have finished. Is this correct?
06:45 PM cradek: oops I didn't mean to imply I knew how it all worked :-)
06:46 PM mozmck: Bummer! somebody should!
06:46 PM cradek: feed-inhibit tells the realtime TP in motion to stop, and G4 means task should stop sending lines to the interpreter for a while
06:47 PM cradek: they aren't really related at all - there are layers and layers of queues between them
06:48 PM mozmck: How does the interpreter (task?) know to quit when feed-inhibit is asserted? There must be some feedback from motion that tells it it is paused?
06:48 PM cradek: so yes if you inhibit during G4, it won't affect the G4 timeout, but when G4 times out it will start sending new lines to motion, and it's still inhibited, motion won't really start
06:48 PM mozmck: Ok, that is what I was thinking. Thanks!
06:48 PM cradek: yay!
06:48 PM cradek: now you should test it :-)
06:49 PM mozmck: My last question is related - just curious how the internal workings work.
06:49 PM mozmck: We may have tested it already :-D
06:50 PM cradek: afaik, motion doesn't tell task it is inhibited (pausing is a different thing that task does)
06:50 PM cradek: task is free to fill up motion's queue while it is inhibited
06:50 PM cradek: task doesn't care about inhibit which is almost just like FO=0%
06:51 PM mozmck: Found an issue and I bet it is that feed-inhibit is being asserted when a G4 is in progress. We might have to change our code to work around it.
06:51 PM cradek: is it a bug?
06:52 PM mozmck: Ah, so motion just has a queue and task fills it until it's full and waits until it needs more I guess.
06:52 PM cradek: of course I haven't tried any of this, and I only think I know how it interacts because I kinda know the structure
06:52 PM mozmck: I don't think it's a bug in linuxcnc - probably just a bug in our process.
06:52 PM cradek: yes! except in the cases where task knows it can't queue up more things, like if it's just sent a probe command and knows it has to wait
06:53 PM cradek: (... because task has to read the final position from motion and do stuff with it before continuing)
06:53 PM mozmck: That makes sense.
06:54 PM cradek: that's what we colloquially call queue-busters
06:55 PM mozmck: I see - I sortof understood that term, but I bet I do so better now - thanks for the help!
06:55 PM cradek: sure, anytime
06:59 PM KGB-linuxcnc: 03andypugh 05andypugh/multispindle-master fcdfc59 06linuxcnc 10(54 files in 14 dirs) Add support for multiple spindles * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fcdfc59
07:02 PM mozmck: So is G4 a queue buster? It would seem that it should wait until the motion queue is empty before starting the dwell?
07:02 PM cradek: yes
07:02 PM mozmck: ok
07:04 PM KGB-linuxcnc: 05andypugh/JA14_multispindle 4c95e18 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4c95e18
07:07 PM cradek: yay a rebase
07:13 PM andypugh: I am guessing that merging something so big an untested into master would be unwelcome?
07:16 PM cradek: hmmm -- are all these true: you've got a user who wants to exercise it, and you're interested in continuing to work on it, and it probably doesn't cause breakage to existing setups?
07:16 PM cradek: (I would personally think merging is ok if I was in that situation, in your shoes)
07:18 PM cradek: G76/E looks like the only unfortunate glitch you ran into
07:18 PM cradek: (just from the commit message - I haven't fully scanned the diff yet)
07:20 PM andypugh: It tries not to break exisitng setups, but would need a lot of testing to be sure. It touched a lot of files in a lot of places.
07:22 PM andypugh: The guy who wants it kept offering to pay me for the work. But I can’t work out a price for my spare time.
07:22 PM cradek: that's hard. I've been there.
07:22 PM andypugh: (and if someone is paying, you can’t just get bored and stop)
07:23 PM andypugh: I decided a while ago that LinuxCNC is a hobby, and I will never take money for it.
07:23 PM andypugh: (to keep it that way)
07:23 PM cradek: totally understandable.
07:24 PM andypugh: Of course, if I didn’t actually have a real job, I might change my mind.
08:40 PM KGB-linuxcnc: 03andypugh 05master 9bbb2bc 06linuxcnc 10docs/src/user/user-concepts.txt Fix an an order of magnitude error in an equation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9bbb2bc
08:51 PM jepler: andypugh: I'm sorry I got pulled away right at that moment in our conversation. I was just throwing out random ideas but I have little enough background in the feature to make the best suggestions.
08:51 PM jepler: it's not my intent to suggest you have to rewrite your work just to satisfy some arbitrary idea I came up with after thinking about it for 30 seconds
08:52 PM andypugh: Good, because I would have been forced to sulk, were that the case
08:53 PM jepler: I think in our gcode dialect we're free to start using AA, AB, ... ZZ and so forth when we really run out of letters
08:54 PM jepler: unless XSIN[3] is valid, but doesn't it have to be X[SIN[3]]?
08:56 PM jepler: darn, XSIN[3] *is* valid gcode today
09:01 PM andypugh: I like $. That means that folk are then free to remap to suit any dialect they want, and we are not breaking any currently-valid code
09:03 PM andypugh: Or we could embrace Uni-G-Code and use 纺 :-)
09:53 PM linuxcnc-build: build #4223 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/4223 blamelist: andypugh <andy@bodgesoc.org>
09:54 PM andypugh: Well, yes, that’s no surprise :-)
09:58 PM linuxcnc-build: build #5014 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/5014 blamelist: andypugh <andy@bodgesoc.org>
09:59 PM linuxcnc-build: build #5011 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/5011 blamelist: andypugh <andy@bodgesoc.org>
09:59 PM andypugh: Yes, yes, enough alrady
09:59 PM linuxcnc-build: build #3173 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/3173 blamelist: andypugh <andy@bodgesoc.org>
10:04 PM KGB-linuxcnc: 03andypugh 05andypugh/multispindle-master 11de84e 06linuxcnc Merge branch 'master' of ssh://git.linuxcnc.org/git/linuxcnc into multispindle-master * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=11de84e
10:04 PM KGB-linuxcnc: 03andypugh 05andypugh/multispindle-master 1c6ba91 06linuxcnc 10configs/sim/axis/lathe_multispindle/lathe.ini Fix the multispindle lathe config * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1c6ba91
10:04 PM KGB-linuxcnc: 03andypugh 05andypugh/multispindle-master 08c587d 06linuxcnc Merge branch 'master' of ssh://git.linuxcnc.org/git/linuxcnc into multispindle-master * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=08c587d
10:09 PM linuxcnc-build: build #3172 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/3172 blamelist: andypugh <andy@bodgesoc.org>
10:12 PM andypugh: Time ti run away, I think
10:16 PM linuxcnc-build: build #2839 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/2839 blamelist: andypugh <andy@bodgesoc.org>
10:34 PM linuxcnc-build: build #3374 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/3374 blamelist: andypugh <andy@bodgesoc.org>
10:48 PM linuxcnc-build: build #2688 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/2688 blamelist: andypugh <andy@bodgesoc.org>
10:52 PM linuxcnc-build: build #1641 of 1530.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1530.rip-jessie-rtpreempt-amd64/builds/1641 blamelist: andypugh <andy@bodgesoc.org>
10:52 PM linuxcnc-build: build #3182 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/3182 blamelist: andypugh <andy@bodgesoc.org>
11:03 PM linuxcnc-build: build #215 of 1540.rip-jessie-armhf is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1540.rip-jessie-armhf/builds/215 blamelist: andypugh <andy@bodgesoc.org>
11:11 PM linuxcnc-build: build #1639 of 1500.rip-jessie-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/1639 blamelist: andypugh <andy@bodgesoc.org>
11:11 PM linuxcnc-build: build #1640 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/1640 blamelist: andypugh <andy@bodgesoc.org>
11:11 PM linuxcnc-build: build #1639 of 1510.rip-jessie-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1510.rip-jessie-rtpreempt-i386/builds/1639 blamelist: andypugh <andy@bodgesoc.org>
11:12 PM linuxcnc-build: build #27 of 1630.rip-stretch-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1630.rip-stretch-rtpreempt-amd64/builds/27 blamelist: andypugh <andy@bodgesoc.org>
11:25 PM linuxcnc-build: build #27 of 1610.rip-stretch-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1610.rip-stretch-rtpreempt-i386/builds/27 blamelist: andypugh <andy@bodgesoc.org>
11:25 PM linuxcnc-build: build #5029 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/5029 blamelist: andypugh <andy@bodgesoc.org>