Back
[02:26:13] <KGB-linuxcnc> 03Chris Morley 05master ac2b8a1 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py gscreen -add constants,verbose printing,generalize mode detection. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ac2b8a1
[02:26:13] <KGB-linuxcnc> 03Chris Morley 05master f35fab0 06linuxcnc 10src/emc/usr_intf/gscreen/Submakefile 03src/emc/usr_intf/gscreen/keybindings.py gscreen -add a generalized keybinding lookup code file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f35fab0
[02:26:13] <KGB-linuxcnc> 03Chris Morley 05master 6c716b0 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py gscreen -use the new keybinding code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6c716b0
[02:26:15] <KGB-linuxcnc> 03Chris Morley 05master 8712aaa 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf -fix debug mode switch and a debug print error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8712aaa
[02:26:19] <KGB-linuxcnc> 03Chris Morley 05master d84cb00 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py gscreen - fix default jog increments, check for dialog handler * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d84cb00
[02:26:23] <KGB-linuxcnc> 03Chris Morley 05master c4118e3 06linuxcnc 10configs/sim/gscreen_custom/gscreen_gaxis.ini 10share/gscreen/skins/gaxis/gaxis.glade 10share/gscreen/skins/gaxis/gaxis_handler.py gscreen gaxis -update Gaxis skin * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c4118e3
[10:03:13] <memleak> seb_kuzminsky, thanks for the credit :)
[10:03:26] <memleak> crediting.. credition.. ?
[10:30:51] <seb_kuzminsky> blame
[10:31:31] <seb_kuzminsky> memleak: do you have an opinion on paolo's recent rtai 4.0 release?
[12:37:41] <ju-emb> Seb is updating this(I think).We did the install yesterday from a temp build and it worked
[12:39:25] <cradek> yeah I'm installing build-deps now...
[12:40:48] <seb_kuzminsky> cradek: it's partially because i messed up the version number on the new kernel package, and partially because linuxcnc's kernel dependency is versioned too strictly
[12:41:20] <seb_kuzminsky> i'm finishing testing the updated deb archive with the new kernel, then i'll push it to w.l.o, update the buildbot, rebuild, and things should be back to working
[12:41:29] <seb_kuzminsky> then i'll mail out something to the emc-users list asking people to test
[12:41:38] <seb_kuzminsky> now i'm glad i procrastinated asking people to test -rtai-1
[12:43:33] <cradek> weird, xubuntu installed without any swap
[12:43:47] <cradek> seb_kuzminsky: I'll build from source and see what happens
[12:43:52] <seb_kuzminsky> ok
[12:43:53] <cradek> seb_kuzminsky: thanks for fixing it up
[12:43:55] <seb_kuzminsky> should be fine
[12:44:11] <seb_kuzminsky> ju-emb tried it yesterday and it worked
[12:44:37] <ju-emb> my guys are hooking up the pc we did the install yesterday to a machine now
[12:44:45] <seb_kuzminsky> sweet! :-)
[12:44:50] <cradek> ju-emb: did your ATA start working with the new kernel rtai-2?
[12:45:03] <seb_kuzminsky> yeah, it was the initrd that you fixed for him
[12:45:06] <ju-emb> yes, all is perfect
[12:45:14] <cradek> that's a very good sign
[12:45:29] <cradek> I still had blinking-monitor syndrome with it, however
[12:45:31] <ju-emb> and it's pretty fast
[12:45:43] <cradek> so I put a panel on the dvi and it's working
[12:46:26] <ju-emb> that issue whit blinking monitor I know
[12:46:41] <seb_kuzminsky> cradek: i dont know what to do about that
[12:46:49] <ju-emb> the actual machine has a via GPU
[12:46:57] <seb_kuzminsky> maybe memleak has some ideas? he's our kernel guy now, i'm just the half-assed packager
[12:47:00] <cradek> it's probably just nvidia/nouveau breakage and my remedy is to not use their cards
[12:47:29] <ju-emb> exactly, it's a graphic driver problem
[12:47:30] <cradek> I'm not asking you to fix it - I don't think it's likely to be our breakage
[12:47:57] <ju-emb> nividia and ATI don't give out there sources or documentation
[12:48:18] <cradek> yeah, I know all about that misery
[12:48:19] <ju-emb> for the GPU's
[12:49:17] <seb_kuzminsky> i try to stay with 1-year-old intel hardware
[12:49:22] <ju-emb> if somebody has that problem with his on Board Chip set, best is to install another Graphic card
[12:50:50] <ju-emb> the new ones works well and the really old ones work well, it's just a few chip releases having that problem
[12:58:57] <cradek> yay, finally building
[13:00:01] <seb_kuzminsky> cool
[13:00:09] <seb_kuzminsky> i'm pushing the new rtai kernel debs to the w.l.o deb archive now
[13:00:13] <seb_kuzminsky> oh, it just finished!
[13:00:44] <archivist> I had a couple of blinking monitor crashes on a Dell the other day, but its a free issue one I am working on and have another pc one to try
[13:01:03] <seb_kuzminsky> oh man, things are working so well this morning, for once no hairy yaks are stampeding across my projects
[13:01:18] <cradek> hey, I resent that
[13:01:37] <seb_kuzminsky> ok, the only hairy yak this morning is cradek
[13:01:39] <seb_kuzminsky> better?
[13:01:42] <cradek> yay
[13:01:44] <archivist> I resemble that
[13:02:19] <cradek> /usr/src/linux-headers-3.4.55-rtai-2/include/linux/types.h:13:2: warning: #warning "Attempt to use kernel headers from user space, see
http://kernelnewbies.org/KernelHeaders" [-Wcpp]
[13:02:26] <cradek> it sure does like giving this warning
[13:02:35] <seb_kuzminsky> only about 1e3 of them
[13:03:14] <ju-emb> there'll come a few more of them, but it works well
[13:03:16] <cradek> it'd be so nice if I could hook my stepper mill to the external port on the 5i25 and then make a panel with the touchy hard controls and hook it to the extra internal one
[13:03:30] <seb_kuzminsky> cradek:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Todo-2.6, 1.2.7
[13:04:14] <cradek> aha
[13:04:20] <ju-emb> those warning are while builing hal
[13:08:00] <seb_kuzminsky> linuxcnc-build: force build checkin
[13:08:01] <linuxcnc-build> build forced [ETA 1h30m32s]
[13:08:01] <linuxcnc-build> I'll give a shout when the build finishes
[13:08:27] <seb_kuzminsky> ok, that's building on -rtai-2 on the precise rtai buildslave now
[13:08:42] <cradek> awesome
[13:10:27] <ju-emb> still don't know what all that means, but I try to get into it
[13:11:01] <seb_kuzminsky> ju-emb: you mean that compile warning? i think it's a bug in the rtai kernel headers
[13:11:28] <ju-emb> no I mean the workflow you guys have
[13:12:12] <ju-emb> all machines and tools you use
[13:12:44] <ju-emb> I mean the tools for building LCNC and the kernels
[13:15:06] <seb_kuzminsky> oh i see
[13:15:06] <memleak> whats the kernel issue that you suggested i help with, seb_kuzminsky?
[13:15:21] <ju-emb> who mainly is doing the Python stuff here?
[13:15:34] <memleak> and i dont follow paolo's code anymore, so as for the rtai 4.0 release i have no clue
[13:15:56] <seb_kuzminsky> memleak: ok, bummer, i was hoping you guys would merge and cooperate, but i know what's not always easy or possible
[13:16:12] <memleak> seb_kuzminsky, i havent looked at RTAI in a few months
[13:16:19] <seb_kuzminsky> memleak:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Todo-2.6, issue number 1.2.7
[13:16:28] <seb_kuzminsky> it's a compile warning with the rtai kernel headers
[13:16:38] <memleak> i brought the project back to life then just stopped working on it and following it
[13:17:26] <memleak> 1.2.7 is just RTAI clean up that needs to be done
[13:17:43] <seb_kuzminsky> it's an issue you know about? and you know the fix for? awesome :-)
[13:18:04] <memleak> RTAI is filled with warnings that are simply just warnings
[13:18:49] <memleak> the fix i dont know though, im sure i could figure it out given the time
[13:19:12] <memleak> the easy way would be to have -Wno-cpp enabled
[13:19:37] <memleak> magic.
[13:21:11] <memleak> hey what do you know! i did know how to fix it!
[13:21:51] <seb_kuzminsky> well, turning off the warning and fixing the thing it's warning about are different ;-)
[13:23:20] <memleak> is the warning telling us to use headers from userspace or that we are using headers from userspace and we shouldn't?
[13:26:01] <memleak> secondly does header userspace mean /lib/headers/ or /usr/src/linux/include ?
[13:29:25] <seb_kuzminsky> "Attempt to use kernel headers from user space"
[13:29:51] <seb_kuzminsky> so i guess a userspace program is including a header file that should only be used in kernel space
[13:30:10] <andypugh> Sounds like the imperative tense to me. But I bet it isn't.
[13:31:23] <seb_kuzminsky> i think kernel headers are often partially visible from user-space code, and i'm guessing the protection in that header is off a bit
[13:31:27] <seb_kuzminsky> maybe
[13:33:37] <jepler> <linux/types.h> should refer to /usr/include/linux/types.h but it must not because we specify -I /usr/src/linux-headers-3.4.55-rtai-1/include
[13:33:45] <jepler> .. when building objects for userspace
[13:34:10] <memleak> so all we do is remove the -I and the crap after it and its fixed?
[13:34:40] <jepler> well .. someone probably put the -I for some reason
[13:35:05] <memleak> a lot of code in RTAI needs to be removed, i wouldnt put it past them
[13:35:59] <cradek> whee, my stepconf-generated config runs
[13:36:06] <seb_kuzminsky> jepler: that sounds bogus
[13:36:10] <seb_kuzminsky> cradek: that sounds awesome
[13:36:34] <memleak> seb_kuzminsky, that was funny
[13:36:37] <jepler> configure isn't clear about where the flag comes from
[13:37:15] <memleak> which version of RTAI are we talking about here? redo, master or tarballs?
[13:37:20] <jepler> I wonder if it is coming from rtai-config
[13:38:03] <seb_kuzminsky> memleak: an old version of master from
https://github.com/ShabbyX/RTAI.git
[13:38:18] <seb_kuzminsky> commit a0dc5355ee233032926dd23d1e132ef1befbbd76 to be exact
[13:38:35] <seb_kuzminsky> from early august
[13:39:07] <memleak> wow i havent checked that repo in months! damn that repo has been busy!
[13:39:10] <memleak> jeeze..
[13:39:56] <seb_kuzminsky> memleak: looks like just a dozen commits or so since then
[13:40:05] <seb_kuzminsky> on the master branch, i mean
[13:40:14] <seb_kuzminsky> oh, i guess one of those is a merge of magma...
[13:40:35] <jepler> OK, so the reason we have the kernel included in userspace is a 2007 commit by me
[13:40:55] <seb_kuzminsky> < jepler> well .. someone probably put the -I for some reason
[13:40:58] <jepler> 3f14f5e It is necessary to have the true kernel headers on my x86-64 machine
[13:41:24] <jepler> too bad I didn't explain any more than that :-/
[13:41:44] <memleak> its also necessary to have -ffast-math on my x86_64 machine btw therefor i need to modify the linuxcnc source code in order to compile anything on my end
[13:42:14] <jepler> consider adding a configure test for this condition
[13:42:17] <seb_kuzminsky> memleak: do you have a modern rtai kernel running on x86_64? that's cool...
[13:42:21] <jepler> that way you don't have to patch your source
[13:42:35] <seb_kuzminsky> bbl
[13:43:09] <memleak> seb_kuzminsky, 3.4.67 was the latest i ever had going
[13:43:30] <memleak> bumping it to 3.4.74 (the latest in the 3.4 series) should be no problem at all
[13:43:42] <memleak> i doubt you'd even have one conflict
[13:44:25] <KGB-linuxcnc> 03Jeff Epler 05jepler/try-no-kernel-headers e5ad357 06linuxcnc 10src/Makefile Revert "It is necessary to have the true kernel headers ..." * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e5ad357
[13:48:00] <cradek> darn, the splash screen isn't scaleable anymore. I was going to make a microscopic one.
[13:48:31] <jepler> It was scalable?
[13:48:32] <memleak> heh
[13:48:43] <cradek> yeah, a while ago it was
[13:58:50] <seb_kuzminsky> it still has a comment saying it's scalable
[13:59:24] <seb_kuzminsky> 2.6 todo item #25 ;-)
[14:02:26] <ju-emb> memleak: you have a RTAI running on x86_64 that's really cool
[14:02:49] <ju-emb> that I like to give a shot next
[14:11:40] <memleak> i was the first to get it going on 3.x kernels earlier this year
[14:11:55] <memleak> biggest pain ever but worth it i guess
[14:14:18] <cradek> http://timeguy.com/cradek-files/emc/precise-rtai-master.jpg
[14:17:51] <skunkworks> cradek: what machine is that?
[14:17:59] <cradek> I did it on max
[14:18:19] <cradek> I almost made it too big for the lowest power on my microscope
[14:18:27] <skunkworks> wow - I didn't know the max had that high of resolution..
[14:18:37] <cradek> yeah it's pretty good at small stuff
[14:19:14] <skunkworks> Neat!
[14:21:31] <KGB-linuxcnc> 03Chris Radek 05master ca61881 06linuxcnc 10share/axis/images/axis.ngc Make the AXIS splash screen scaleable again * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ca61881
[14:22:10] <cradek> it worked surprisingly well to point my phone at the microscope eyepiece
[14:22:46] <cradek> good work memleak and seb_kuzminsky and everyone else! it's going to work.
[14:22:49] <cradek> bbl
[14:28:28] <jepler> cradek: nic
[14:28:29] <jepler> e
[14:28:38] <jepler> can we have a "smallest linuxcnc" contest now?
[14:29:24] <linuxcnc-build> Hey! build checkin #1558 is complete: Success [3build successful]
[14:29:24] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1558
[14:31:44] <andypugh> I don't see any reason that LinuxCNC couldn't control an AFM.
[14:57:32] <seb_kuzminsky> andypugh: i've often daydreamed about that too :-)
[14:57:58] <seb_kuzminsky> we have a guy at the hackspace who's built an stm before...
[15:10:14] <andypugh> If i was still working at Dage I think that LinuxCNC would be controlling x-ray microscopes.
[15:25:26] <jepler> seb_kuzminsky: I'll let you judge whether to merge jepler/try-no-kernel-headers after buildbot finishes chewing on it. It does seem to have gotten rid of those -Wcpp diagnostics in
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-realtime-rip/builds/759/steps/compile
[15:38:15] <seb_kuzminsky> jepler: i see no reason not to, if all the slaves finish their work
[16:35:21] <seb_kuzminsky> linuxcnc-build: force build --branch=v2.5_branch checkin
[16:35:30] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[16:53:28] <seb_kuzminsky> i'm planning to mail this out to the emc-users list, any feedback first?
[16:53:30] <seb_kuzminsky> http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_On_Ubuntu_Precise
[16:55:48] <cradek> trying it now
[16:56:50] <cradek> shouldn't the linuxcnc install pull in the kernel? I mean isn't #6 unnecessary?
[16:59:26] <cradek> Recommended packages:
[16:59:26] <cradek> hostmot2-firmware
[16:59:34] <cradek> this isn't installable
[17:00:37] <seb_kuzminsky> i think you're right, 6 is superfluous
[17:00:48] <seb_kuzminsky> hmm, hostmot2-firmware should be in w.l.o/precise/base
[17:01:02] <seb_kuzminsky> .... but it aint, wtf
[17:01:12] <cradek> on the CNC menu, clicking user manual gives me Error: no "view" mailcap rules found for type "application/pdf"
[17:01:56] <seb_kuzminsky> it's called hostmot2-firmware-all, not that other thing
[17:02:28] <cradek> E: Unable to locate package hostmot2-firmware-all
[17:03:13] <cradek> otoh, the linuxcnc package does install and run, yay
[17:04:00] <seb_kuzminsky> lucid and hardy have symlinks in base/binary-i386 pointing at binary-all for the firmware debs
[17:04:10] <seb_kuzminsky> i thought binary-all was sufficient
[17:04:47] <seb_kuzminsky> oh, no Packages file gets built for binary-all
[17:05:12] <seb_kuzminsky> because it's missing from generate.conf
[17:05:29] <andypugh> I thought is was just some form of placeholder?
[17:05:50] <seb_kuzminsky> no, it's real, for packages which can be installed on any architectures, with no dependency on the binary arch
[17:05:53] <seb_kuzminsky> such as firmare
[17:05:57] <seb_kuzminsky> firmware
[17:06:15] <andypugh> (I think that the package manager describes it as a meta-package)
[17:12:39] <seb_kuzminsky> huh, that's funny, there is no binary-all in ubuntu
[17:12:46] <seb_kuzminsky> when did that go away? or did i imagine in?
[17:16:34] <seb_kuzminsky> looks like debian 2.0 "hamm" was the last one to have a binary-all:
http://archive.debian.org/debian/dists/hamm/main/
[17:16:44] <seb_kuzminsky> i guess i spaced out there for a while... since.. 1999
[17:17:09] <seb_kuzminsky> ok, i'll just do for precise what we already do for lucid: symlink binary-all/* to binary-i386 and binary-amd64
[17:25:01] <seb_kuzminsky> ok, now the hostmot2-firmware-* packages are available, but none of the Provide hostmot2-firmware, so the linuxcnc Recommends is not fulfillable
[17:25:46] <seb_kuzminsky> i think this is not a precise bug or a master bug, i think it's in 2.5 as well, for older distros as well
[17:26:51] <cradek> well crap...
[17:27:02] <cradek> should we fix it or ignore it?
[17:27:09] <seb_kuzminsky> though the fact we didnt notice until now makes me think i'm wrong
[17:29:29] <seb_kuzminsky> i guess the easy thing to do would be to make a commit in 2.5 to change the Recommends to hostmot2-firmware-all
[17:30:37] <seb_kuzminsky> it'll pull in... 4.4 megs of firmware, on top of the ~12 MB of linuxcnc + docs, so no big deal there
[17:30:45] <seb_kuzminsky> and it's a one-time download
[17:31:08] <seb_kuzminsky> so that'd be my recommendation
[17:32:35] <seb_kuzminsky> also, about your earlier comment on having the install instructions not install the kernel explicitly...
[17:32:57] <seb_kuzminsky> i think i prefer to do it explicitly, so we can reboot after that step and make sure linuxcnc will run after the later install step
[17:33:30] <cradek> oh ok
[17:33:39] <cradek> I don't have any strong feelings about it
[17:34:27] <seb_kuzminsky> if you want, i'll make the change in 2.5 and merge it to master
[17:34:37] <seb_kuzminsky> about the hostmot2-firmware vs -all
[17:35:11] <cradek> please
[17:35:15] <seb_kuzminsky> ok
[17:39:12] <seb_kuzminsky> oh no!
[17:39:29] <seb_kuzminsky> hostmot2-firmware-all is buggy! it's missing all its dependencies, so it doesnt install anything :-(
[17:39:43] <seb_kuzminsky> le sigh
[17:39:58] <seb_kuzminsky> ok, i've got to go, i'll deal with this later :-/
[17:40:09] <cradek> arg
[17:45:50] <cradek> http://timeguy.com/cradek-files/emc/tool-length-sensor.jpg
[17:49:08] <jepler> did you notice that before or after jamming a tool down onto it?
[17:49:35] <cradek> uh-oh, notice what?
[17:49:41] <cradek> (it works...)
[17:50:42] <cradek> someone asked me about it and I finally took a picture, that's all
[17:50:55] <seb_kuzminsky> if you use a large diameter cutter, can yyou hit the shcs?
[17:51:17] <cradek> haha if I could put a 1" end mill in my 1/8" spindle, possibly
[17:51:23] <seb_kuzminsky> heh
[17:51:43] <cradek> that huuuuuge SHCS is 1/4-20
[17:52:39] <seb_kuzminsky> hostmot2.git/debian/control misspelled Depends as Requires
[17:52:52] <cradek> !!
[17:52:55] <cradek> so you found it already :-)
[17:56:13] <seb_kuzminsky> ok, i pushed a commit to hostmot2-firmware.git, we'll see if this works...
[17:56:44] <cradek> go buildbot go
[17:57:19] <skunkworks> it is always something!
[17:57:21] <skunkworks> ;)
[17:58:22] <seb_kuzminsky> cradek: i think the hostmot2 git repo didnt poke the hm2 buildbot correctly
[17:58:30] <seb_kuzminsky> can you check the post-receive hook?
[17:58:32] <jepler> cradek: it looked like the right solder connection had come loose
[17:58:48] <jepler> cradek: but I assumed there was something going wrong because immediately before you'd said "arg"
[17:59:09] <seb_kuzminsky> he was arghing about the hostmot2 packages i think
[17:59:21] <jepler> oh
[17:59:31] <seb_kuzminsky> it might be on my side, i probably forgot to poke a hole in the new firewall for the hm2 buildbot
[17:59:35] <jepler> I should say, I thought I'd committed a fix for that problem an age ago
[17:59:46] <jepler> the dependency problem
[17:59:56] <seb_kuzminsky> i didnt see a fix for it in hm2.git master
[18:00:10] <jepler> it rang a bell anyway
[18:00:23] <jepler> probably someone told me and then I imagined fixing it
[18:00:23] <andypugh> I have known for a long time that hostmot2-firmware-all doesn't install anything. I just assumed that it was meant to be like that, and it was my ignorance that meant I couldn't figure out the point of it.
[18:00:23] <jepler> :-/
[18:00:46] <jepler> I'll go away again now
[18:00:47] <cradek> seb_kuzminsky: oops fixed
[18:00:55] <cradek> seb_kuzminsky: I had a bug too
[18:01:11] <seb_kuzminsky> you're ahead of me in bug-fixing
[18:01:12] <cradek> seb_kuzminsky: 5133
[18:01:21] <seb_kuzminsky> heh, 5-13-3, e-m-c
[18:01:47] <seb_kuzminsky> no, it's supposed to be 8132, h-m-2
[18:01:56] <seb_kuzminsky> 5133 is the linuxcnc buildbot
[18:02:03] <seb_kuzminsky> and my firewall is wrong
[18:02:58] <cradek> oops you're right, 8132
[18:03:12] <andypugh> The Synaptic Package manager description of hostmot2-firmware-all says "This is an empty package that depends on tall the separately packaged firmware images". So I had assumed that it wasn't meant to install anything, being empty, and all that.
[18:04:28] <seb_kuzm1nsky> ok im back
[18:06:11] <seb_kuzm1nsky> hm2-buildmaster_: force build
[18:06:12] <hm2-buildmaster_> you must provide a Builder, try 'force build [--branch=BRANCH] [--revision=REVISION] [--props=PROP1=VAL1,PROP2=VAL2...] <WHICH> <REASON>'
[18:06:25] <cradek> I think I can poke the hook
[18:07:00] <cradek> ?
[18:09:00] <cradek> hope he's making his changes from inside the firewall...
[18:12:59] <cradek> bbl
[18:21:53] <seb_kuzm1nsky> hm2-buildmaster: force build build
[18:21:58] <hm2-buildmaster> build #7 forced
[18:21:58] <hm2-buildmaster> I'll give a shout when the build finishes
[18:22:03] <seb_kuzm1nsky> that felt like a silly thing to say
[18:22:11] <seb_kuzm1nsky> bbl
[18:45:32] <hm2-buildmaster> Hey! build build #7 is complete: Success [3build successful]
[18:45:32] <hm2-buildmaster> Build details are at
http://localhost:8020/builders/build/builds/7
[19:54:14] <andypugh> A thought... The CNC menu for Pncconf perhaps ought to call it "Mesa card config wizard"
[19:56:54] <pcw_home> Or use hal pins like I suggested before it was even started...
[20:00:35] <andypugh> How it is called out in the menu is a different issue.
[20:01:37] <andypugh> But you really did pull the rug out from under Chris' feet with your Smart-serial and lots of new cards. He thought he had a simple and well contained system to handle :-)
[20:04:25] <pcw_home> I never intended that there be standard configurations...
[20:06:25] <andypugh> The paradigm should have been one of interogating attached hardware from the start.
[20:06:53] <pcw_home> Thats is the HM2 paradigm
[20:07:44] <andypugh> One day I might look at making it easier to interrogate the hardware without actually trying to run it.
[20:08:21] <pcw_home> whats missing is some configuration agnostic metadata for a more flexible hal file generator
[20:09:58] <pcw_home> (the halcmd show -xml option)
[20:10:52] <pcw_home> and a file that knows some boilerplate affinities for various hal pins
