Back
[07:10:32] <KGB-linuxcnc> 03John Thornton 05master 88f0d5c 06linuxcnc 10(25 files in 2 dirs) Configs: remove old plasma config that is too complicated * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=88f0d5c
[07:12:34] <linuxcnc-build> build #721 of precise-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/721 blamelist: John Thornton <jthornton@gnipsel.com>
[07:17:23] * jthornton wonders how I broke it this time?
[07:18:20] <linuxcnc-build> build #1518 of precise-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1518 blamelist: John Thornton <jthornton@gnipsel.com>
[07:18:55] <linuxcnc-build> build #1315 of precise-amd64-sim-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/1315 blamelist: John Thornton <jthornton@gnipsel.com>
[07:18:57] <linuxcnc-build> build #1520 of precise-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1520 blamelist: John Thornton <jthornton@gnipsel.com>
[07:19:27] <linuxcnc-build> build #1520 of lucid-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1520 blamelist: John Thornton <jthornton@gnipsel.com>
[07:19:28] <linuxcnc-build> build #1517 of lucid-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1517 blamelist: John Thornton <jthornton@gnipsel.com>
[07:20:18] <linuxcnc-build> build #1516 of lucid-rtai-i386-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-rtai-i386-clang/builds/1516 blamelist: John Thornton <jthornton@gnipsel.com>
[07:20:26] <KGB-linuxcnc> 03Jeff Epler 05master 90a2fc5 06linuxcnc 10src/Makefile build: this configuration directory no longer exists * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=90a2fc5
[07:20:30] <jepler> jthornton: fixed by my push, I think ^^
[07:20:55] <jthornton> jepler, thanks
[07:21:30] <linuxcnc-build> build #1519 of lucid-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1519 blamelist: John Thornton <jthornton@gnipsel.com>
[07:22:08] <jepler> fwiw I also got this message when pushing:
[07:22:09] <jepler> remote: warning: refname 'bdi-4' is ambiguous.
[07:22:21] <linuxcnc-build> build #1521 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1521 blamelist: John Thornton <jthornton@gnipsel.com>
[07:23:05] <linuxcnc-build> build #1516 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1516 blamelist: John Thornton <jthornton@gnipsel.com>
[07:23:09] <linuxcnc-build> build #1519 of hardy-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1519 blamelist: John Thornton <jthornton@gnipsel.com>
[07:23:10] <linuxcnc-build> build #1521 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1521 blamelist: John Thornton <jthornton@gnipsel.com>
[07:23:40] <jepler> so it may be related to cradek's recent upgrade of git
[07:24:34] <jthornton> I got a strange message yesterday when I did a git pull --rebase so I got a fresh copy of master last night
[07:24:57] <cradek> yesterday I replaced that bdi-4 tag with bdi4
[07:25:02] <cradek> tried to anyway?
[07:25:29] <jepler> cradek: that doesn't get rid of the tag in everybody's existing clones
[07:26:00] <cradek> oh. I thought it was a server-side warning
[07:28:16] <jepler> jthornton: you didn't say what your "strange message" was, but it could have been related to commit bc1bc5
[07:28:42] <jthornton> I'm not sure but it might have been the bdi-4 tag message
[07:28:55] <jthornton> I don't have that terminal open any more
[07:29:14] <jepler> cradek: I sure don't know, but since I agree it looks like the bdi-4 tag is gone from git.l.o, and yet I got the message just now, it seems like it might have something to do with me having the bdi-4 tag locally
[07:30:08] <jepler> cradek: but with "push.default=current" I have no idea why my git push would be announcing tags to the server, soooo...
[07:30:42] <jepler> bbl
[09:19:18] <cradek> I have no idea why this has just appeared.
[10:22:41] <seb_kuzminsky> morning folks
[10:23:03] <seb_kuzminsky> i'm in favor of making newbies' first run work every time
[10:23:17] <JT-Shop> me too
[10:23:37] <seb_kuzminsky> i like the idea of making the obvious first thing to try be a guaranteed-to-work sim config
[10:23:45] <seb_kuzminsky> by making it more prominent in the configpicker list
[10:23:48] <JT-Shop> it's very frustrating for a newbee to press run on a sim and it breaks
[10:23:53] <seb_kuzminsky> yeah :-(
[10:23:58] <cradek> JT-Shop: before that
[10:24:06] <cradek> just finding the right sim config is very hard
[10:24:16] <seb_kuzminsky> JT-Shop: unforch our current splash code has that problem
[10:24:26] <JT-Shop> yep
[10:24:28] <cradek> there are a hundred configs in the tree that simply won't work
[10:24:28] <seb_kuzminsky> and our current config list has the problem cradek is talking about
[10:24:45] <seb_kuzminsky> cradek: ... and that won't be fixed because no one has the hardware and/or cares
[10:25:29] <cradek> seb_kuzminsky: which that?
[10:25:55] <seb_kuzminsky> oh, that the list is cluttered with broken/out-of-date configs that make the useful ones disappear in the noise
[10:26:15] <seb_kuzminsky> i like dgarr's idea of keeping "maybe useful but currently broken" configs in the git repo, but hidden away from first-timers
[10:26:35] <seb_kuzminsky> i dont like the idea of putting them on the wiki, i think
[10:26:48] <seb_kuzminsky> things on the wiki get even less attention that unused things in our repo
[10:27:42] <seb_kuzminsky> so, i'd favor removing truly useless dead configs, and putting "maybe useless" configs in an Attic directory or soemthing
[10:27:56] <seb_kuzminsky> where they can be found if someone actually wants them, but dont clutter up the view for noobs
[10:28:06] <cradek> ok maybe I should limit my proposal: the things that show up on the config picker are the things that will run if you pick them. to a good approximation this means the union of 1) the sim configs and 2) the ones you've generated with stepconf etc and 3) whatever samples you've copied into ~/linuxcnc/configs and modified
[10:28:20] <dgarr> i will make a patch for pickconfig to try to make sim at top or more obvious somehow -- later this week
[10:29:16] <cradek> so maybe the Attic (examples for hardware you probably don't have) need to be removed from the config picker but not the distribution? they could still be on the filesystem.
[10:32:23] <JT-Shop> I think less is better in the config picker, something like Axis Sim, NGCGUI Sim, Touchy Sim, Pico, Mesa, Other Hardware so there is only a few directories to pick from
[10:32:50] <seb_kuzminsky> cradek: some thing match "probably wont run on your machine" but should still probably be in the config picker... i'm thinking hm2-servo and hm2-stepper specifically, maybe others
[10:32:57] <JT-Shop> is there still a problem with subdirectories in the config picker?
[10:32:59] <seb_kuzminsky> or can those be rebuilt by pncconf now? i dont even know
[10:33:07] <seb_kuzminsky> JT-Shop: i think subdirs work fine
[10:33:15] <JT-Shop> ok, great
[10:37:49] <dgarr> meanwhile, i have a patch (work in progress) for making hal pins from some of the ini file settings. Current version (with version number in commit message) is at:
[10:37:51] <dgarr> http://www.panix.com/~dgarrett/stuff/inihal.patch
[10:38:24] <dgarr> There is a sim test configuration named configs/sim/ngcgui/ini_hal_demo that pops up a gui for simulating some pins
[10:38:40] <cradek> wow
[10:41:52] <dgarr> i'm confused about [TRAJ]default_velocity and emcTrajSetVelocity()
[11:09:00] <seb_kuzminsky> very cool dgarr
[11:55:58] <jepler> installing linuxcnc build deps: Need to get 745 MB of archives.
[11:56:06] <jepler> with --no-install-recommends: Need to get 172 MB of archives.
[11:56:10] <jepler> that's quite the difference
[12:07:41] * jepler considers whether it makes sense to make a debian/configure --without-docs
[12:08:10] <jepler> it would only be useful for people who want to use mk-build-deps to get build dependencies but don't ever want to build docs
[12:13:23] <jepler> mah also hasn't taken any action on license issues in the master branch since my e-mail of September 18; he did at least remove the Apple files from ub3 but I don't see that he fixed any other problems in that branch to address the license issues I outlined September 11.
[12:13:30] <jepler> that's disheartening since he's the biggest offender
[12:14:34] <jepler> I know that other people did fix problems on the master branch (me, seb, andy, you at least)
[12:14:37] <cradek> he said he would, and he recently said life has been interfering with linuxcnc work
[12:15:20] <jepler> or maybe he's too busy on the linuxcnc lecture circuit
[12:15:30] <jepler> ooh it's lunchtime
[12:15:31] <cradek> in my mind, the remedy is don't merge that branch for 2.6
[12:15:36] <cradek> yeah there's that
[12:16:34] <jepler> master branch still has about 20 files in src/ which have his thumbprints on them and no adequate license statement
[12:16:39] <jepler> we can't very well not merge master
[12:17:17] <cradek> sigh
[12:18:01] <jepler> real 0m27.364s
[12:18:05] <jepler> ooh this new computer builds linuxcnc fast
[12:18:15] <cradek> I have 70 messages flagged ~F in emc-developers which means I thought they needed my further consideration or response
[12:18:24] <cradek> I suppose your license message is in there
[12:19:00] <cradek> yep
[12:19:19] <jepler> ccache brings it down more: real 0m10.689s
[12:19:21] <jepler> anyway, lunch
[12:19:53] <seb_kuzminsky> mah also has a bunch of fixmes in his remapping docs
[12:20:03] <seb_kuzminsky> i've poked him about it but he ignored me
[12:20:23] <seb_kuzminsky> i guess to pay me back for ignoring him about all his new development that he wants feedback on?
[12:21:03] <seb_kuzminsky> jepler: what new computer did you buy?
[13:23:06] <jepler> seb_kuzminsky: $DAY_JOB has recently replaced my desktop with a i7-4930K
[13:23:44] <skunkworks> ooh - 4th gen i7.. How do you like it?
[13:24:12] <jepler> it is pretty fast, though $DAY_JOB software still takes minutes and minutes to build.
[13:24:34] <skunkworks> I have a first gen in my laptop - other than it being a furnace.. (partly because of video)
[13:24:43] <skunkworks> it runs quite nice
[13:25:14] <jepler> previous machine was Core 2 Duo E8500g
[13:25:16] <jepler> s/g$//
[13:25:38] <jepler> going from 2 threads to 12 threads is a huge benefit when building software
[13:25:47] <skunkworks> I bet
[13:25:53] <jepler> .. I routinely get 1170% CPU usage in a build
[13:26:11] <jepler> (average over a 10+ minute build, peak is 1200%)
[13:26:22] <jepler> and frankly that's awesome
[13:26:23] <skunkworks> http://electronicsam.com/images/KandT/testing/Screenshot-1.png
[13:26:26] <skunkworks> heh
[13:27:37] <jepler> skunkworks: that's not much slower than mine!
[13:27:49] <skunkworks> (that is from a few years ago...)
[13:27:56] <jepler> oh so not current master branch?
[13:28:10] <skunkworks> no
[13:28:14] <skunkworks> I am not that quick
[13:28:22] <jepler> real 0m27.613s
[13:28:22] <jepler> user 4m31.509s
[13:28:22] <jepler> sys 0m14.173s
[13:28:34] <jepler> so the complexity of our software is keeping pace with the increase in CPU speeds to hold build times constant
[13:28:37] <jepler> how nice
[13:28:42] <skunkworks> heh
[13:28:45] <cradek> :-/
[13:29:46] <jepler> v2.5_branch: real 0m14.838s
[13:29:46] <jepler> user 1m22.313s
[14:16:31] <skunkworks> well - I can't test any longer programs with the new tp as it goes into orbit. (thanks seb - that is an awesome analogy..)
[14:17:02] <seb_kuzminsky> wait what?
[14:17:07] <skunkworks> heh
[14:17:20] <seb_kuzminsky> oh the solar system thing? :-)
[14:17:36] <skunkworks> yes
[14:18:04] <seb_kuzminsky> rfc: drop ja4 from 2.6?
[14:18:36] <seb_kuzminsky> rationale: it's got known outstanding issues, and i think it should have a more complete test suite, and the new rtos work is more important to get out
[14:18:37] <skunkworks> So I just have to wait for an update. (or learn a bunch of motion control theory)
[14:18:44] <seb_kuzminsky> save ja4 for 2.7
[14:18:47] <seb_kuzminsky> what you say!
[14:19:23] <skunkworks> For me - i think the unified build is a bit more important..
[14:19:34] <skunkworks> Just a bit..
[14:20:14] <seb_kuzminsky> i'm on the fence about the "unified build" part of the unified-build branch
[14:20:24] <seb_kuzminsky> i think the new rtos kernel support is awesome and i want it
[14:20:47] <seb_kuzminsky> all the other things in that branch are obstacles to getting that nugget of goodness into master, imo
[14:21:04] <jepler> I have vaguely had the same thought, but not to the point of doing the work to separate the two
[14:21:28] <skunkworks> what/how much gets us a chance to be in debian?
[14:22:09] <seb_kuzminsky> to get into debian we'd need to support a realtime kernel that's in debian, and... i think that's it
[14:22:24] <seb_kuzminsky> the ub stuff may help, but i dont know
[14:22:24] <jepler> and in debian 7 that's rt-preempt, the userspace realtime flavor
[14:22:51] <jepler> seb_kuzminsky: from your pov, is the xenomai or rt-preempt realtime flavor more important in the 2.6 timeframe?
[14:23:12] <seb_kuzminsky> xenomai, since it opens up beaglebone black
[14:23:25] <seb_kuzminsky> but i think we get both, or none
[14:23:45] <skunkworks> the rt-preempt and xenomai also opens the door to ethernet devices
[14:23:50] <jepler> xenomai userspace or xenomai kernel space? Aren't both supported in UB3?
[14:23:57] <seb_kuzminsky> i think that's further down the road, no?
[14:24:22] <seb_kuzminsky> err, rt ethernet needs more than just a new kernel, right skunkworks ?
[14:24:38] <seb_kuzminsky> and jepler , i think xeno user is the one on charles' machinekit image
[14:25:17] <skunkworks> Well - we need to ask peter - but I think xenomai requires rtnet - but preeemt doesn't..
[14:25:55] <skunkworks> I have been testing the xenomai and rtnet
[14:26:01] <seb_kuzminsky> that stuff is in the post-2.6 timeframe, imo
[14:26:19] <seb_kuzminsky> we need to stop adding features to the 2.6 list, and focus on getting what we've already committed to out the door
[14:26:25] <jepler> I agree with seb_kuzminsky
[14:26:58] <seb_kuzminsky> then we should try to do 2.7 on a shorter time scale, but notice i didnt volunteer to do it
[14:27:10] <cradek> I hope we'd merge ja4 after making the 2.6 branch
[14:27:30] <seb_kuzminsky> so, speaking of 2.6, any objections to delaying ja4 until later? there's known bugs (no jogwheel) and lack of tests for such a deep change
[14:27:44] <seb_kuzminsky> cradek read my mind
[14:28:53] <jepler> fwiw I would participate in weekend or "evening" (early evening to seb_kuzminsky) code sprints to pull out the new realtime stuff from the unified-build branch, but I don't really know that the concept of a code sprint works over a network...
[14:29:19] <jepler> .. this month
[14:29:55] <seb_kuzminsky> i'm worried about the political/emotional fallout of separating things in the ub branch
[14:30:11] * seb_kuzminsky is too sensitive to be a good release manager
[14:30:19] <jepler> I never realized you were sensitive
[14:30:51] <seb_kuzminsky> did i say sensitive? i meant autistic
[14:31:03] <jepler> I was thinking like sensitive skin, but then you shave so that just didn't make sense.
[14:31:20] <seb_kuzminsky> i just stopped shaving! i'm all bushy-faced now
[14:31:26] <jepler> oh that's surprising
[14:31:41] <seb_kuzminsky> it just hurt my sensitive skin too much, i couldnt take it
[14:31:49] <cradek> it's getting silly in here
[14:31:52] <jepler> pixels or your quantum state hasn't actually been collapsed by the observer
[14:32:09] * jepler has been reading too much Greg Egan
[14:32:20] <jepler> .. his ears were burning
[14:32:26] <seb_kuzminsky> did you like clockwork rocket?
[14:32:46] <jepler> yes
[14:32:57] <jepler> and now I know the final volume will have a 2014 US publication date
[14:33:37] <seb_kuzminsky> i'd be up for a sprint this month some time
[14:34:08] <seb_kuzminsky> not sure what execatly we'd work on, but there's sure plenty to do
[14:35:19] <seb_kuzminsky> i think with ja4 delayed for now, the top item is the new rtos branch (whatever that means), including its kernels
[14:37:45] <seb_kuzminsky> we should maybe also think about how our deb archive is signed
[14:38:08] <seb_kuzminsky> i think if the new rtai kernel was in there, it'd be easier for folks to test it out and we'd get more feedback sooner
[15:32:33] <andypugh> i guess there is a danger of 2.6 being our Mach4.
[15:32:48] <andypugh> Something so ambitious that folk get bored waiting for it.
[15:36:54] <seb_kuzminsky> it was ~2 years between 2.4.0 and 2.5.0, and so far it's only been 1 year 9 months since 2.5.0
[15:37:41] <seb_kuzminsky> let's get 2.6.0 out, then try to do 2.7 in something closer to 6 or 12 months instead of 24
[15:45:25] <andypugh> I have been targetting 2.7 for the tool table. (Actually, the Master-after-2.6)
[15:46:11] <andypugh> Though I can't claim to have worked on that much since Wichita, other than a brief spurt to push something for people to ignore.
[15:46:31] <seb_kuzminsky> that's how we do it, apparently
[15:47:27] <seb_kuzminsky> i like the idea of people developing features in side branches, then offering them for merging shortly after the release branch is made, for inclusion in the next release a handful of months down the road
[15:48:11] <seb_kuzminsky> then the N+1 release manager merges all the features that are ready, and we make a new release branch, and the cycle repeats
[15:49:08] <seb_kuzminsky> little things like bugfixes dont have to follow that cadence, but if big changes did, it might be easier to manage
[15:51:25] <seb_kuzminsky> dgarr: patches might reach a more specific audience on the emc-developers list, rather than emc-users
[16:11:59] <KGB-linuxcnc> 03Michael Haberler 05zultron-ubc3-dev 3ac79be 06linuxcnc 10(9 files in 6 dirs) Merge remote-tracking branch 'origin/master' into unified-build-candidate-3 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3ac79be
[16:12:00] <KGB-linuxcnc> 03John Morris 05zultron-ubc3-dev cdf9757 06linuxcnc 10src/configure.in Rework usermode PCI driver logic * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cdf9757
[16:12:00] <KGB-linuxcnc> 03John Morris 05zultron-ubc3-dev 9704d9e 06linuxcnc 10.gitattributes .gitattributes: don't export git artifacts into tarball archives * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9704d9e
[16:12:01] <KGB-linuxcnc> 03John Morris 05zultron-ubc3-dev 8eda21b 06linuxcnc 10src/emc/pythonplugin/Submakefile 10src/emc/rs274ngc/Submakefile 10src/emc/task/Submakefile Submakefiles: Add $(Q) to several linker commands * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8eda21b
[16:12:06] <KGB-linuxcnc> 03John Morris 05zultron-ubc3-dev c9a7602 06linuxcnc 10src/configure.in configure.in: Look for tkConfig.sh in /usr/lib64 also * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c9a7602
[16:12:10] <KGB-linuxcnc> 03John Morris 05zultron-ubc3-dev 793d56d 06linuxcnc 10(5 files in 5 dirs) linuxcncrsh tests: use 'tcping' when no 'nc -z' available * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=793d56d
[16:12:14] <KGB-linuxcnc> 03John Morris 05zultron-ubc3-dev 2af4d25 06linuxcnc 10src/configure.in configure.in: replace 'tempfile' with distro-agnostic 'mktemp' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2af4d25
[16:15:04] <cmorley> It might be a good idea to discuss the 2.6 release changes (proposed or already decided?) on the mail list
[16:18:43] <seb_kuzminsky> cmorley: you're right
[16:19:02] <seb_kuzminsky> it's only discussed at this point
[16:20:12] <cmorley> ya good to broaden the audience and then most people are on same page. :)
[16:20:33] <cmorley> of course it will probably be heated at some point :)
[16:20:46] <cradek> and bike sheds
[16:21:25] <seb_kuzminsky> heated opinions are fine, i guess, but if no one steps up to do the work, all the opinions in the world dont matter
[16:24:30] <andypugh> As we know that there are problems with JA4, then I can see that you could drop that. (I say "you" because all I can do is heckle from the sidelines). I think separating out UBC from the kernel support might be a lot of effort for a gain I can't see.
[16:25:33] <linuxcnc-build> build #1523 of hardy-amd64-sim is complete: Failure [4failed configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1523 blamelist: John Morris <john@zultron.com>, Michael Haberler <git@mah.priv.at>
[16:26:15] <linuxcnc-build> build #1518 of hardy-i386-realtime-rip is complete: Failure [4failed configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1518 blamelist: John Morris <john@zultron.com>, Michael Haberler <git@mah.priv.at>
[16:26:32] <linuxcnc-build> build #1521 of hardy-i386-sim is complete: Failure [4failed configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1521 blamelist: John Morris <john@zultron.com>, Michael Haberler <git@mah.priv.at>
[16:29:27] <KGB-linuxcnc> 03Chris Morley 05master 78d09b3 06linuxcnc 10lib/python/gladevcp/combi_dro.py gladevcp -fix some error messages with combi_dro * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=78d09b3
[16:29:28] <KGB-linuxcnc> 03Chris Morley 05master d96f36d 06linuxcnc 10share/gscreen/skins/gaxis/gaxis_handler.py 10share/gscreen/skins/gmoccapy/gmoccapy_handler.py 10share/gscreen/skins/industrial/industrial_handler.py 10src/emc/usr_intf/gscreen/gscreen.py gscreen/gmoccapy -fix a sequencing problem with embedded objects * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d96f36d
[17:04:08] <linuxcnc-build> build #1523 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1523 blamelist: John Morris <john@zultron.com>, Michael Haberler <git@mah.priv.at>
[17:08:13] <seb_kuzminsky> cmorley: ok, email sent
[17:15:26] <andypugh> I would love to help with the tools, but my skills are not in that area.
[17:15:55] <seb_kuzminsky> which tools do you mean? i'd love to teach what i know
[17:17:36] <andypugh> I am thinking in terms of the config mungers, stepconf, etc. I am still in the foothills of the Python learning curve, I only really understand registers.
[17:18:11] <seb_kuzminsky> aha, the config-maker tools
[17:19:09] <andypugh> Indeed, I could spend months learning the tools and eventually produce something inferior to what someone else could do in an afternoon.
[17:19:31] <andypugh> It's not a great motivation, knowing that.
[17:20:49] <seb_kuzminsky> i know that feeling
[17:20:52] <seb_kuzminsky> but
[17:20:54] <andypugh> Conversely, when something comes up like table-mode in Hostmot2 stepgen that I think I can do in a couple of hours, then I am happy to spend 3 days to find I was wrong :-)
[17:21:07] <cradek> I bet we all do
[17:21:14] <seb_kuzminsky> if you do the work and they don't, then you did better anyway
[17:21:59] <andypugh> A fair point.
[17:22:22] <cradek> I wonder if jogwheel works on trivkins configs in ja4
[17:22:33] <seb_kuzminsky> if we had a test, we'd know! ;-)
[17:22:39] <andypugh> I could probably learn a lot munging Stepconf to understand JA3.
[17:23:07] <cradek> I bet you could do that easily (once you understood the config changes needed)
[17:23:32] <cradek> it plugs some numbers into some boilerplate. you'd change the boilerplate. [... he said without looking]
[17:23:37] <jepler> as long as you don't make the mistake of also biting off "oh I'll make it work for gantries too"
[17:23:43] <seb_kuzminsky> i pushed that motion-tests branch a bit ago, it adds the beginnings of a test of continuous jogs, it's not done yet but it could be extended to do jogwheel tests pretty easily i think
[17:23:46] <andypugh> But then, I don't like stepconf. It ought to use the HAL/INI as input and not blindly over-write stuff.
[17:24:13] <cradek> andypugh: eh, see my recent rant that nobody cared about
[17:24:16] <jepler> people can write things in .hal and even .ini files which are way too crafty for a program to figure out and present as a gui
[17:24:24] <andypugh> Oh! Look! feature creep!
[17:24:26] <jepler> particularly now that .hal files can be Tcl programs or something
[17:24:33] <cradek> we sacrifice a lot at the altar of human-editable config files
[17:24:43] <seb_kuzminsky> cradek: and we gain a lot too
[17:25:23] <seb_kuzminsky> cradek, jepler: i want to schedule a meeting with you some time it works for us all to talk about deb archive management on w.l.o
[17:25:23] <cradek> yes, we're both right
[17:25:33] <seb_kuzminsky> <--- pointy hair
[17:25:41] <cradek> schedule a ... meeting !?
[17:26:14] <cradek> there's a key to sign the repo, several of us have it
[17:26:16] <seb_kuzminsky> i just want to understand how it's been done in the past, and how i can get access (since i think it's the norm for the RM to manage the deb archive too)
[17:26:42] <seb_kuzminsky> i dont necessarily want to do it now since i'm at work...
[17:26:50] <cradek> sure, I can send it to you
[17:26:52] <andypugh> I spend a lot of my replies on the forum saying "Well done, you now understand what is possible better than the config wizards do, it is time to edit the files directly". Actually, I have never said that, but I will next time, it souds so much more positive :-)
[17:26:55] <cradek> jepler: any objection?
[17:26:56] <seb_kuzminsky> but maybe sharing that key with me would be easy and not too insecure
[17:27:00] <jepler> yeah, I think we just give you the key we've already used, even though it's got some now-inappropriate "real name" on it
[17:27:11] <jepler> I don't suppose you guys have each other's gpgs?
[17:27:26] <cradek> sure, I'll send it in gpg-encrypted email
[17:27:32] <seb_kuzminsky> i think i have a gpg key that i made in like 2004, i might even have the passphrase for it still
[17:27:39] <cradek> seb_kuzminsky: you've got a key in the keyservers?
[17:27:52] <seb_kuzminsky> i dont think so, but i guess i should
[17:27:59] <seb_kuzminsky> let me sort that out and i'll mail you a link
[17:28:29] <cradek> ok
[17:28:47] <cradek> btw
http://timeguy.com/cradek/key
[17:30:50] <cradek> gpg: key 1BB63D53: public key "Sebastian Kuzminsky <seb@highlab.com>" imported
[17:32:03] <cradek> I sent you a test message.
[17:32:26] <cmorley> seb_kuzminsky: thanks for that.
[17:32:31] <cradek> you knew the passphrase 8 years ago...
[17:32:50] <seb_kuzminsky> i wrote it down on a sticky note on my monitor, i bet i can still find it
[17:33:29] <cradek> yep that's what I do
[17:51:22] <cradek> seb_kuzminsky: sent you the keypair
[18:26:24] <seb_kuzminsky> thanks cradek
[18:27:26] <cradek> your response is incorrect
[18:29:23] <cradek> I mean, the email
[18:29:28] <cradek> saying thanks is perfectly fine
[18:29:39] <cradek> but your email is unreadable
[18:40:19] <cradek> aha, I decoded it, but it's not pgp/mime, the standard since uh 1996 (wow)
[18:41:39] <skunkworks> the yahoo groups have an issue of not displaying the message in the web interface if it is formated wrongly..
[18:43:43] <cradek> unfortunately few people today can successfully send and receive encrypted email
[18:46:10] <seb_kuzminsky> cradek: hrm. i typed 'gpg --sign --encrypt --armour $FILE' and pasted the result into thunderbird
[18:46:10] <skunkworks> like
[18:46:12] <skunkworks> http://groups.yahoo.com/neo/groups/DIY-CNC/conversations/messages/33545
[18:46:23] <seb_kuzminsky> i wonder what i'm supposed to do
[18:46:42] <cradek> seb_kuzminsky: tell thunderbird to encrypt it, and it'll generate the right mime parts etc
[18:47:13] <cradek> seb_kuzminsky: of course I have no idea how to tell it that :-/
[18:48:29] <cradek> in mutt, you hit p (pgp) e (encrypt) and it guesses the target from the To: and asks you to confirm the pubkey to use
[18:48:47] <cradek> then it encrypts with yours AND mine, so I can read it in my outbox if I want
[18:49:01] <seb_kuzminsky> i've been resisting mutt, not sure why
[18:49:18] <cradek> there's gotta be a way modern peoples do the same thing :-)
[18:49:55] <cradek> wonder what charles uses - he pgp signs his mails
[18:50:13] <andypugh> modern peoples dont't care. They don't even know thery should care. This is bad.
[18:50:25] <seb_kuzminsky> there's an extension to thunderbird called "enigmail" that purports to do the pgp thing
[18:50:35] <cradek> yeah he uses Thunderbird/24.1.1
[18:51:26] <cradek> X-Enigmail-Version: 1.6
[18:51:32] <cradek> and yes, enigmail apparently
[18:52:47] <cradek> andypugh: they care, but they are helpless, because the free services they use serve someone else's interests
[18:54:09] <cradek> skunkworks: all I get is a redirect to some login page
[18:54:11] <andypugh> Enigma-email woud be sort-of fun. If you texted the code wheel settings and refrained from sendind a weather report, it would be fairly secure.
[18:55:48] <andypugh> You would absoloutely not have to encrypt the headers though, those are far too static
[18:56:02] <cradek> yeah, bad news
[18:56:28] <cradek> I don't like that pgp/mime sends the subject in plaintext (I'm stubborn enough to not use a real subject)
[18:57:37] <andypugh> I am knowledgable enough to know I should care, and lazy enough to not care.
[18:58:45] <andypugh> I would encrypt immediately if I had any reason to believe that the folk I email would be able to decrypt, but in general they wouldn't.
[18:59:26] <cradek> yes there's sure a bootstrap problem
[19:00:07] <cradek> I set up everything in 2003 and have probably sent a dozen encrypted emails since then
[19:01:05] <andypugh> It's also curious that tor.com is largely unerwritten by the US government, while at the same time a different section is trying to hack it. That really is the bleeding-edge of open-source.
[19:01:15] <cradek> ha
[19:01:52] <cradek> I also use tor sometimes. it's great.
[19:33:21] <skunkworks> cradek: yeck
[19:33:23] <skunkworks> sory
[19:33:26] <skunkworks> sorry
[19:33:58] <cradek> ?
[20:56:00] <skunkworks> cradek: I thought that was an open list..
[21:02:16] <cradek> logger[mah]: ?
[21:02:16] <logger[mah]> cradek: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-12-03.html
