Back
[07:10:34] <KGB-linuxcnc> 03John Thornton 052.6 4572451 06linuxcnc 10docs/man/man9/debounce.9 Docs: provide an example of creating filter groups * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4572451
[08:30:32] <jepler> mozmck: EXPORT_SYMBOL is from the kernel, we have a version that works similarly but not identically for uspace.
[09:19:07] <seb_kuzminsky> good morning folks
[09:31:18] <seb_kuzminsky> this reminds me of our docs:
http://i.imgur.com/EAqfdHb.jpg
[09:42:32] <jepler> hee hee
[09:46:44] <cradek> the USA+flag insignia makes it
[09:53:09] <CaptHindsight> I go through this in China all the time. They never ask a native English speaker to proofread.
[11:04:03] <kwallace2> I have put forward the notion that we need to put the source in with the distribution DVD and the images will either be protected by trademark law which is separate from GPL, or are part of look and feel, which apparently is not protected, so though painful, why worry about it. GPL seems to state that a file's original copyright needs to be in place, plus a statement of any changes, the authors and when. I haven't seen any files anywhere that
[11:05:23] <kwallace2> I haven't seen any files anywhere that strictly comply with this since a file could have hundreds of changes, so I think a more general statement should suffice.
[11:11:33] <skunkworks> kwallace2, are there roughing cycles on the tormach now?
[11:11:51] <skunkworks> (lathe_
[11:11:53] <skunkworks> )
[11:12:05] <jepler> kwallace2: sounds good to me -- putting the complete corresponding source code on the same media you put the binary on is a good strategy. That's 3(a) in the GPLv2.
[11:12:34] <jepler> kwallace2: if you are packaging .debs then the build process even automates creating this "complete corresponding source code" file
[11:14:57] <skunkworks> kwallace2, if not.. this seems like a good project to take on.. ;)
http://www.bpuk.org/linuxcnc/
[11:15:20] <kwallace2> skunkworks, On the lathe, but they are not separate. The rough DoC is used until the last pass then the finish DoC. The routines are either g-code or Python and not canned like I think Fanuc may have.
[11:15:32] <jepler> kwallace2: GPLv2 2(a) requirement to date every change in every modified file is, to put it mildly, routinely ignored.
[11:16:39] <jepler> I doubt even the FSF followed the letter of this rule, though they *do* carefully keep up to date a ChangeLog file
[11:17:23] <kwallace2> If I get the guy that signs the checks to agree, where do I send the DVD?
[11:17:51] <jepler> I thought you were talking about a DVD that you distribute to your customers
[11:19:39] <kwallace2> Yes, but that is a format that complies, but I think we still need to provide it on demand.
[11:20:28] <jepler> if you do 3(a) you don't have to do 3(b).
[11:20:51] <kwallace2> Okay, I'm fine with that.
[11:21:48] <seb_kuzminsky> the way to comply with the GPLv2 that's the most helpful to the upstream project (us) is to provide a git repo with your changes
[11:22:21] <seb_kuzminsky> i assume you've got an internal git repo with a branch that you build your packages from?
[11:22:54] <jepler> yes I'd love to talk about not just complying with the GPL but also helping improve LinuxCNC
[11:26:01] <kwallace2> Okay, I'll look into it.
[12:17:09] <seb_kuzminsky> skunkworks: do you know who bpuk is?
[12:23:44] <seb_kuzminsky> oh, i see, Brian Potter
[13:12:09] <mozmck> speaking of distributing the source, if we start supporting linuxcnc, we plan to ship basically a liveCD with linuxcnc and our configs on it. Would we need to include source code for every program on the liveCD??? It kinda looks that way.
[13:28:32] <seb_kuzminsky> mozmck: i think you can do what we do, and include a link to the source code for everything on the live cd
[13:29:01] <seb_kuzminsky> i am not a lawyer, but as i understand it the main thing is this:
[13:29:25] <seb_kuzminsky> 1. if you ship a modified version of GPL software, you must supply the source code of your modified program
[13:29:45] <seb_kuzminsky> 2. if you ship a program that links against GPL libraries, you must supply the source code of your program
[13:30:01] <seb_kuzminsky> in both these cases "supply" here means "include the source code or include a link to the source code"
[13:30:13] <CaptHindsight> but supply doesn't mean it has to be on the disk
[13:30:21] <CaptHindsight> it just needs to be available
[13:30:29] <seb_kuzminsky> where source code can be anything from the .c files (or whatever), or a tarball of the sources, or a link to a git repo
[13:32:16] <CaptHindsight> no matter what you do you're going to get some source nazi to complain about how something wasn't available they way they wanted it before they even knew they wanted it
[13:34:42] <mozmck> according to the article jepler linked to yesterday, you are required to make available the source code for all GPL 2 binaries that you distribute - on physical media.
[13:35:05] <kwallace2> This link makes a case for putting the source on the distribution DVD.
http://www.softwarefreedom.org/resources/2008/compliance-guide.html See 4.1.1 Option (a): Source Alongside Binary
[13:35:33] <mozmck> Yes, that's the article I was talking about.
[13:36:20] <mozmck> But if you distribute a liveCD linux distribution, it could take several DVDs to get all the source for every program on the liveCD!
[13:38:26] <seb_kuzminsky> yes, that's not commonly done
[13:38:54] <seb_kuzminsky> it made more sense before the internet was widely used, and open source was developed by snail-mailing tapes around
[13:39:11] <seb_kuzminsky> now days the polite, effective thing to do is to provide a link to a public git repo
[13:39:23] <mozmck> So what would be a more normal and suitable option? Point people to the source packages of the distribution?
[13:39:24] <seb_kuzminsky> or, second best, a webserver with tarballs
[13:40:07] <mozmck> How about just pointing people to the distribution the binaries came from for the sources?
[13:40:36] <seb_kuzminsky> yes, i think that's a good way to do it for binaries that you did not make, that an upstream distribution made, that you're just redistributing
[13:40:48] <seb_kuzminsky> that's what we (linuxcnc) do for our live-cd
[13:41:48] <seb_kuzminsky> it's really mostly stuff that you modify or that you are the upstream developer for that you normally provide source code for
[13:42:08] <mozmck> According to that article the re-distributor is also required to "make available on physical media" the sources and not just the original distributor.
[13:42:17] <mozmck> that makes sense to me.
[13:43:00] <mozmck> I guess it would not be too hard to get all the source and put it on a CD if someone really wanted to get it that way :)
[13:43:14] <mozmck> But normally not include it.
[13:50:18] <seb_kuzminsky> yeah
[13:50:23] <kwallace2> If you use the Offer method and are under GPLv2 you are supposed to maintain the offer for physical media for three years as opposed to just putting it on the distribution DVD and have the liability end with the last DVD sent out.
[13:50:40] <mozmck> Yes, that could be a pain.
[13:51:02] <mozmck> Maybe it would all fit on one DVD.
[13:51:48] <seb_kuzminsky> the whole linuxcnc git repo is 109 MB (that includes all of history)
[13:52:03] <mozmck> Sounds like GPLv3 is a good bit better in some ways.
[13:52:34] <seb_kuzminsky> a tarball of the current tip of master is ~24 MB
[13:52:46] <cradek> if you use apt, this is super easy, because apt-get source of any package you have installed will automatically get you the source
[13:53:20] <seb_kuzminsky> cradek: i think they're worried about the letter-of-the-law that says you must provide the source on physical media if asked
[13:53:36] <cradek> availability of the corresponding source is really built into debian...
[13:53:39] <mozmck> Yes, but I'm thinking of the linux kernel, libreoffice, inkscape, etc.etc. A re-distributor must either send with or make available the source for ALL GPL binaries for up to 3 years after the end of life of the product.
[13:54:05] <cradek> that is not something that would probably come up, but if someone asks, sure, you could just do it
[13:54:54] <mozmck> hi cradek, yes, but the 3 years after the product ends could be a problem. I guess if we got all the source and kept a CD in a file, then it would be easy to just make a copy and ship it.
[13:55:11] <cradek> 3 years after you distribute
[13:55:24] <mozmck> But as versions get updated that could get interesting.
[13:55:53] <cradek> yeah
[13:56:26] <cradek> I have not seen this come up, but it's true it could conceivably be a pain.
[13:56:30] <seb_kuzminsky> i bet we dont have source packages for the exact versions of the upstream debs we include on our live-cd
[13:56:45] <seb_kuzminsky> and i bet it will never be an issue
[13:56:46] <mozmck> see section 4.1.2 of the article kwallace2 mentioned above.
[13:57:20] <cradek> seb_kuzminsky: I suspect they're actually all available on the debian apt servers
[13:57:43] <seb_kuzminsky> i believe that our obligations can be met by fetching the deb sources that our upstream (debian wheezy) is obligated to provide
[13:57:46] <seb_kuzminsky> cradek: yes
[13:59:01] <cradek> it would be extremely unusual if we got that request
[13:59:06] <mozmck> It's obviously more of a pain for a company than individual OS developers. Who would one make a request to or sue over getting a physical media of the source code for everything on the liveCD? But for a company it's a little different.
[13:59:25] <seb_kuzminsky> cradek: i agree - un-heard-of unusual
[14:00:12] <cradek> making a dvd and keeping it in your file cabinet is an EXTREMELY small price to pay for a company using decades worth of free code
[14:00:23] <cradek> I just don't understand the hand-wringing
[14:00:24] <mozmck> true!
[14:00:46] <mozmck> Just trying to figure out what is required and how to do it on my end.
[14:01:08] <cradek> I understand
[14:01:12] <mozmck> And not all companies are large and have lots of money :)
[14:02:09] <cradek> sorry, I have seen this stuff argued in bad faith so many times ("so therefore free software is bad for people, and bad for business"). I know that's not how you are though.
[14:02:18] <mozmck> Our company has a software and firmware development team of 1, and he does some of the hardware development too :)
[14:03:17] <mozmck> no problem, I can understand that. I'm a free software guy as much as I can be. Started with Debian in 97 or 98
[14:03:25] <cradek> lb (the debian live build system) has a single command that will assemble the corresponding source and make an image for you.
[14:03:33] <cradek> so if you're rolling a cd for you company, you can just do that
[14:03:57] <mozmck> oh wow, that could be very useful - thanks for the tip
[14:04:37] <mozmck> I need to look at the debian live build system. Last time I used anything was for 10.04
[14:05:08] <cradek> (I haven't tried it)
[14:05:28] <seb_kuzminsky> that's good news, cradek!
[14:05:33] <seb_kuzminsky> makes it easy
[14:05:42] <seb_kuzminsky> i should have guessed the debian tool developers would be awesome in that way
[14:05:51] <cradek> yeah, it figures, doesn't it
[14:06:25] <mozmck> sorry I was not able to help more with the last liveCD and kernel seb and cradek. things have been a bit busy for me.
[14:06:41] <cradek> mozmck: it was my turn again, no problem
[14:07:04] <cradek> mozmck: also, I think it's getting less bad every time
[14:07:12] <mozmck> that's good
[14:07:31] <mozmck> How is the debian distribution working out over all?
[14:07:41] <cradek> it seems really great
[14:07:46] <seb_kuzminsky> yeah, no worries mozmck
[14:07:55] <seb_kuzminsky> i'm pretty happy with wheezy
[14:08:09] <cradek> people have had different opinions about which desktop environment is best, and they can just install their choice
[14:08:16] <cradek> I haven't seen much other than that
[14:08:17] <mozmck> not having problems with newer hardware? I wondered about that a bit because of the older kernel and all.
[14:08:24] <mozmck> ah, yes.
[14:08:25] <seb_kuzminsky> it was super helpful^W^Wcrucial for the new rtai kernel to have memfrob around to make rtai work right
[14:08:49] <mozmck> I like xfce myself. I haven't tried MATE but I'm sure it's good too since I liked gnome2 fine.
[14:09:03] <mozmck> yes, I gathered that!
[14:09:20] <mozmck> I have never gotten that deep into the kernel.
[14:09:32] <cradek> lb_config ... --source true
[14:10:01] <mozmck> ok, thanks for the info. have to get back to other work...
[14:10:20] <cradek> http://manpages.ubuntu.com/manpages/natty/man1/lb_config.1.html
[14:10:39] <cradek> the manpage says once you start distributing your live image, you oughta make a source image
[14:11:26] <seb_kuzminsky> cradek: do you have config files & helper scripts for our live cd in a git repo somewhere? i realize i have no idea how you did it
[14:11:33] <skunkworks> I request a source image of the wheezy livecd... ;)
[14:11:58] <cradek> http://timeguy.com/gitweb?p=live-images.git;a=log;h=refs/heads/debian
[14:12:43] <cradek> I have not yet pushed the changes for 2.7 or addition of screen
[14:13:22] <seb_kuzminsky> thanks!
[14:14:03] <Tom_itx> does the source have to be available for free?
[14:14:28] <mozmck> basically, yes.
[14:14:34] <cradek> Tom_itx: you can charge a reasonable amount for the media to distribute it
[14:14:44] <mozmck> you can charge what it costs to make and ship the media.
[14:14:46] <Tom_itx> 10k?
[14:14:59] <Tom_itx> that would deter anybody asking
[14:15:07] <seb_kuzminsky> heh:
http://timeguy.com/gitweb?p=live-images.git;a=commitdiff;h=adf685864b6848bfc6b71108336706c13a22b835
[14:15:44] <seb_kuzminsky> Tom_itx: sorry, you have to find another loophole if you dont want to distribute source
[14:16:14] <Tom_itx> that came up once for me and that was the offer made to me
[14:16:24] <Tom_itx> not with lcnc but something else
[14:16:32] <cradek> Tom_itx: if you fell for it, shame on you
[14:16:36] <Tom_itx> no
[14:17:05] <mozmck> Tom_itx: wow, according to the article mentioned: GPLv2 permits “a charge no more than your cost of physically performing source distribution”
[14:17:29] <Tom_itx> another time a lib source was delivered and all the variables were _ underscores of varying lengths
[14:17:37] <seb_kuzminsky> cradek: the new live-cd stuff rocks
[14:17:42] <seb_kuzminsky> things really are getting better
[14:17:43] <cradek> Tom_itx: that is also a violation
[14:17:53] <cradek> seb_kuzminsky: yes absolutely
[14:17:58] <Tom_itx> the guy was a real ass
[14:18:55] <Tom_itx> what ver is the live cd now?
[14:19:08] <Tom_itx> something newer than the USB fix?
[14:19:27] <seb_kuzminsky> Tom_itx: the current live cd has the usb/baytrail fix
[14:19:34] <Tom_itx> ok
[14:22:06] <cradek> Tom_itx: "The source code for a work means the preferred form of the work for making modifications to it."
[14:22:19] <cradek> Tom_itx: this rules out your underscores, and other kinds of obfuscation
[14:23:08] <Tom_itx> i kinda doubt it would ever come up anyway
[14:24:23] <Tom_itx> not unless lcnc ever became obsolete
[14:24:36] <Tom_itx> which is unlikely
[14:24:41] <jepler> sorry if this was mentioned already, but GPLv2 3(c) is a viable choice for noncommercial distribution like we do from linuxcnc.org but is not available for commercial distribution.
[14:25:05] <jepler> so for the iso file from linuxcnc.org, we basically rely on the offer we received from debian.
[14:25:28] <jepler> but if you're distributing linuxcnc in binary form as part of a commercial product, you can't satisfy your obligations in this way.
[14:25:29] <seb_kuzminsky> jepler: that's new & useful in the context of this conversation
[14:26:12] <cradek> interesting
[14:26:31] <seb_kuzminsky> not often you see someone connect via IPv6
[14:27:36] <seb_kuzminsky> 3(c) makes a lot of sense
[14:28:10] <seb_kuzminsky> zlog:
[14:28:29] <mozmck> hi jepler: yes, that was mentioned in the article.
[14:28:53] <seb_kuzminsky> i'm glad my assumption about how it works was right!
http://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2014-12-18.html#13:57:43
[14:54:08] <mozmck> Ok, back with another question. Is there a way to update the position of an axis from a component?
[14:55:43] <mozmck> So if an axis is moved externally to linuxcnc, can I inform linuxcnc of the new position - or maybe the distance it was moved.
[14:56:01] <cradek> that's what position feedback already does
[14:56:27] <cradek> you can disable the amps and move the machine all you want, then turn the amps back on
[14:56:59] <cradek> heh you can do it with the amps on, but it'll push back
[14:57:46] <cradek> ... or ferror, depending on your hardware's capabilities
[14:57:57] <mozmck> hmm, maybe I should explain a little more.
[14:59:19] <mozmck> We are using step/dir motors. Our THC takes over moving the Z axis after the torch fires. After a cut, the Z may not be at the same position it started out, but linuxcnc will think it never moved.
[14:59:45] <cradek> hmmm
[14:59:47] <mozmck> So at that point I want to update linuxcnc on where the axis actually is before it starts moving again.
[15:00:00] <cradek> I don't know of a way to do that
[15:00:19] <cradek> shouldn't it / can't it move back when done?
[15:00:42] <cradek> otherwise the commanded Z height from gcode doesn't seem useful
[15:01:17] <mozmck> Not always, because the metal may warp etc, so the height at the finish of a cut may be higher than the height at the start etc.
[15:01:46] <mozmck> The commanded Z is useful for the place the cut starts, but will be out of sync at the end.
[15:01:51] <CaptHindsight> can you Home Z after the THC is done?
[15:02:17] <skunkworks> doesn't the torch hight control componant do this?
[15:03:06] <cradek> you must not see this offset on-screen
[15:03:34] <mozmck> the THC component in linuxcnc now actually moves the Z, but our THC moves the Z independently of the controller.
[15:04:10] <cradek> what is Z in the gcode used for?
[15:04:10] <mozmck> well, with "that other software", I can update the position periodically during the cut and it shows in the DRO.
[15:05:02] <mozmck> Currently the Z is controlled by gcode to move to a safe height for rapids, touch-off (home), and move to pierce height and then cut height.
[15:05:50] <cradek> ok, so it is useful
[15:06:16] <mozmck> We designed this so at some point (soon probably) we can use it on systems that don't have Z control at all and it will be able to do all of that internally. But it is useful to have a hybrid like this.
[15:06:39] <mozmck> yes. It allows jogging the Z manually easily etc.
[15:06:40] <cradek> if you open up ferror limits, you can sure display whatever Z you want on the screen, but that doesn't change commanded Z to match it, until you change to machine-off state
[15:07:17] <cradek> as soon as you change to machine-off commanded is set to be equal to feedback
[15:07:17] <mozmck> what about a touch-off (or whatever it's called?)
[15:07:33] <cradek> I don't understand that question
[15:07:58] <mozmck> can't you tell an axis where it is in the GUI?
[15:08:09] <cradek> yes, that runs a G10 command
[15:08:27] <cradek> that sets a gcode offset
[15:08:38] <cradek> it does not change the commanded position
[15:09:25] <mozmck> interesting, so if I click touch off and set X to 0.0 it just sets a gcode offset?
[15:09:45] <cradek> yes
[15:09:55] <cradek> it sure doesn't move the machine
[15:10:16] <mozmck> No, but I thought it basically set the position of that axis.
[15:13:54] <mozmck> Maybe I can basically just do a G10 then. G10 L20 looks like it might be close to what I need.
[15:15:25] <cradek> hm maybe so
[15:15:45] <cradek> I don't have a feel for how thc should work
[15:17:10] <mozmck> It's different than milling or lathe for sure
[15:18:55] <mozmck> the material is not static - thinner sheets of metal can warp an inch or two as you cut.
[15:20:53] <cradek> so if you say G0Z1 and start an inch up, and then make a long cut and float upward as the piece warps, you get to the end you want it to say Z=1 again, even though if you jog back to the original start point you'll be 3" above now but it'll say Z=1?
[15:22:14] <cradek> or wait, maybe you're saying the opposite
[15:22:55] <cradek> it still says Z=1 but you want to change it to say Z=3 and simulatenously remove the automatic 2" offset, wherever that is
[15:25:00] <mozmck> Hmm.
[15:27:07] <mozmck> If Z was always the same height off the metal at the end, it might work to let it think it's in the same absolute position. The problem we have at times is if the torch dives at the end of a cut, then it is sitting on the metal (actually below because the Z is floating), so you don't want to start XY movement until the torch has been picked up.
[15:27:44] <mozmck> Ideally there won't be a torch dive at the end of a cut, but sometimes it happens depending on the setup.
[15:28:01] <cradek> can you add a switch?
[15:28:33] <mozmck> there is a switch and often an ohmic sensor.
[15:28:53] <mozmck> I see - use the switch to detect that we are on the metal.
[15:28:57] <mozmck> might work
[15:29:07] <cradek> if that's the only problem you're solving...
[15:29:11] <cradek> I dunno, I'm clueless about this
[15:29:30] <mozmck> as far as I can remember that's the main problem.
[15:30:11] <mozmck> well, that gives me some ideas to look at. thanks for the help.
[15:30:25] <cradek> welcome
[15:32:50] <CaptHindsight> we had to introduce offsets to Z on the fly using a laser micrometer, but I can't recall now how we did that
[15:33:25] <mozmck> CaptHindsight: I'd be interested in anything you have on that.
[15:33:48] <CaptHindsight> there were surface irregularities that the laser would pick up and adjust the Z to keep the nozzle a set 25um from the surface
[15:34:27] <mozmck> Did linuxcnc move the Z or the laser?
[15:35:13] <CaptHindsight> we tried both and I think it was easier for Linuxcnc to do it
[15:35:30] <CaptHindsight> we gave it an offset on the fly
[15:35:36] <CaptHindsight> how I'll have to check
[15:36:05] <mozmck> our THC directly controls the Z while cutting, so I think it's a little different
[15:36:51] <CaptHindsight> yes, we could just introduce an error voltage and gate the encoder from going back to Linuxcnc
[15:37:12] <CaptHindsight> which is what you must be doing
[15:38:19] <mozmck> we use step/dir drives, and our board does accel/deccel and all internally when cutting. When not cutting it passes step/dir signals through from linuxcnc or whatever the controller is.
[15:43:18] <CaptHindsight> http://linuxcnc.org/docs/html/man/man9/offset.9.html
[15:52:32] <skunkworks> so how does the software know where z is?
[15:52:58] <skunkworks> or does the board always return to a known postion?
[15:53:40] <mozmck> The board keeps track of every step it takes after taking over the Z.
[15:54:14] <mozmck> So it can report the number of steps back to the PC.
[16:14:36] <skunkworks> how does it report back?
[16:18:35] <mozmck> skunkworks: rs485 from the device to our hub which talks to the PC over usb
[16:20:04] <skunkworks> wow
[16:39:26] <cradek> -rw-r--r-- 1 root root 163840 Dec 18 16:18 source.debian-live.tar
[16:39:26] <cradek> -rw-r--r-- 1 root root 2777180160 Dec 18 16:18 source.debian.tar
[16:39:55] <cradek> yep you can build a corresponding-source tarball to a live+install iso like we use, with one command
[16:41:04] <cradek> you even get the source for the image builder, so you can rebuild the image builder to rebuild the image
[16:41:08] <cradek> or something like that
[16:41:10] <cradek> mozmck: ^
[16:41:32] <cradek> like always: yay for the debian folks
[16:43:32] <mozmck> thanks cradek!
[16:44:01] <mozmck> so that's about 2.77 Gb?
[16:44:55] <seb_kuzminsky> cradek: sweet!
[16:45:29] <seb_kuzminsky> http://i.imgur.com/axjyiYW.gif
[16:45:41] <jepler> cradek: that's not a small file
[16:45:59] <jepler> is it a tar full of .tar.gzs, or will it compress substantially?
[16:46:21] <jepler> seb_kuzminsky: Capt. Riker is a handsome man. and he knows it.
[17:04:18] <seb_kuzminsky> jepler: lieutenant commander, you filthy casual
[18:00:17] <jepler> seb_kuzminsky: It depends at what time you're talking about. "By 2379, Riker decided to accept promotion to captain of the USS Titan, assuming command of the ship that year." --
http://en.memory-alpha.org/wiki/William_T._Riker
[18:01:28] <jepler> .. but you're probably right that when that photograph was taken he was probably no higher ranking than Commander.
[18:01:58] <jepler> ("William Riker was promoted to commander and first officer of the newly launched USS Enterprise-D in 2364.")
[18:04:16] <jepler> (not to mention that in the novels he's promted to Admiral)
[18:08:52] <seb_kuzminsky> he
[18:08:55] <seb_kuzminsky> h
[18:10:29] <seb_kuzminsky> memfrob: which kernel was it you made rtai support for? 3.16?
[18:23:36] <cradek> jepler: [orig.]tar.gz, dsc, diff.gz
[18:24:29] <jepler> cradek: ah so it won't compress much further
[18:24:33] <jepler> (slight) pity
[18:25:32] <cradek> eh, who cares
[18:32:36] <memfrob> seb_kuzminsky: 3.16.7
[18:33:37] <memfrob> latency without web browser 5 useconds, with web browser, 40-60
[18:34:11] <memfrob> i looked at 3.18 and it would be a few days of very boring copy pasting and grepping
[18:34:23] <memfrob> but not hard at all, just tedious
[18:35:24] <memfrob> i didnt look much into the deb building after a quick glance and some of the makefiles
[18:35:29] <memfrob> *at some
[18:36:23] <memfrob> i would like to have other people try it to see if it causes problems for other boards but i know it's not a big concern for the linuxcnc community
[18:40:56] <memfrob> i only have the latest bleeding edge hardware from AMD so for older systems i honestly have no idea how it will perform
[18:45:06] <KGB-linuxcnc> 03Dewey Garrett 052.7 bf2820c 06linuxcnc 10(12 files in 5 dirs) moveoff: support -mode always, fixes from testing * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bf2820c
[18:45:06] <KGB-linuxcnc> 03Dewey Garrett 052.7 91247e5 06linuxcnc 03docs/man/man1/moveoff_gui.1 03docs/man/man1/sim_pin.1 10docs/src/config/moveoff.txt 10scripts/moveoff_gui moveoff_gui: new manpage * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=91247e5
[19:20:21] <linuxcnc-build> build #2792 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2792 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:25:35] <linuxcnc-build> build #2802 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2802 blamelist: Dewey Garrett <dgarrett@panix.com>
[19:33:53] <seb_kuzminsky> that's my fault, not dewey's
[19:34:41] <memfrob> heh!
[19:37:21] <seb_kuzminsky> i bet it's one of those sleepy problems like the linuxcncrsh test the other day
[19:52:44] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 7af4f1d 06linuxcnc 10tests/halui/jogging/test-ui.py tests: longer timeout in halui jogging test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7af4f1d
[19:53:32] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 d740ca4 06linuxcnc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d740ca4
[19:54:48] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master d230316 06linuxcnc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d230316
[21:56:26] <seb_kuzminsky> cmorley: are you around?
[21:59:16] <skunkworks> zlog:
[22:40:07] <seb_kuzminsky> memfrob: what's the git repo & branch?
[23:00:11] <memfrob> github.com/ntulinux/rtai
[23:01:23] <memfrob> only one branch
