#linuxcnc-devel | Logs for 2016-05-11

Back
[00:33:03] <seb_kuzminsky> jepler: thanks for dealing with nml, that's awesome
[00:38:50] <linuxcnc-build> build #1251 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/1251 blamelist: Boris Skegin <boris.skegin.de at gmail.com>, Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[00:54:37] <linuxcnc-build> build #3308 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/3308 blamelist: Boris Skegin <boris.skegin.de at gmail.com>, Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[01:18:24] <linuxcnc-build> build #1923 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/1923 blamelist: Boris Skegin <boris.skegin.de at gmail.com>, Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[01:32:56] <linuxcnc-build> build #4111 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4111 blamelist: Boris Skegin <boris.skegin.de at gmail.com>, Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[03:27:47] <linuxcnc-build> build #2293 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2293 blamelist: Norbert Schechner <nieson@web.de>
[04:08:30] <linuxcnc-build> build #4113 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4113 blamelist: Norbert Schechner <nieson@web.de>
[05:28:33] <linuxcnc-build> build #300 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/300 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[05:41:54] <linuxcnc-build> build #1255 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/1255 blamelist: dummy, Boris Skegin <boris.skegin.de at gmail.com>, Jeff Epler <jepler@unpythonic.net>, Al Smart <smartmachinetool@yahoo.com>, Chris Morley
[05:41:54] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, Jan Mr?zek <email@honzamrazek.cz>
[06:03:03] <linuxcnc-build> build #1927 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/1927 blamelist: dummy, Boris Skegin <boris.skegin.de at gmail.com>, Jeff Epler <jepler@unpythonic.net>, Al Smart <smartmachinetool@yahoo.com>, Chris Morley
[06:03:03] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, Jan Mr?zek <email@honzamrazek.cz>
[06:13:02] <linuxcnc-build> build #3312 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/3312 blamelist: dummy, Boris Skegin <boris.skegin.de at gmail.com>, Jeff Epler <jepler@unpythonic.net>, Al Smart <smartmachinetool@yahoo.com>, Chris Morley
[06:13:03] <linuxcnc-build> <chrisinnanaimo@hotmail.com>, Norbert Schechner <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, Jan Mr?zek <email@honzamrazek.cz>
[06:29:56] <linuxcnc-build> build #4115 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4115 blamelist: dummy, Boris Skegin <boris.skegin.de at gmail.com>, Jeff Epler <jepler@unpythonic.net>, Al Smart <smartmachinetool@yahoo.com>, Chris Morley <chrisinnanaimo@hotmail.com>, Norbert Schechner
[06:29:56] <linuxcnc-build> <nieson@web.de>, Dewey Garrett <dgarrett@panix.com>, Sebastian Kuzminsky <seb@highlab.com>, John Thornton <bjt128@gmail.com>, Jan Mr?zek <email@honzamrazek.cz>
[09:02:05] <seb_kuzminsky> yikes, that's a red-looking morning
[09:02:53] <seb_kuzminsky> master is failing to build on rtai due to this pktuart problem: http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3308/steps/compile/logs/stdio
[09:04:57] <seb_kuzminsky> the EU_Surplus_FastSeal branch failure is my arm buildslave segfaulting during the build again :-(
[09:06:01] <seb_kuzminsky> and the nml-tcp branch is failing because it's based on master with the pktuart/rtai bug
[09:06:44] <seb_kuzminsky> that's your buildbot report for this morning
[09:11:34] <jepler> oh I hadn't realized that master branch was failing due to pktuart :-/
[10:00:40] <KGB-linuxcnc> 03Jeff Epler 05master 9733d35 06linuxcnc 10src/hal/drivers/mesa_pktgyro_test.comp pktgyro: remove unneeded header * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9733d35
[10:01:13] <jepler> .. I don't have an rtai machine handy to test on so I don't know if that'll resolve the build errors or not
[10:12:28] <linuxcnc-build> build #3313 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/3313 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:14:21] <linuxcnc-build> build #1928 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/1928 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:18:05] <seb_kuzminsky> jepler: none of us knew because the buildbot was wedged
[10:18:11] <seb_kuzminsky> dgarr clued me in to that
[10:18:26] <seb_kuzminsky> i've got an rtai vm here, i'll poke at it later today
[10:18:28] <seb_kuzminsky> bbl
[10:22:48] <linuxcnc-build> build #1256 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/1256 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:33:12] <linuxcnc-build> build #4116 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4116 blamelist: Jeff Epler <jepler@unpythonic.net>
[10:55:51] <jepler> seb_kuzminsky: ah I see
[10:56:35] <jepler> I think we asked Boris S. for some component using the pktuart functionality, but I'm not sure it's a good component
[10:57:28] <seb_kuzminsky> thanks for handling that PR
[10:57:44] <seb_kuzminsky> there was a lot going on there
[11:11:04] <seb_kuzminsky> mesa_pktuart_gyro.comp doesn't even try to build on uspace
[11:11:15] <seb_kuzminsky> it just builds on rtai, and there it fails
[11:12:37] <jepler> oh hm that's why it built after I changed it I guess
[11:12:41] <seb_kuzminsky> i wish the buildbot would build PRs for us
[11:23:39] <jepler> http://www.theregister.co.uk/2016/05/09/allwinners_allloser_custom_kernel_has_a_nasty_root_backdoor/ stay away from vendor kernels
[12:45:51] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 7e5edcc 06linuxcnc 04docs/src/namelink.sh namelink.sh: remove wrongly included file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7e5edcc
[12:45:51] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 62d9c61 06linuxcnc 10(43 files in 14 dirs) keystick gui removal * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=62d9c61
[12:45:51] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 766c022 06linuxcnc 10(71 files in 22 dirs) mini gui removal * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=766c022
[13:25:03] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master ffdc647 06linuxcnc 03src/hal/components/mesa_pktgyro_test.comp 04src/hal/drivers/mesa_pktgyro_test.comp move mesa_pktgyro_test comp to correct dir, fix header path * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ffdc647
[13:36:33] <jepler> seb_kuzminsky: thank you
[13:39:48] <seb_kuzminsky> dgarr: thanks for removing those old guis and sending the email abotu the others
[13:40:14] <seb_kuzminsky> jepler: that built the comp for me on both uspace and rtai, remains to be seen if the buildbot can stay up long enough to validate it :-/
[17:32:08] <tinkerer> is any pcw instance there?
[17:32:32] <tinkerer> here
[17:48:54] <jepler> seb_kuzminsky: looks like it did ? http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4118
[17:51:30] <PCW> yes for a bit
[17:51:52] <tinkerer> PCW: Hi
[17:53:08] <tinkerer> I have a question about this "late sample"
[17:53:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 379fd11 06linuxcnc 10src/Makefile build: warn about incorrect function overloading * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=379fd11
[17:53:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 8bed9d6 06linuxcnc 10src/libnml/buffer/tcpmem.cc 10src/libnml/buffer/tcpmem.hh nml: Fix prototypes in class TCPMEM * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8bed9d6
[17:53:21] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 84b0b3d 06linuxcnc 10src/libnml/buffer/tcpmem.cc nml: tcp: copy serial number back to caller * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=84b0b3d
[17:53:23] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp e756541 06linuxcnc 10src/libnml/buffer/rem_msg.hh 10src/libnml/buffer/tcpmem.cc 10src/libnml/cms/tcp_srv.cc 10src/libnml/nml/nml_srv.cc nml: tcp: arrange to transport write_id back to client * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e756541
[17:53:28] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp c0c788c 06linuxcnc 10configs/common/linuxcnc.nml 10tests/linuxcncrsh-tcp/tcp.nml configs: must enable "confirm_write" to get serial number return * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c0c788c
[17:53:32] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 2090d90 06linuxcnc 10src/libnml/cms/cms.cc nml: trivial typo * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2090d90
[17:53:36] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 428e9c6 06linuxcnc 10src/libnml/cms/cms.cc 10src/libnml/cms/cms.hh 10tests/linuxcncrsh-tcp/tcp.nml nml: add 'serial' flag to do command serial-number stuff * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=428e9c6
[17:53:40] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp b1708ea 06linuxcnc 10src/libnml/nml/nml_srv.cc nml: write the serial number into the command as seen by task * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b1708ea
[17:53:44] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp 48a06f3 06linuxcnc 10configs/common/client.nml 10configs/common/linuxcnc.nml 10configs/common/server.nml fix other nmlfiles * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=48a06f3
[17:53:49] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/nml-tcp aebad41 06linuxcnc 04tests/linuxcncrsh-tcp/skip tests: linuxcncrsh-tcp test now passes for me * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=aebad41
[17:54:28] <tinkerer> in the docs there is: This matches SPI master setup with CPOL=0 and CPHA=0.
[17:55:58] <PCW> Some SPI masters have the ability to sample the slave data later than the normal clock edge
[17:56:40] <tinkerer> but as I understand this description http://dlnware.com/theory/SPI-Transfer-Modes, "late sample" would be CPHA=1 ...
[17:56:50] <PCW> master clock to slave data valid is what limits the SPI clock rate
[17:57:06] <PCW> No this is a fraction of a clock
[17:57:25] <tinkerer> ok
[17:58:35] <PCW> something outside the normal CPOL CPHA settings ( TI has this for example as do the Allwinner A10/20)
[18:00:08] <jepler> http://www.byteparadigm.com/files/documents/Using-SPI-Protocol-at-100MHz.pdf the figure on page 2 shows how propagation shifts MISO @ master vs SCLK @ master http://www.byteparadigm.com/files/documents/Using-SPI-Protocol-at-100MHz.pdfhttp://www.byteparadigm.com/files/documents/Using-SPI-Protocol-at-100MHz.pdf
[18:00:22] <jepler> err pardon the bad paste
[18:02:47] <tinkerer> jepler: thanks this explains it
[18:02:57] <tinkerer> ok, I've a "short" second question :)
[18:02:59] <jepler> and yes, this is a different register in each SPI hardware implementation, if it's available at all. I also don't believe it's available through the /dev/spidev ioctl interface even if it is hardware-supported.
[18:04:12] <tinkerer> as you know, I don't use the spidev :)
[18:05:34] <tinkerer> the question: is it possible to compile just the hostmot2 driver without the whole source tree
[18:06:11] <tinkerer> like halcompile <driver>
[18:06:45] <PCW> I was able to do 50 MHz SPI clock with a 7I90 with no master late sample option (BSPI master in 7I80 FPGA)
[18:06:46] <jepler> no, nobody's made that possible.
[18:06:47] <PCW> This does require short cables
[18:07:48] <jepler> I probably have 10cm cables, plus whatever delay is introduced by the level shifter, and ran at 40MHz.
[18:07:55] <jepler> (flat ribbon cable)
[18:07:59] <PCW> I think I had to tweak the FPGAs clock drive strength
[18:10:29] <jepler> since hostmot2 consists of multiple source files and produces multiple output realtime modules, it is not a good match for how halcompile thinks about things. at a minimum you'd have to understand how Makefile.modinc works and write your own Makefile.
[18:11:41] <jepler> it's not clear how we'd include something like that in linuxcnc; for components normally shipped in linuxcnc.git, I think building them separately is an antipattern and at any rate it would be rarely tested and likely to bitrot
[18:12:59] <tinkerer> ok, was just a idea
[18:13:03] <tinkerer> BTW: is there some kind of good/bad duty cycle between servothread time and packet time
[18:14:18] <jepler> afk
[18:14:26] <tinkerer> under packet time I understand the time for sending the whole data
[18:15:12] <tinkerer> per servo thread time
[18:21:18] <PCW> As long as all the hal functions can finish in the servo period its not terribly important
[18:21:20] <PCW> (also depends on how efficient the SPI interface is about using CPU )
[18:24:03] <tinkerer> ok
[19:22:51] <skunkworks_> zlog
[19:36:34] <seb_kuzminsky> since we're talking about throwing out cruft, i wonder if anyone is using halrmt or emclcd
[19:43:16] <jepler> linuxcnclcd is on dgarr's list
[19:43:24] <jepler> halrmt isn't a sticking point for anything at the moment
[19:55:21] <seb_kuzminsky> you're right, of course, linuxcnclcd == emclcd, i spaced that
[20:32:46] <cradek> seb_kuzminsky: I am making the 2.5.5 release. Is it correct that I should sign the tag with this key?:
[20:32:49] <cradek> user: "Chris Radek <chris@timeguy.com>"
[20:32:52] <cradek> 1024-bit DSA key, ID BC92B87F, created 2003-03-14
[20:33:16] <cradek> I think that's the one I always used before, but I think we also do have a release manager key now
[20:35:39] <cradek> we just passed 20000 messages on emc-developers
[20:35:45] <jepler> it's a question of what key would be installed..
[20:36:29] <jepler> (are you signing the repo or the .changes file?)
[20:36:33] <cradek> no, it's what the buildbot recognizes as an anointed release maker's key
[20:36:39] <cradek> the git tag
[20:36:46] <jepler> oh the git tag? I guess that doesn't matter.
[20:36:52] <cradek> it does
[20:36:58] <jepler> oh
[20:37:06] <cradek> buildbot ignores signed release tags unless they're by the right person
[20:37:12] <jepler> TIL
[20:37:27] <cradek> I *think* the deb archive is signed by:
[20:37:27] <cradek> sec 1024D/8F374FEF 2008-04-15
[20:37:28] <cradek> uid EMC Archive Signing Key <emc-board@linuxcnc.org>
[20:37:42] <cradek> but I'm not that far yet...
[20:38:25] <cradek> huh jmk's key expired a few years ago
[20:38:59] <jepler> hm the docs imply that git show --show-signature should verify the signature by invoking gpg, but nothing happens for me
[20:42:01] <jepler> ok I can see that v2.5.0 was signed by BC92B87F and v2.7.4 was signed by 741499B0 "LinuxCNC Release Manager <emc-developers@lists.sourceforge.net>"
[20:42:29] <jepler> so if you have the latter key it's probably a better choice for signing
[20:42:43] <cradek> I don't have that one
[20:43:03] <cradek> I have
[20:43:03] <cradek> pub 2048R/54621DFA 2014-04-04 [expires: 2019-04-03]
[20:43:03] <cradek> uid LinuxCNC 2.6 Release Manager <seb@highlab.com>
[20:43:09] <cradek> but that's clearly just seb's
[20:43:27] <cradek> I'm going to wait for him and not guess :-)
[20:43:34] <jepler> yeah sounds good
[20:43:43] <cradek> pushing a bad tag is bad
[20:43:54] <jepler> one more interjection: I hope he won't turn off the hardy buildslave right after this release goes out; we should wait until it's clear there's no brown paper bag bug to fix
[20:44:29] <jepler> gitk shows 81 commits for v2.5.4..origin/v2.5_branch, there must be at least one mistake in there
[20:44:34] <cradek> this fixes several wrong-motion type bugs
[20:45:03] <cradek> I would bet at least $2 there isn't a new bug
[20:45:20] <cradek> we were very careful with each of these fixes
[20:45:28] <cradek> some of these went in 2.4!
[20:45:46] <jepler> it also helps that all those commits are guaranteed to be in 2.6.x etc
[20:45:51] <cradek> huh, 25 months since 2.5.4
[20:46:00] <cradek> yeah, yay for the mergeups
[20:46:25] <jepler> "biquad", I wonder what it is and who uses it
[20:47:02] <jepler> (https://en.wikipedia.org/wiki/Digital_biquad_filter)
[20:47:20] <jepler> peteg added it in 07
[20:48:53] <cradek> argh forgot to -s my release commit
[20:49:52] <cradek> oh good, there's a tag -f
[20:49:59] <cradek> now I'm ready, for reals
[20:50:50] <jepler> do I get the $2 if it's a bug in NURBS?
[20:51:06] <jepler> (not that I've spotted it, I'm just glancing at all the commits)
[20:51:07] <cradek> a *new* bug, yes
[20:51:58] <cradek> the NURBS path was totally wrong, previously
[20:53:34] <cradek> if you want to see the changelog: http://timeguy.com/gitweb?p=linuxcnc.git;a=log;h=refs/heads/v2.5_branch
[20:53:35] <jepler> yeah
[20:54:00] <jepler> anyway I glanced at each patch, paid at least cursory attention to ones that weren't doc changes, and I didn't spot anything
[20:54:08] <cradek> thank you
[20:54:16] <jepler> it's reassuring that a large number of those commits are from the addition of the SOB rules, we pulled in a bunch of commits from that
[20:54:29] <jepler> also a lot of docs and a lot of tests which is also reassuring
[20:56:52] <skunkworks_> I spent a couple hours playing with the tool changer - about 1/2 way through it. had to stop when a couple inputs where not hooked up yet
[20:57:00] <skunkworks_> linuxcnc is pretty darn cool
[21:02:27] <jepler> hm I wonder how much software breaks when you do this
[21:02:28] <jepler> https://lwn.net/SubscriberLink/686789/feb55c5aa3873526/
[21:04:00] <jepler> I mean, you won't believe how many applications break when you use this one weird trick
[21:04:32] <cradek> I wouldn't expect that to break much
[21:08:25] <skunkworks_> changer finds tool, moves up, down. In, out - collet clamps/unclamps. Started going though the sequence..
[21:08:35] <jepler> skunkworks_: fun times
[21:08:44] <jepler> hopefully linuxcnc isn't making it toooo easy
[21:08:47] <skunkworks_> It is. I like that sort of stuff.
[21:09:19] <skunkworks_> it is pretty easy. I have used it enough that I forget how a new user would be overwhelmed..
[21:10:11] <skunkworks_> I had to stop when we noticed the collet clamp/unclamp limit switches where missed when hooking up the inputs. More of dads home work ;)
[21:12:06] <jepler> even better if you have someone to do the physical wiring for you
[21:12:07] <skunkworks_> I am trying to set it up so I can also have a manual panel - for manually tickling the tool change sequences. I never got around to doing that on the K&T - if something goes wrong - estop - physically move things back to resting
[21:12:43] <cradek> nah, you can just fire up the ladder editor, hit stop, and poke things
[21:12:58] <skunkworks_> jepler, yes - it is nice. He has done an awesome job cleaning up the crap we don't need and wiring everything in.
[21:13:52] <skunkworks_> cradek, so far I have accidently named an output Q0 about 5 times.. (which puts the machine into estop)
[21:15:36] <skunkworks_> save the rung - bang - machine goes into estop. ;)
[21:16:34] <cradek> it's picky, isn't it
[21:19:44] <skunkworks_> I think I found on the k&t that you don't use the output in more than one place.. Seemed like such a great idea...
[21:27:57] <jepler> hm should have retitled that e-mail
[21:37:36] <andypugh> The update_ini script gives the URL http://wiki.linuxcnc.org/cgi-bin/wiki.pl?JointAxesBranch
[21:38:43] <andypugh> That isn’t the best docs, the best docs are at (for yesterday only….) http://buildbot.linuxcnc.org/doc/scratch/v2.8.0~pre1-ja~joints-axes13~0b86428/html/getting-started/updating-linuxcnc.html
[21:39:06] <andypugh> I wonder what the best way to manage this is?
[21:39:23] <jepler> I don't think those docs will go at a durable location until they're merged into a branch that gets its docs put on www.linuxcnc.org
[21:39:53] <jepler> the docs are in one of the pdfs we ship with the debs, of course, but we don't have an effective way to link "inside" a pdf document at the right page
[21:40:42] <jepler> so I think the best to be done right now is a mental note to update the URL once ja is merged to master
[21:41:07] <andypugh> Yes, that’s the problem. And the scratch docs go away eventually, I assume.
[21:41:16] <jepler> yes, though I don't know when
[21:41:40] <andypugh> Perhaps we can just occasionally paste a set of “real” docs into the Wiki page?
[21:42:44] <jepler> I don't mind if you choose to do that.
[21:43:41] <jepler> ooh interesting, a new macro lens from canon integrates a ring light into the lens body. too bad it only fits on EF-M cameras (their viewfinderless interchangeable lens cameras) http://www.dpreview.com/news/0802768407/canon-debuts-ef-m-28mm-f3-5-macro
[21:43:46] <andypugh> Is it possible to put straight html on a Wiki page?
[21:45:07] <jepler> duuno
[21:45:35] <jepler> I know or think I remember that limited html is accepted
[21:45:45] <jepler> but I've never tried literally cutting and pasting a whole html document into it
[21:50:15] <jepler> wow the wiki is not fast
[21:50:30] <jepler> anyway assuming it matches our version http://www.usemod.com/cgi-bin/wiki.pl?TextFormattingRules#HTML
[21:51:10] <jepler> somewhere down there it says allowing HTML is a security risk, so I hope we have it turned off :-/
[21:51:18] <andypugh> A straight paste is very much a partial success: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?JointAxesBranchTest
[21:52:47] <jepler> :-/ again
[21:54:14] <jepler> wow is the wiki always this slow?
[21:55:03] <seb_kuzminsky> cradek: sign with your BC92B87F key
[21:55:11] <seb_kuzminsky> same one that signed v2.5.0 - v2.5.4
[21:55:25] <cradek> jepler: a lot of the 'net isn't working right for me tonight
[21:55:40] <cradek> seb_kuzminsky: thank you
[21:55:58] <seb_kuzminsky> the buildbot verifies the signature on the release tags
[21:56:12] <jepler> ah hm yeah, the page loads quite fast from some other machine
[21:56:16] <jepler> so maybe it is my ISP
[21:56:23] <KGB-linuxcnc> 03Chris Radek 05v2.5_branch 92c698b 06linuxcnc 10VERSION 10debian/changelog Release 2.5.5 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=92c698b
[21:56:28] <seb_kuzminsky> in 2.5, the buildbot's key management was shoddy, and each buildslave user had to have the valid keys in their personal keyring
[21:56:31] <seb_kuzminsky> woo!!
[21:56:38] <seb_kuzminsky> in 2.6 and later it's shoddy in a different way
[21:56:38] <cradek> oh hell
[21:56:47] <cradek> I think I didn't push the tag with it
[21:56:55] <cradek> because the wiki wasn't loading and I didn't have that page in front of me anymore
[21:57:03] <seb_kuzminsky> that's not the end of the world
[21:57:11] <seb_kuzminsky> push the tag by itself
[21:57:26] <seb_kuzminsky> the buildbot will build that commit but call it 2.5.4-99 or whatever
[21:57:31] <jepler> cradek, seb_kuzminsky thank you for working on it
[21:57:40] <KGB-linuxcnc> 03Chris Radek 05signed tags a96531c 06linuxcnc 03v2.5.5 LinuxCNC v2.5.5 (tagged commit: 92c698b) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a96531c
[21:57:49] <cradek> siiiiigh
[21:57:49] <seb_kuzminsky> then when the tag is available we'll trigger a re-build and it'll build the same commit with the 2.5.5 version number
[21:57:52] <seb_kuzminsky> great
[21:57:53] <cradek> seb_kuzminsky: thanks :-)
[21:57:55] <seb_kuzminsky> thank you
[21:57:56] <jepler> seb_kuzminsky: do you have access to enough tuits to put the ja## docs at a durable location so that andypugh can link to them from the config converter?
[21:58:17] <seb_kuzminsky> sure
[21:58:23] <andypugh> raw asciidoc on the Wiki is at least legible: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?JointAxesBranchTest
[21:58:24] <cradek> git bites me so many different ways
[21:58:34] <seb_kuzminsky> do you want them on the buildbot or on wlo?
[21:58:51] <seb_kuzminsky> cradek: great power/great responsibility/nag/nag
[21:59:08] <jepler> andypugh: either is fine (buildbot or wlo) as long as the link will work from now until ja is merged, right?
[21:59:16] <seb_kuzminsky> we use a lot of mercurial at work and it's awful compared to git
[21:59:18] <andypugh> I think wlo is the place. I am hopeful that they will be there pretty soon anyway
[21:59:23] <cradek> yeah yeah
[21:59:27] <jepler> you'll still have to change the URL though
[21:59:31] <jepler> from ja to master to 3.0
[21:59:42] <andypugh> Yeah, I am fine with that
[21:59:45] <seb_kuzminsky> or maybe it's just that i have a decade or two of experience with git, and only a few months with hg
[21:59:48] <cradek> I'd trade some power for sensible defaults and a consistent commandline interface
[21:59:53] <seb_kuzminsky> heh
[22:00:05] <jepler> oh hg, I saw what you said but read bzr
[22:00:21] <seb_kuzminsky> ok i'll rsync the most recent ja docs to wlo, justasec
[22:00:24] <andypugh> Anyone tried Accurev?
[22:01:08] <cradek> never even heard of it
[22:02:39] <jepler> there's also "fossil", the SCM that I've only ever heard of being used with tcl/tk: http://wiki.tcl.tk/19821 (ugh that's got to not help drive new developers)
[22:04:34] <seb_kuzminsky> hm, my old ssh pubkey is no longer accepted by wlo
[22:04:49] <seb_kuzminsky> debug1: Skipping ssh-dss key /home/seb/steel-home/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
[22:04:52] <seb_kuzminsky> debug1: Skipping ssh-dss key /home/seb/steel-home/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
[22:04:55] <seb_kuzminsky> debug1: Skipping ssh-dss key /home/seb/steel-home/.ssh/id_dsa - not in PubkeyAcceptedKeyTypes
[22:04:58] <seb_kuzminsky> oops, once would have been enough
[22:05:05] <seb_kuzminsky> can someone put my new rsa key in authorized_keys?
[22:05:36] <seb_kuzminsky> http://highlab.com/~seb/id_rsa.pub
[22:06:10] <seb_kuzminsky> i set up a separate ssh key for the buildbot to rsync docs to wlo, but it only allows rsync on the far side, not a shell
[22:06:18] <jepler> http://lists.mindrot.org/pipermail/openssh-unix-announce/2015-August/000122.html
[22:06:21] <jepler> * Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled
[22:06:24] <jepler> by default at run-time. These may be re-enabled using the
[22:06:27] <jepler> instructions at http://www.openssh.com/legacy.html
[22:06:37] <jepler> wow cradek is using software at least as new as August 2015
[22:06:40] <jepler> afk and goodnight
[22:06:43] <cradek> :-P
[22:06:57] <cradek> you mean on wlo, not glo?
[22:07:01] <seb_kuzminsky> yeah
[22:07:01] <andypugh> There seem to be many SCM systems I have never heard of: https://en.wikipedia.org/wiki/Comparison_of_version_control_software
[22:07:08] <seb_kuzminsky> goodnight jepler
[22:07:42] <andypugh> They use Accurev at work. But I don’t. so I don’t know if it is nice or not.
[22:07:51] <cradek> seb_kuzminsky: should this one have a command= ?
[22:08:27] <cradek> well I'll let you figure that out - I added it
[22:08:48] <seb_kuzminsky> good, thanks
[22:10:07] <andypugh> Can you bung me an email when there is a linkable version of the docs? it’s time for me to sleep.
[22:11:52] <seb_kuzminsky> andypugh: http://linuxcnc.org/docs/ja/
[22:11:58] <seb_kuzminsky> email on its way
[22:20:08] <seb_kuzminsky> thanks for making the release cradek
[22:20:21] <seb_kuzminsky> i'll cajole the buildbot along
[22:20:41] <seb_kuzminsky> and i'll leave the hardy buildslave around for a while, in case something unexpected happens
[23:21:26] <linuxcnc-build> build #304 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/304 blamelist: Chris Radek <chris@timeguy.com>
[23:28:50] <seb_kuzminsky> that's ok
[23:41:20] <linuxcnc-build> build #1439 of 4000.deb-hardy-rtai-i386 is complete: Failure [4failed shell_1] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/4000.deb-hardy-rtai-i386/builds/1439 blamelist: Chris Radek <chris@timeguy.com>