Back
[01:00:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/linuxcnc-ui-api 941ba77 06linuxcnc 10src/liblinuxcnc-ui/new.cc lui: use a unique-ish serial number * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=941ba77
[08:25:58] <decimad2> Hello I have a conceptual high level question about gcode and milling and all. Does G-Code support "parallel" execution of movement? I was thinking about how to implement more than 3-axis milling and I was wondering where the kinematics-logic has to be located in the apparently standard g-code way
[08:27:44] <archivist> define parallel as linuxcnc can move 9 axes at the same time
[08:28:43] <archivist> you can program your own kinematics for non standard machines
[08:28:49] <decimad2> What I mean is how can I tell linuxcnc to move those 9 axes in parallel when g-code is basically (to my understanding) a sequential description format... Does linux-cnc do the kinematics?
[08:29:09] <archivist> yes linuxcnc does the kenematics
[08:30:35] <decimad2> So I basically have to find a way to encode what I want to do in g-code and a way to decode that again in linux cnc
[08:30:43] <archivist> so a single g1 like g1 x0,y3,z8,a5,b23 will be one move
[08:31:30] <archivist> what type of machine, the kins may already exist
[08:32:04] <decimad2> okay, that gave me the basic understanding thank you, I just need to get my head around the necessary projection now... complex if not used to... ;)
[08:32:18] <decimad2> Well, the 4th axis is a rotary axis for the blanket
[08:33:28] <archivist> I usually hand code my machine, too lazy to write any kins
[08:35:19] <decimad2> Additionaly there's barely affordable software that would generate 4 axis programs...
[08:35:57] <decimad2> And that's the point I'm currently thinking about... what goes into writing such a generator...
[08:36:47] <archivist> I cut gears and other regular forms, for those it is simple to use gcode
[08:38:47] <archivist> also you can "pretend" the surface of your cylinder around your rotary be X or Y
[08:39:19] <archivist> or you can gear axes together in hal
[08:39:57] <decimad2> I had the feeling that this "false" pretending breaks feed calculations
[08:40:38] <archivist> rotary feed calculations are broken anyway use inverse time mode for them
[08:43:44] <archivist> probably where writing your own kins matters
[08:49:52] <decimad2> is there a way to hand in commands directly without going to g-code?
[08:50:48] <archivist> you can jog an axis if that is what you mean
[08:52:29] <decimad2> what I mean is to use the software as a mere motor controller and do the pathing stuff myself...
[08:52:59] <decimad2> bypassing any g-code interpretation restrictions...
[08:53:42] <archivist> I am not sure what you mean by restrictions
[08:54:35] <archivist> you may be reinventing the wheel before realising what linuxcnc can do
[08:55:31] <decimad2> How can I express is... Say I mean I have a german text, I translate it to chinese (g-code), the software translates it to english (kinematics) and then translates it to motorish
[08:56:21] <archivist> kinematics IS the translation
[08:57:33] <archivist> are you just carving text around A
[08:59:24] <decimad2> What I mean is this: if I have to "linear" movements in parallel axes, the combination might end up being nonlinear through kinematics. So when I go through g-code, I will add up massive amounts of data... or I'm currently misunderstanding everything
[09:03:10] <archivist> people who use cam often end up with huge files, I dont my gcode is often around 1-200 lines per item
[09:03:34] <decimad2> or put differently again, I cannot see how to generate g-code without the understanding of the machine kinematics anyway, then I abstract the kinematics away for g-code and then linux cnc adds them again...
[09:05:03] <archivist> I use the default kins(trivkins i think) and hand code, it just works for me
[09:05:28] <archivist> there is no doubling and masses
[09:05:38] <decimad2> trivkins pretends cartesian axes?
[09:05:55] <archivist> yes
[09:08:03] <decimad2> Do commercial milling machines interface to commercial cam software through g-code still?
[09:08:35] <decimad2> I'm wondering if I see problems where there aren't any actually...
[09:09:02] <archivist> you have the order wrong there, cad->cam->gcode->machine and yes
[09:09:29] <archivist> cam has a post processor suited to the machine
[09:10:06] <archivist> but for users like me cam is far too expensive to I do the maths in gcode
[09:15:46] <decimad2> of course those x-axis cam tools available are much too expensive for me too... again I'm thinking about what goes into proper path generation, expressing it in g-code and doing the maths in control software like linux cnc...
[09:17:06] <jepler> decimad2: you read
http://linuxcnc.org/docs/html/motion/kinematics.html ?
[09:20:51] <decimad2> I now did, that stuff I think I understand already... :) What drives me nuts is that feed control needs absolute positions of parallel axes in relation to each other to work... is there a way to set this up?
[09:21:29] <archivist> are you thinking of a gantry, what machine?
[09:21:39] <jepler> if you're talking about obeying the acceleration and velocity constraints of joints as opposed to acceleration and velocity constraints of cartesian axes, linuxcnc does not have a good solution for this.
[09:21:46] <archivist> because slaved axes is also easy
[09:22:44] <decimad2> The usual workflow as I understand it works by setting a reference frame by touching the blanket and that's the coordinate system to work with (I would call that system "relative"). But kinematics need to know absolute positions in case we're not talking serial kinematics... hrmmmm
[09:23:22] <archivist> blanket? do you mean plane
[09:23:42] <decimad2> hrmm, the block to mill stuff out
[09:24:02] <decimad2> the block from which to mill stuff out :D
[09:25:17] <archivist> are you thinking of a plain 4 axis mill?
[09:25:56] <decimad2> I'm thinking of any-axis mill currently... but it applies to 4 axis too, if the 4th axis is not serial to the 3 other axes
[09:29:34] <archivist> sometimes you just need to apply your mind, no cam needed, just put the maths in the gcode and it all just works
[09:30:22] <decimad2> Yes I see that... but if by any chance somebody on this world is willing to do a multi axis cam software open source, wouldn't that be great? No need for any more maths... :)
[09:30:56] <decimad2> I mean, there must be a reason there is none yet... I would just like to understand this better
[09:31:47] <archivist> it is a hard problem to write general purpose CAM software
[09:32:17] <archivist> there are subsets suited to 2.5D etc
[09:33:52] <jepler> decimad2: with a nontrivial kinematics machine you *must* have a homing procedure that puts the machine in a known absolute position
[09:34:10] <decimad2> Okay, so I was not too way off.
[09:34:15] <jepler> it's true that with a 3-axis mill you can "get away with" just locating the top of the piece of material to be cut
[09:34:43] <jepler> but a proper machine will have home switches and the startup procedure will locate the home switch of each motor
[09:35:00] <jepler> since the home switches are at fixed locations in space (at least relative to the machine as a whole), then you know exactly where you are
[09:35:03] <decimad2> Yep, the machine I have as an example has those
[09:35:27] <jepler> many hobbyist milling machines eliminate this as unnecessary but any serious machine has it, even those with trivial kinematics
[09:35:43] <archivist> I have a lot to mess with when I set up a 5 axis job because finding the working point cannot be with switches
[09:36:31] <archivist> my tooling(ans axes) move around in space
[09:37:57] <archivist> this illustrates one set up
http://www.collection.archivist.info/archive/DJCPD/PD/2013/2013_08_11_bevel/IMG_1633.JPG A rotating about B but geared together in gcode
[09:38:05] <decimad2> So it's obvious that linux cnc will represent that with multiple available frames to the kineamtics...?
[09:39:33] <archivist> that setup produced
http://www.collection.archivist.info/archive/DJCPD/PD/2013/2013_08_16_bevel/IMG_1651.JPG
[09:39:33] <jepler> inverse kinematics receives the cartesian coordinates in the machine's absolute coordinate system
[09:39:37] <decimad2> hrmmm, also I couldn't find an explanation to the inverted time mode yet... is there any explanation available somewhere? would like to understand
[09:40:21] <jepler> http://linuxcnc.org/docs/html/gcode/gcode.html#sec:G93-G94-G95-Mode
[09:40:27] <decimad2> thank you.
[09:40:32] <jepler> "G93 - is Inverse Time Mode. In inverse time feed rate mode, an F word means the move should be completed in [one divided by the F number] minutes. For example, if the F number is 2.0, the move should be completed in half a minute."
[09:41:19] <decimad2> So I will do the feed rate calculation in my theoretical cam software and use f-codes to communicate the paths?
[09:42:18] <archivist> F is feed rate not path
[09:42:26] <decimad2> erm, g93-codes
[09:43:18] <archivist> the paths are still defined by normal gcodes like g1,g2 etc
[09:43:47] <decimad2> That's the point I was trying to make... if I have to resort to these codes, then what basically is happening is that the kinematics are done in the cam software, broken down to F-values and then done again in the controller software...
[09:44:30] <archivist> I think you are confused
[09:47:22] <decimad2> If I set a path and a time for completion then that path and the given time must be compatible with the feed rate, or the feed rate must be compatible with the time, plus the maximum rates of the axes must be taken into consideration. I cannot see how the CAM-software does not need the kinematics.
[09:48:22] <archivist> the cam software knows the moves, the machine will slow down to make it possible
[09:57:41] <decimad2> I think I will try write a simple generator g93-base generatir and play around with custom kinematics in the times coming. Thanks for your explanations and the links!
[09:58:08] <decimad2> Gosh, reformulating shouldnt be done in a hurry, sorry.
[10:25:23] <jepler> oops! spot the bug
[10:25:23] <jepler> > - tm.tv_sec = (long) timeout;
[10:25:24] <jepler> > - tm.tv_sec = (long) (fmod(timeout, 1.0) * 1e6);
[10:32:56] <cradek> skunkworks: can I have the gcode that does weirdness in 2.6?
[10:43:59] <decimad2> writing to tv_sec twice?
[10:44:54] <decimad2> I bet there must be tv_micros :D
[11:02:48] <skunkworks> cradek,
http://electronicsam.com/images/KandT/testing/SPACOUT1.ngc
[11:04:20] <skunkworks> the config was 30in/sec^2 and 500ipm
[11:18:59] <dirty_d> I'm confused, what hal function does linuxcnc call when it wants to output a signal on a pin?
[11:19:49] <dirty_d> i see functions in hal.h for creating pins and signals, but I'm not seeing what actually gets called in the driver to do the actual work
[11:20:52] <archivist> look for the driver of a signal
[11:22:38] <dirty_d> hal_export_funct
[11:24:53] <dirty_d> so the parport driver exports a function that actually writes to the parport and gives it a name i.e "parport.0.write"
[11:29:49] <skunkworks> cradek, can you re-produce? I exported with 4 digits just to make sure it wasn't something odd with that but it did the same thing.
[11:38:01] <dirty_d> im more confused now, the partport function exports a write function and an argument to be passed to it as a parameter which is of type parport_t
[11:38:08] <dirty_d> parport driver*
[11:38:44] <dirty_d> how does linuxcnc specify which pins to turn on when it calls the write_port function
[11:38:55] <dirty_d> unless it knows about the parport_t type
[11:39:05] <dirty_d> which it shouldnt, because the inner working should be abstracted away
[12:07:54] <cradek> skunkworks: thanks, I'll try it soon
[12:18:15] <kwallace> dirty_d, unless I'm missing something, the parport driver has a write function which should be added to a thread, usually "addf parport.0.write servo-thread" in the .hal file. When the write function is called by the servo thread, the write function does an out_b (or something similar) which outputs a byte to an IO address that corresponds to the appropriate parallel port data register. The parallel port hardware sets the hardware (motherboar
[12:20:32] <dirty_d> .hal file?
[12:21:54] <pcw_home> Yeah parport_t type is local, not public (public signal are all indivdual bits)
[12:22:31] <pcw_home> public interface is HAL pins
[12:28:57] <dirty_d> ok, so the stepper driver would just directly set the values of the signals on the pins, then call the parport write exported function?
[12:30:15] <cradek> after the pin is created, the creator holds a pointer to it. There is no function call required to write through this pointer to the pin
[12:30:30] <cradek> this is how hal works, and is not peculiar to any particular driver
[12:30:55] <cradek> I am not positive that's what you're meaning to ask, but it's how I read your initial question
[12:31:32] <dirty_d> cradek, i know but how do you actually tell the driver to actually output these values to hardware right now
[12:31:53] <cradek> that depends on the hardware. values get sent to hardware in lots of ways
[12:32:24] <cradek> maybe back up and say what you're trying to do? I don't understand the situation that's causing these questions
[12:32:35] <kwallace> The stepper driver takes in position information and outputs step and direction signals. The .hal file connects the stepper signals to the parport driver.
[12:33:00] <cradek> yes except I would say "hal component" in both places you said driver
[12:33:09] <dirty_d> i want to connect a microcontroller to a raspberry pi, and write a driver to offload the realtime stuff to the microcontroller
[12:33:31] <archivist> he is attempting to cram linuxcnc on a pi
[12:33:45] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master bf5bffb 06linuxcnc 10docs/man/man1/linuxcncrsh.1 10src/emc/usr_intf/emcrsh.cc 10src/emc/usr_intf/emcsh.cc 10src/emc/usr_intf/shcom.hh remove EMC_WAIT_NONE from shcom, it's broken * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bf5bffb
[12:34:12] <archivist> dirty_d, what microcontroller?
[12:34:43] <cradek> bbl
[12:35:17] <dirty_d> not sure, i have a bunch
[12:35:20] <dirty_d> thats the easy part
[12:35:27] <dirty_d> well, maybe
[12:36:09] <dirty_d> this will only work if linuxcnc will send stuff faster than it needs to happen in real time, so it can be buffered on the microcontroller, then output at the correct time
[12:36:27] <archivist> buffering makes little sense
[12:37:03] <dirty_d> like whenever the state of any pin changes, the pin and level along with the length of time to stay at that level
[12:37:09] <dirty_d> archivist, why?
[12:37:13] <archivist> but there is a more natural separation further up the chain
[12:37:47] <cradek> that is contrary to the architecture of linuxcnc. some information here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Emc2HardwareDesign
[12:38:44] <archivist> dirty_d, we get someone trying this once every few months, it is just not the right way, it will be painful
[12:38:50] <pcw_home> buffering causes pain and suffering for real time motion control (or you eventually figure out that you want to port all of linuxcnc /HAL to the ucontroller)
[12:39:16] <dirty_d> hmm
[12:39:17] <ssi> and then you end up with arduino motion control like reprap uses being drip-fed over usb or serial
[12:39:28] <ssi> that's the logical conclusion of this :)
[12:39:56] <ssi> you need some amount of real-time atomicity, for lack of a better term
[12:39:59] <dirty_d> is that just he way its made, or is there some fundamental reason the step sigals couldnt be computed ahead of time and then executed in real time by other hardware?
[12:40:32] <dirty_d> for my machine i cant see any reason, maybe something more complxt with some sort of feedback id understand
[12:40:32] <cradek> yes - you break all of homing, probing, pid control, tapping, threading, etc with your new architecture for NO benefit
[12:40:45] <dirty_d> yea that makes sense
[12:40:52] <cradek> we have a lot of existing GREAT solutions
[12:40:53] <ssi> in the simplest case, think e-stop
[12:40:58] <ssi> if e-stop is hit, stepgen needs to stop now
[12:41:03] <ssi> not once the buffer's flushed
[12:41:30] <archivist> my hobbing machine cannot work that way
[12:42:00] <cradek> yes also css, fpr, all spindle synchronized motion like archivist's hobbing
[12:42:08] <pcw_home> and it moves all those relatively complicated real time tasks a much less friendly development environment
[12:42:43] <archivist> in short, we dont recommend it
[12:42:58] <kwallace> dirty_d, a key concept to motion control or real-time is not speed but getting the various bits that need to happen at the same time, to actually happen on time. To go from point A to B, all three axes must get the appropriate number of steps at each way point at the same time.
[12:44:02] <ssi> it's not obvious if you only think in terms of moving one axis from A to B, but becomes more obvious when you start thinking about how to synchronize everything
[12:44:21] <dirty_d> yea i see what youre saying when you have input rather than just outputs
[12:44:32] <dirty_d> my machine is just a dumb 3 axis cnc with 3 steppers
[12:45:34] <ssi> so think about homing... you queue a bunch of steps into your off-pc buffer, and it starts moving the axis, and then you get a home switch trip; where exactly was the axis when it tripped?
[12:45:41] <archivist> soon you want to tap though which needs a spindle encoder
[12:46:14] <CaptHindsight> who is working on ESP Hal? or maybe predictive synchronized motion where it's accurate 50% of the time :p
[12:46:20] <pcw_home> dirty_d: AFAIK all LinuxCNC hardware stepgenerators work in approximately the same way:
[12:46:22] <pcw_home> linuxcnc commands a velocity and reads back position every servo thread. This can easily be offloaded to a Uproc
[12:46:48] <dirty_d> i dont even have homing
[12:47:14] <dirty_d> i get everything youre saying, im just want a quick hack to save a few hundred bucks on a new pc
[12:48:01] <CaptHindsight> lots of older <$25 PC's that work fine with LPT/EPP
[12:48:01] <archivist> I use second hand PCs last one cost a pound
[12:48:33] <ssi> I just paid $55 for two d525 boards shipped, they work well
[12:48:34] <pcw_home> http://www.ebay.com/itm/Intel-DQ35JO-MicroATX-Motherboard-w-Core-2-Duo-E6550-2-33GHz-512MB-QTY-/161389612993?pt=US_Motherboard_CPU_Combos&hash=item2593920fc1
[12:49:26] <CaptHindsight> what's a Rpi + IO board cost?
[12:49:51] <cradek> suitable PCs are $0
[12:50:01] <dirty_d> linuxcnc works with the serial port too right?
[12:50:08] <dirty_d> that board has no parport
[12:50:18] <kwallace> http://www.ebay.com/itm/281459983873
[12:50:21] <cradek> you can use a serial port for realtime digital I/O of a few bits
[12:50:54] <kwallace> LOL
[12:51:03] <archivist> serial, cough
[12:51:35] <pcw_home> a PCI parallel port card is <$10
[12:52:15] <kwallace> I think cradek means you _can_ toggle pins on the serial port just like the parallel port.
[12:52:39] <cradek> yes our serport driver does that
[12:52:52] <ssi> regardless of cost... spending dozens of hours reengineering linuxcnc to work with rpi with far less performance in order to save a small amount of money is false economy
[12:52:53] <cradek> I've never used it, but there might be enough bits to use it for a jogwheel or such
[12:53:24] <kwallace> Could be handy.
[12:53:31] <KGB-linuxcnc> 03Chris Radek 05joints_axes6 1294bf2 06linuxcnc New branch with 163 commits pushed, 10183 files changed, 038816(+), 045092(-) since joints_axes6/c6911bc
[12:53:38] <cradek> yeah
[12:54:57] <kwallace> I guess one would need to account for the +/- 12 Volt signal?
[12:55:02] <dirty_d> the price is right
http://www.ebay.com/itm/New-PCI-I-O-Parallel-Port-DB25-25Pin-IEEE-1284-Printer-Card-Controller-Adapter-/380801587270?pt=US_Internal_Port_Expansion_Cards&hash=item58a98b1846
[12:55:48] <ssi> ok I need to figure this verilog out for reals
[12:56:53] <dirty_d> I just bought that miniITX board
[12:57:06] <dirty_d> and pci parallel port card
[12:57:30] <micges-dev> cradek: what's new in ja6?
[12:57:53] <kwallace> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?EMC2_Supported_Hardware look down the page for Parallel Port Cards
[12:57:59] <micges-dev> cradek: rebased on newest master?
[12:58:02] <seb_kuzminsky> micges-dev: it's ja5 rebased onto the current master
[12:58:03] <seb_kuzminsky> yes
[12:58:16] <micges-dev> ok
[12:59:55] <ssi> are there any plans to move ja to master?
[13:00:28] <cradek> yes that's the eventual hope but it's not ready yet
[13:00:50] <ssi> ok
[13:01:06] <ssi> I've got two gantry machines on ja5, if there's any way I can help with testing or whatnot let me know
[13:02:15] <cradek> ssi: that's good to know - the important problem I saw was that setups with nonconsecutive defined axes don't work right, and unfortunately I don't remember the details
[13:02:32] <cradek> I saw both XYZB and XZ (lathe) configs not work right at all
[13:02:54] <ssi> ah
[13:03:27] <ssi> I am willing to try a ja5 or ja6 build on my lathe and see if I can make an XZ setup work or not work
[13:03:27] <dirty_d> has there been any thought into an open source linuxcnc hardware project? like linuxcnc usb external controller
[13:03:54] <cradek> all the mesa firmwares are open source, and some people have built compatible hardware
[13:04:04] <CaptHindsight> USB isn't real time, unless you want really slow real time
[13:04:08] <seb_kuzminsky> dirty_d: there's also this:
https://github.com/SebKuzminsky/cncfpga
[13:04:14] <ssi> and the mesa stuff is priced inexpensively enough that there's usually no reason to try to roll your own
[13:04:24] <dirty_d> CaptHindsight, right but you can still give the device high level commands that are executed in real time
[13:04:36] <dirty_d> like lower the spindle this many mm for every revolution
[13:04:39] <CaptHindsight> and the VHDL for mesa is all open source
[13:05:12] <ssi> dirty_d: you're back in the same boat you were in with an external uc
[13:05:26] <ssi> it's not realtime if you can't synchronize it with stuff happening in the pc
[13:05:45] <dirty_d> what needs to happen in realtime in the pc though?
[13:06:08] <CaptHindsight> it's take a bit of really looking at the big picture
[13:06:11] <ssi> didn't we just have this conversation 20 minutes ago?
[13:06:18] <seb_kuzminsky> dirty_d: motmod (the motion controller) and some subset of the hal components, dependent on what your machine configuration is like
[13:06:37] <dirty_d> ssi, yea but im saying if the controller did more than just generated pulses from input pulse commands
[13:06:37] <ssi> if you want to offload everything to external hardware, get a RAMPS board and run marlin or similar on it
[13:08:08] <CaptHindsight> how does RAMPS handle servo or other closed loop real time IO?
[13:08:20] <ssi> it doesn't
[13:09:21] <CaptHindsight> dirty_d: that's the difference, you're not limited to open loop with Linuxcnc
[13:09:31] <ssi> it's just an arduino with a builtin 5 axis stepper drive and some IO hardware
[13:09:41] <ssi> but that's basically what he's talking about wanting to build
[13:10:09] <ssi> if you have external hardware that's responsible for stepgen, and also responsible for all inputs, and synchronizing them togother
[13:10:23] <ssi> you quickly discover that you have to build the trajectory planner into your external hardware
[13:10:32] <ssi> and then you start to question why you need linuxcnc at all
[13:10:49] <ssi> and the answer is, you don't, because you've reimplemented it
[13:12:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/linuxcnc-ui-api 61f6ceb 06linuxcnc 10src/emc/usr_intf/Submakefile 10src/emc/usr_intf/emcrsh.cc linuxcncrsh: use lui for estop * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=61f6ceb
[13:12:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/linuxcnc-ui-api 195dee7 06linuxcnc 10src/emc/usr_intf/Submakefile 10src/emc/usr_intf/xemc.cc xemc: use lui for estop * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=195dee7
[13:12:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/linuxcnc-ui-api 62ccf88 06linuxcnc 10src/emc/usr_intf/Submakefile 10src/emc/usr_intf/emclcd.cc linuxcnclcd: use lui for estop * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=62ccf88
[13:12:47] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/linuxcnc-ui-api 825bc02 06linuxcnc 10src/emc/usr_intf/emcrsh.cc linuxcncrsh: use lui for machine_on() and machine_off() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=825bc02
[13:12:52] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/linuxcnc-ui-api 103b652 06linuxcnc 10src/emc/usr_intf/emcrsh.cc linuxcncrsh: use lui_get_task_mode() * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=103b652
[13:18:29] <CaptHindsight> as much as I love the con men behind many of the *dunio and reprap projects where is a good place to publish an article clearing up the differences between Linuxcnc and what they are peddling?
[13:20:37] <cradek> the blogosphere maybe?
[13:23:21] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 2642c3c 06linuxcnc 10docs/src/code/.gitignore 10docs/src/code/Code_Notes.txt 03docs/src/code/task-state-transitions.dot docs: add a Task "state" transition diagram to Code Notes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2642c3c
[13:27:46] <KGB-linuxcnc> 03Sebastian Kuzminsky 05liblinuxcnc-ui de29c75 06linuxcnc New branch with 35 commits pushed, 1026 files changed, 031820(+), 04164(-) since master/2642c3c
[13:28:14] <CaptHindsight> some of the contributors at Machine design are 3D printer fans, maybe I can nudge one
[13:28:28] <KGB-linuxcnc> 05seb/master/linuxcnc-ui-api 103b652 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=103b652
[13:44:39] <linuxcnc-build> build #2531 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2531 blamelist: Chris Radek <cradek@dsndata.com>, andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh
[13:44:39] <linuxcnc-build> <andy@bodgesoc.org>, Alex Joni <alex_joni@users.sourceforge.net>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, John Kasunich <jmkasunich@fastmail.fm>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>
[14:04:05] <KGB-linuxcnc> 03Chris Radek 05joints_axes6 9f5dca7 06linuxcnc 10src/rtapi/rtapi_math.h Remove unneeded gcc version check, like fdb2d64 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9f5dca7
[14:12:43] <linuxcnc-build> build #1733 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1733 blamelist: Chris Radek <cradek@dsndata.com>, andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh
[14:12:43] <linuxcnc-build> <andy@bodgesoc.org>, Alex Joni <alex_joni@users.sourceforge.net>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, John Kasunich <jmkasunich@fastmail.fm>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>
[14:21:12] <linuxcnc-build> build #2532 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2532 blamelist: Chris Radek <cradek@dsndata.com>, andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh
[14:21:12] <linuxcnc-build> <andy@bodgesoc.org>, Alex Joni <alex_joni@users.sourceforge.net>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, John Kasunich <jmkasunich@fastmail.fm>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>
[14:22:16] <linuxcnc-build> build #346 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/346 blamelist: Chris Radek <cradek@dsndata.com>, andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh
[14:22:16] <linuxcnc-build> <andy@bodgesoc.org>, Alex Joni <alex_joni@users.sourceforge.net>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, John Kasunich <jmkasunich@fastmail.fm>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>
[14:26:49] <jepler> > In a followup to last year's report on the future of realtime Linux, Thomas Gleixner once again summarized the status of the long-running patch set. The intervening year did not result in the industry stepping up to fund further work, which led Gleixner to declare that realtime Linux is now just his hobby. That means new releases will be done as his time allows and may eventually lead to dropping the patch set altogether if
[14:27:11] <jepler> (the rest of the story is behind lwn's paywall so far, that quote from the front page
https://lwn.net/ )
[14:30:52] <jepler> .. time to start packing up, I guess.
[14:35:09] <kwallace> Realtime Linux as in being part of regular Linux?
[14:36:05] <dirty_d> what is this? --with-boost-python
[14:36:23] <dirty_d> is boost-python a library?
[14:37:17] <kwallace> I think Boost is a binding of something to Python. I should know but...
[14:38:28] <kwallace> http://www.boost.org/doc/libs/1_56_0/libs/python/doc/
[14:40:14] <dirty_d> i have this /usr/lib/libboost_python.a
[14:41:11] <decimad2> there's precision time protocol to synchronize distributed actors...
[14:41:27] <dirty_d> might not have anything to do with my error though,
http://pastebin.com/ShkE3KTL
[14:41:27] <seb_kuzminsky> here's the link, unpaywalled:
https://lwn.net/Articles/617140/
[14:41:48] <kwallace> I could be way off, but it (Boost) may be needed for parts of LinuxCNC that is written in C++?
[14:42:32] <micges-dev> I think it's used in gcode remapping
[14:43:41] <dirty_d> i have boost
[14:44:02] <dirty_d> i think it has something to do with C++11 conditional code or something
[14:45:31] <dirty_d> BOOST_NO_CXX11_RVALUE_REFERENCES
[14:51:11] <linuxcnc-build> build #2540 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2540 blamelist: Chris Radek <cradek@dsndata.com>, andypugh <andy@bodgesoc.org>, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Andy Pugh <andy@bodgesoc.org>, Alex Joni
[14:51:11] <linuxcnc-build> <alex_joni@users.sourceforge.net>, Jeff Epler <jepler@unpythonic.net>, Stephen Wille Padnos <swpadnos@sourceforge.net>, John Kasunich <jmkasunich@fastmail.fm>, sam sokolik <samcoinc@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>
[14:51:13] <linuxcnc-build> build #2541 of 0000.checkin is complete: Failure [4failed fetch branch to local git repo] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2541 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[14:54:05] <dirty_d> does line 81 look like a bug do you guys?
http://pastebin.com/tB2cjidx
[14:54:14] <dirty_d> i think it should be #if defined
[14:54:24] <dirty_d> i changed it to that and now linuxcnc compiles
[14:56:17] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 e5d5e58 06linuxcnc 10scripts/githelper.sh teach the build scripts to be more accepting of release branch names * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e5d5e58
[14:56:17] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 dc23fff 06linuxcnc 10VERSION 10debian/changelog Pre-release v2.7.0~pre1 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dc23fff
[14:56:17] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags 6991da4 06linuxcnc 03v2.7.0-pre1 LinuxCNC v2.7.0-pre1 (tagged commit: dc23fff) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6991da4
[14:56:25] <seb_kuzminsky> haw yeah, that's right
[15:03:01] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 b954ad3 06linuxcnc 10scripts/githelper.sh oops, bump the master tag glob * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b954ad3
[15:04:23] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 847eaaf 06linuxcnc 10VERSION 10debian/changelog Pre-release: 2.8.0~pre0 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=847eaaf
[15:04:23] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 3a52501 06linuxcnc 10debian/changelog Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3a52501
[15:04:23] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags dca997c 06linuxcnc 03v2.8.0-pre0 LinuxCNC v2.8.0-pre0 (tagged commit: 847eaaf) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dca997c
[15:04:46] <seb_kuzminsky> ahem, "haw yea, that was nearly right, and maybe this is closer"
[15:06:25] <seb_kuzminsky> airplane time for seb!
[15:06:36] <seb_kuzminsky> the hackfest was wonderful! can't wait for next year!
[15:06:37] <seb_kuzminsky> bye!
[15:18:09] <kwallace2> Bummer, I've used MAH's log to check IRC history, but I guess he isn't logging any more?
[15:19:28] <micges-dev> kwallace: psha.org.ru/irc
[15:20:10] <micges-dev> kwallace2: www.psha.org.ru/irc
[15:20:44] <dirty_d> i think you guys might have a bug in rs274ngc_pre.cc line 132
[15:20:50] <dirty_d> _setup.pythis = boost::python::object(boost::cref(this));
[15:20:56] <dirty_d> shouldnt it be _setup.pythis = boost::python::object(boost::cref(*this));
[15:21:09] <dirty_d> theres no such thing as a refrence to this
[15:23:28] <kwallace2> micges-dev, thank you.
[15:26:55] <dirty_d> the r-value constructor of boost::refrence_wrapper is deleted
[15:27:09] <dirty_d> recently i guess
[15:34:03] <brianmorel99_wor> dirty_d: What version are you trying to build?
[15:34:51] <dirty_d> good point, master
[15:35:12] <dirty_d> but anyway, changing it to *this fixed it
[16:28:48] <kwallace2> Hmm... My pogo sockets call for a .067 (#51) drill, bit but that gives .0015 clearance which is fairly slippery. I was hoping for a light press fit. The next drill size down, .0635" (#52) is way too tight. I may have to put a dab of silicone on the far side of the sockets to keep them from falling out?
[16:59:00] <dirty_d> that bug is in v2.6.3 too
[16:59:11] <dirty_d> _setup.pythis = boost::python::object(boost::cref(this));
[16:59:32] <dirty_d> are you developing against an older version of boost?
[17:00:47] <dirty_d> it doesnt compile against boost 1.56
[17:28:53] <linuxcnc-build> build #2332 of 1901.clang-precise-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1901.clang-precise-amd64/builds/2332 blamelist: Chris Radek <chris@timeguy.com>
[17:37:04] <jepler> dirty_d: please submit a bug on sourceforge or a pull request on github.
[17:37:54] <jepler> dirty_d: I will be happy to look at it in depth later, but my real computers are far from me at this second and I'll forget in time
[17:38:15] <jepler> github is jepler/linuxcnc-mirror, we respond to pull requests there.
[17:38:17] <linuxcnc-build> build #2534 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2534 blamelist: Chris Radek <chris@timeguy.com>
[17:40:41] <dirty_d> ok
[17:42:18] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master dcf6f1c 06linuxcnc 10scripts/githelper.sh githelper: better tag glob for master * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dcf6f1c
[17:43:42] <seb_kuzminsky> wow the buildbot is really slow
[17:51:29] <linuxcnc-build> build #2534 of 1300.rip-precise-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2534 blamelist: Chris Radek <chris@timeguy.com>
[17:52:52] <linuxcnc-build> build #2536 of 1306.rip-precise-amd64 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2536 blamelist: Chris Radek <chris@timeguy.com>
[17:54:33] <seb_kuzminsky> what is this failed git
[17:55:21] <seb_kuzminsky> heh, thank you git:
[17:55:35] <seb_kuzminsky> Auto packing the repository in background for optimum performance.
[17:55:45] <seb_kuzminsky> cp: cannot stat `/home/buildslave/emc2-buildbot/precise-amd64/precise-amd64-sim/source/.git/objects/pack/pack-8e28b44b5d62285c15295e52ec6c958123b9a79b.idx': No such file or directory
[17:56:17] <seb_kuzminsky> linuxcnc-build: force build --branch=joints_axes6 0000.checkin
[17:56:21] <seb_kuzminsky> try again pls
[17:56:22] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[17:57:39] <linuxcnc-build> build #1736 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1736 blamelist: Chris Radek <chris@timeguy.com>
[18:13:19] <linuxcnc-build> build #349 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/349 blamelist: Chris Radek <chris@timeguy.com>
[18:14:35] <linuxcnc-build> build #2535 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2535 blamelist: Chris Radek <chris@timeguy.com>
[18:15:54] <decimad2> I'm beginning to see a pattern there!
[18:39:17] <linuxcnc-build> build #2544 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2544 blamelist: Chris Radek <chris@timeguy.com>
[19:18:20] <linuxcnc-build> build #596 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/596 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:18:23] <linuxcnc-build> build #596 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/596 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:20:01] <linuxcnc-build> build #160 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/160 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:20:03] <linuxcnc-build> build #299 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/299 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:20:05] <linuxcnc-build> build #121 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/121 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:21:09] <linuxcnc-build> build #865 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/865 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:21:12] <linuxcnc-build> build #2032 of 4007.deb-precise-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/2032 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:21:13] <linuxcnc-build> build #2032 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/2032 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:21:38] <linuxcnc-build> build #2029 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2029 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:22:22] <linuxcnc-build> build #2026 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/2026 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[19:22:22] <linuxcnc-build> build #2026 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/2026 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[20:32:35] <linuxcnc-build> build forced [ETA 1h02m53s]
[20:32:35] <linuxcnc-build> I'll give a shout when the build finishes
[20:42:43] <linuxcnc-build> build #2537 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2537
[21:07:37] <jepler> dirty_d: boost 1_55 is the version in debian jessie and ubuntu utopic, so I imagine it's the newest version which is routinely tested with linuxcnc
[21:07:41] <linuxcnc-build> build #1739 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1739
[21:10:46] <jepler> this incompatible change is not called out in boost's release notes, more's the pity
[21:13:15] <jepler> some runtests fail when the boost::cref line is commented out so the testsuite is exercising the code
[21:13:25] <jepler> and the test does succeed when the suggested change is made
[21:15:38] <jepler> so as far as I'm concerned we can incorporate the change, particularly if dirty_d makes a suitable pull request
[21:15:41] <jepler> bbl
[21:23:56] <linuxcnc-build> build #352 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/352
[21:24:10] <linuxcnc-build> build #2538 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2538
[21:49:03] <linuxcnc-build> build #2547 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2547
[21:49:43] <seb_kuzminsky> linuxcnc-build: force build --branch=2.7 --revision=v2.7.0-pre1 0000.checkin
[21:49:44] <linuxcnc-build> build forced [ETA 1h02m53s]
[21:49:44] <linuxcnc-build> I'll give a shout when the build finishes
[21:59:17] <seb_kuzminsky> crap, i signed the release tag with the wrong key :-/
[22:01:04] <seb_kuzminsky> guess i was being too hasty this afternoon
[22:29:54] <linuxcnc-build> build #598 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/598
[22:30:06] <linuxcnc-build> build #123 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/123
[22:30:06] <linuxcnc-build> build #162 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/162
[22:30:06] <linuxcnc-build> build #598 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/598
[22:31:17] <linuxcnc-build> build #867 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/867
[22:32:05] <linuxcnc-build> build #301 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/301
[22:32:09] <linuxcnc-build> build #2034 of 4007.deb-precise-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/2034
[22:32:10] <linuxcnc-build> build #2034 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/2034
[22:32:18] <seb_kuzminsky> ugh
[22:32:37] <linuxcnc-build> build #2031 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2031
[22:33:15] <linuxcnc-build> build #2028 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/2028
[22:33:16] <linuxcnc-build> build #2028 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/2028
[22:44:12] <linuxcnc-build> Hey! build 0000.checkin #2548 is complete: Success [3build successful]
[22:44:12] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2548
[23:13:04] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 d024544 06linuxcnc 10(6 files in 2 dirs) Add a gnupg keyring for release tag signature verification * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d024544
[23:14:40] <seb_kuzminsky> i hope i didn't just check my personal private key into our git repo
[23:28:12] <ssi> lol
[23:39:31] <cradek> seb_kuzminsky: you home already? I made it out of texas...
[23:40:10] <cradek> fest was great! what a neat place their hackspace is.
[23:45:25] <seb_kuzminsky> im on the bus on my way home
[23:45:27] <seb_kuzminsky> and my laptop
[23:45:37] <seb_kuzminsky> is about to run out of batteries and put itself to sleep
[23:45:40] <seb_kuzminsky> bye!
[23:52:40] <linuxcnc-build> build #599 of 4016.deb-wheezy-i386 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/599 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:52:41] <linuxcnc-build> build #599 of 4017.deb-wheezy-amd64 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/599 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:53:35] <linuxcnc-build> build #302 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/302 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:54:47] <linuxcnc-build> build #868 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/868 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:54:49] <linuxcnc-build> build #2035 of 4008.deb-precise-amd64 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/2035 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:54:49] <linuxcnc-build> build #2035 of 4007.deb-precise-i386 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/2035 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:55:48] <linuxcnc-build> build #2032 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2032 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:56:07] <linuxcnc-build> build #2029 of 4004.deb-lucid-amd64 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/2029 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:56:07] <linuxcnc-build> build #2029 of 4003.deb-lucid-i386 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/2029 blamelist: Sebastian Kuzminsky <seb@highlab.com>
