Back
[00:39:11] <linuxcnc-build> build #1633 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1633
[01:43:48] <KGB-linuxcnc> 03Chris Morley 05master 1ad20eb 06linuxcnc 10src/emc/usr_intf/gscreen/gscreen.py gscreen -fix early setting of states from preference file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1ad20eb
[01:43:48] <KGB-linuxcnc> 03Chris Morley 05master 633a09f 06linuxcnc 10share/gscreen/skins/gmoccapy/gmoccapy_handler.py gmoccapy - fix imperial-as-default-preference bug * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=633a09f
[02:18:44] <linuxcnc-build> build #1634 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1634 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[02:22:05] <linuxcnc-build> build #1632 of hardy-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1632 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[02:39:22] <linuxcnc-build> build #1634 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1634 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[11:36:53] <dgarr> any objections to adding this contributed patch for TB6560 boads?
http://www.panix.com/~dgarrett/stuff/0001-Initial-Addition-of-TB6560-Configs.patch
[11:39:08] <archivist> dgarr, Longshine is reasonably common too
[11:44:07] <atom1> tried running 2.6 with robEllenberg's TP
[11:44:18] <atom1> loaded the hostmot2 drivers
[11:44:23] <atom1> then unloaded and quit
[11:44:32] <atom1> dmesg didn't show anything unusual
[11:44:48] <atom1> Starting HAL User Interface program: halui
[11:44:48] <atom1> Killing task linuxcncsvr, PID=3953
[11:44:48] <atom1> Removing HAL_LIB, RTAPI, and Real Time OS modules
[11:44:48] <atom1> Removing NML shared memory segments
[11:44:58] <atom1> last few lines of the log
[11:50:27] <seb_kuzminsky> linuxcnc-build: force build --branch=master checkin
[11:50:28] <linuxcnc-build> build #1635 forced
[11:50:28] <linuxcnc-build> I'll give a shout when the build finishes
[12:29:40] <KGB-linuxcnc> 03Norbert Schechner 05master e3b3630 06linuxcnc 10share/gscreen/skins/gmoccapy/gmoccapy_handler.py 10share/gscreen/skins/gmoccapy/release_notes.txt gmoccapy_0_9_9_7_5 - typo in initialize_preferences * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e3b3630
[13:14:01] <linuxcnc-build> Hey! build checkin #1635 is complete: Success [3build successful]
[13:14:01] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1635
[15:51:51] <seb_kuzminsky> zultron: ubc3's configure looks for libudev.... what's that used for?
[16:15:33] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder 6188806 06linuxcnc 10(19 files in 2 dirs) stepconf -refactor to use GTK Builder and Notebook * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6188806
[16:15:33] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder b3bf2ee 06linuxcnc 10src/emc/usr_intf/stepconf/base.glade 10src/emc/usr_intf/stepconf/pages.py 10src/emc/usr_intf/stepconf/stepconf.py stepconf -have stepconf reset the axis defaults on unit change * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b3bf2ee
[16:15:33] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder 0b19ba1 06linuxcnc 10src/emc/usr_intf/stepconf/finished.glade 10src/emc/usr_intf/stepconf/main_page.glade 10src/emc/usr_intf/stepconf/pages.py 10src/emc/usr_intf/stepconf/stepconf.py stepconf -make the navigation buttons direct the user * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0b19ba1
[16:15:37] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder 479342b 06linuxcnc 10(6 files) stepconf -add a second parallel port signal selection page * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=479342b
[16:15:41] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder 4680440 06linuxcnc 03src/emc/usr_intf/stepconf/pport2.glade stepconnf -oops for got glade file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4680440
[16:15:45] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder f753c15 06linuxcnc 10src/emc/usr_intf/stepconf/stepconf.py stepconf -fix axis test to use up to two parports * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f753c15
[16:15:49] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder c0e4ada 06linuxcnc 10src/emc/usr_intf/stepconf/pages.py 10src/emc/usr_intf/stepconf/pport1.glade 10src/emc/usr_intf/stepconf/stepconf.py stepconf -add output presets for TB6560 board * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c0e4ada
[16:27:42] <zultron> seb_kuzminsky, libudev is for Charles's user-mode PCI drivers.
[16:28:30] <seb_kuzminsky> ah, ok
[16:30:41] <seb_kuzminsky> so it's only used for the userspace thread styles?
[16:31:21] <seb_kuzminsky> ie the posix, rtpreempt-user, and xenomai-user flavors, do i have the terminology right?
[16:32:41] <zultron> Right.
[16:34:52] <zultron> I got rid of the '-user' extension, so the list is posix, xenomai, rt-preempt, xenomai-kernel, rtai-kernel.
[16:35:35] <seb_kuzminsky> aha, thanks
[16:38:55] <zultron> Depending on how you want to do it, all builders can build all flavors if the right build deps are present by running simple './configure'; alternatively, a flavor-specific builder can be told to build a single flavor with e.g. './configure --with-rtai-kernel'.
[16:39:51] <zultron> (I'm assuming you're updating the buildbot. :)
[16:39:59] <seb_kuzminsky> i'm working on it ;-)
[16:41:39] <seb_kuzminsky> your commit ed1e9c36ea25bc20a16b97c7a10aaf6a978aadba broke src/autogen.sh on Hardy, but i think we decided at some point to drop hardy support for 2.6, and i'm wondering now if that's because ubc3 needed libudev
[16:42:30] <seb_kuzminsky> if so, we can maybe still ship 2.6 on hardy by not building the flavors that need libudev on hardy
[16:42:53] <zultron> I'm setting up a buildbot for RH distros. I tell all builders to build all flavors. That may not be useful for testing LinuxCNC, but it uncovered a number of problems in my buildbot, kernel-headers pkgs, etc.
[16:43:07] <seb_kuzminsky> i guess we'd still want to ship the posix flavor (that's what we used to call sim, right?) on hardy, but we could disable the usermode pci stuff on posix on hardy
[16:43:44] <zultron> Hardy's broken for two reasons.
[16:44:32] <zultron> One is libudev, but I may have put in a fix to not build usermode PCI drivers when that's absent, I forget.
[16:45:00] <seb_kuzminsky> src/configure checks for it, and i assume it disables the parts that need it, but i'm not sure
[16:45:29] <zultron> Other is the configure.in m4 macros in that commit you pointed out.
[16:46:10] <zultron> Jeff pointed out the problem in an emc-dev post. That's fixable, too.
[16:47:07] <seb_kuzminsky> hardy has autoconf 2.61 and m4 1.4.10, lucid has 2.65 and 1.4.13... maybe we should just have ubc3 build-depend on autoconf >= 2.65, and disable hardy that way?
[16:48:56] <zultron> Well, what does 'disable hardy' mean, exactly?
[16:49:27] <seb_kuzminsky> teach it not to try to build ubc3 on hardy
[16:49:39] <seb_kuzminsky> still build older branches that work on hardy
[16:49:53] <zultron> The hardy pkg builders will attempt to build packages whether or not the source packaging has a build-dep, won't they?
[16:50:27] <seb_kuzminsky> my buildbot has a three-stage build process:
[16:50:44] <seb_kuzminsky> 1. try run-in-place & runtests on every platform
[16:51:04] <seb_kuzminsky> 2. if none failed, try to build all source packages
[16:51:11] <seb_kuzminsky> 3. build the source packages into binary packages
[16:51:39] <seb_kuzminsky> i can change 1 so that if hardy fails, it doesn't stop the others from continuing with 2 and 3
[16:51:40] <zultron> Does #3 have a conditional as well?
[16:51:56] <zultron> Ok
[16:52:30] <seb_kuzminsky> i dont remember, it might, but we can control it with the haltOnFailure property and friends
[16:52:32] <zultron> My feeling is that you'd want to filter out UBC3 checkins.
[16:52:58] <seb_kuzminsky> i'd rather not maintain a list of branches-to-platforms mappings if i can avoid it
[16:53:23] <zultron> buildbot has a feature to filter changesets, which could be configured to discard any changeset that has some specified ancestor commit.
[16:54:10] <zultron> Not sure if that can be applied to builders or not, though.
[16:54:30] <seb_kuzminsky> i think it applies to triggers
[16:55:02] <seb_kuzminsky> you can imagine a buildstep that checks for that special commit, if it's running on a special platform... but i don't like the smell of that
[16:55:25] <zultron> That's what I'm imagining. :)
[16:56:00] <seb_kuzminsky> last time i thought about this i imagined a scripts/platform-is-supported script that would exit yea or nay if it thinks the platform it's running on is supported by the checked out branch
[16:56:08] <zultron> I don't like the smell of telling hardy to attempt a build of something known to fail.
[16:56:32] <seb_kuzminsky> i see your point
[16:57:11] <zultron> But I don't know the correct answer right now....
[16:57:24] <seb_kuzminsky> me neither
[16:57:59] <seb_kuzminsky> in general i prefer to put smarts in the repo instead of in the buildbot - it's easier to maintain
[16:59:18] <zultron> repo = Debian archive? Or repo = glo/linuxcnc.git?
[16:59:33] <seb_kuzminsky> repo = git repo
[16:59:54] <seb_kuzminsky> for example, the get-version-from-git script is easier to maintain than a special buildstep inside the buildbot
[17:01:52] <zultron> What's the 'get-version-from-git' script?
[17:02:06] <zultron> Oh, I see.
[17:02:30] <seb_kuzminsky> just a little helper script, only ever used by the buildbot as far as i know, but it's in the git repo instead of in a build step
[17:03:27] <zultron> So in your scripted build step, you'd run 'get-version-from-git' and grep for ubc3 or something? Then what?
[17:03:44] <seb_kuzminsky> that's not what i was suggesting
[17:04:07] <seb_kuzminsky> that was just an example to illustrate my preference
[17:04:27] <seb_kuzminsky> but imagine another script, maybe called "platform-is-supported", living right next to get-version-from-git
[17:04:47] <zultron> Oh, got it: 'i imagined a scripts/platform-is-supported script that would exit yea or nay'
[17:04:54] <seb_kuzminsky> this script would be run by each builder, right after 'git clone'
[17:04:57] <zultron> That would be a separate step
[17:05:01] <seb_kuzminsky> yeah
[17:05:21] <zultron> And if it fails, following build steps won't be run, but it won't be considered an overall failure?
[17:05:28] <seb_kuzminsky> if the script exits 0 (or if the script doesn't exist, probably), the build proceeds
[17:05:47] <seb_kuzminsky> if the script exists and exits 1, then the build does not start, and that builder reports success
[17:05:52] <seb_kuzminsky> yes exactly
[17:05:53] <zultron> Got it.
[17:06:11] <zultron> That sounds great.
[17:06:51] <seb_kuzminsky> just an idea, haven't tried it yet, but it seems feasible
[17:07:49] <seb_kuzminsky> it's a bit redundant, since in theory the build-dependencies should tell us the same information
[17:07:56] <zultron> I confess I don't understand how to set up a buildbot workflow that isn't simply a sequence of steps, but includes conditionals, ignores some failures but not others, or other such things.
[17:08:23] <seb_kuzminsky> there should be examples of that in the master.cfg script i sent you guys a while ago
[17:08:32] <seb_kuzminsky> are you using that, or did you start from scratch?
[17:09:05] <andypugh> zultron: Any idea how much work I am lettign myself in for trying to build xenomai/arm kernels for Udoo?
[17:09:35] <seb_kuzminsky> check out buildbot's 'doStepIf', and the Trigger step
[17:09:43] <seb_kuzminsky> anyway, got to go, seeya later
[17:09:47] <zultron> Sure. If you don't mind making up a ShellCommand step, you could probably do something to check the build deps easily enough.
[17:09:50] <zultron> Ok CU
[17:10:41] <andypugh> As an experiment I tried the machinekit BB kernel deb, but it refused to consider it.
[17:10:42] <zultron> andypugh, not sure. Do you already have the Udoo's OS installed with Xenomai kernel?
[17:10:50] <zultron> Ah
[17:11:08] <andypugh> Currently I have a 12.04 Ubuntu on there.
[17:11:11] <zultron> What form did its refusal take?
[17:11:20] <andypugh> I am trying to remember :-)
[17:12:00] <zultron> I'm trying to remember what Charles told me (and you should probably shoot him an email).
[17:12:48] <zultron> If Charles's kernel doesn't work on the Udoo, it might be difficult to build a kernel that does.
[17:13:17] <andypugh> I think it complained that the kernel deb was armhf and the platform was arml. Something like that.
[17:14:27] <zultron> Well, I have no experience, but I'd first try rebuilding Charles's kernel source pkg, unchanged, on the Udoo.
[17:15:03] <zultron> That may not work, since all these ARM CPUs seem to have their own needs for special patches.
[17:15:32] <andypugh> I am starting with the Udoo kernel git, and was going to xenomai-patch that insrtead
[17:16:35] <zultron> If it didn't work, I'd then probably try to modify the Udoo's kernel source with Xenomai, but I imagine needing to crib from Charles's package building system.
[17:17:15] <zultron> There're these weird pre- and post-patches you'll need to get Xenomai working for any ARM CPU.
[17:18:15] <zultron> That's the trick, AFAIK. I'd cross my fingers that the BeagleBone patches worked for Udoo.
[18:25:19] <mhaberler> seb_kuzminsky: libudev is essential for the kernel thread flavors, the shared memory driver uses udev rules
[21:10:09] <piranha32> hi
[21:11:04] <cradek> I can't believe people want to use machines that can't run X. I used to run X on my 386-33.
[21:11:13] <cradek> I don't understand this new trend
[21:16:00] <piranha32> anybowy works with linuxcnc on beaglebone?
[21:16:05] <piranha32> anybody
[21:16:55] <cradek> piranha32: go ahead and ask your real question
[21:17:54] <piranha32> I need to recompile kernel, but I have never worked with xenomai. Is there a howto specific for machinekit?
[21:43:11] <CaptHindsight> cradek: I don't get it either. Of all the ARM boards why the one with the GPU that isn't useful for a UI?
[21:47:08] <memleak> The Xorg server itself can run on anything 32-bit whether ARM, x86, PPC as long as it has a video output connector.
[21:49:14] <atom1> I found something a bit odd testing the circular blend code so i tried it again with master and found the same thing: In the MDI window if i enter a tool change ie: 'T1 M6 G43 H1' nothing happens and i see no activity in halconfig related to toolchange however if i run a gcode file the manual tool change dialog box pops up and a tool change occurs.
[21:50:42] <atom1> running my configs from 2.5.3
[21:51:13] <cradek> atom1: what branch are you testing?
[21:51:30] <atom1> i just pulled master and tested it
[21:51:47] <atom1> https://github.com/robEllenberg/linuxcnc-mirror.git
[21:51:54] <atom1> was the blend code i was testing
[21:52:38] <cradek> rellenberg doesn't hang out here - you'll have to ask on the emc-developers list
[21:52:40] <atom1> i'm recompiling it to try again just in case something got muffed up
[21:53:11] <atom1> master acted the same way
[21:53:52] <cradek> master of what repo?
[21:54:12] <atom1> you'll have to spell it out for me, i'm quite new to this
[21:54:18] <atom1> i'm running 10.04
[21:54:25] <skunkworks> atom show the git command you used to pull master
[21:54:35] <skunkworks> I am pretty sure it is master on linuxcnc.org
[21:54:55] <cradek> well he just said it was something from someone's github
[21:54:57] <atom1> git clone git://git.linuxcnc.org/git/linuxcnc.git mydirectory
[21:55:27] <atom1> i ran 2 separate tests
[21:55:28] <skunkworks> he tested roberts branch - found the issue and then tried it in master.. same issue
[21:55:29] <atom1> same results
[21:55:43] <cradek> oh ok
[21:56:26] <atom1> i noticed robert's ver still had the original hal_manualtoolchange code
[21:57:05] <atom1> ok i just updated his and it has the current ver now
[21:57:22] <atom1> the only difference is the addition of a physical button
[21:57:34] <atom1> along with the axis dialog
[21:59:46] <cradek> I remember seeing an addition to hal_manualtoolchange recently
[21:59:52] <cradek> I'm building master to try it
[22:00:02] <atom1> yeah dgarr added it i believe
[22:02:04] <atom1> another odd thing i just noticed that repeated itself is after homing, i select the x axis and press the '-' jog button and it seems to stick a while
[22:02:17] <atom1> it keeps jogging upon release for a second or so
[22:02:23] <atom1> only does it once
[22:03:22] <cradek> manualtoolchange seems to work to me
[22:03:36] <cradek> can you explain again what you do, then what you see, then how that is different from what you expect to see
[22:03:36] <atom1> NML_INTERP_LIST::append(nml_msg_ptr{size=12,type=EMC_TASK_PLAN_SYNCH}) : list_size=6, line_number=4
[22:03:36] <atom1> Issuing EMC_TOOL_PREPARE -- (+1104,+20, +0, +15,)
[22:03:36] <atom1> Issuing EMC_TASK_PLAN_PAUSE -- (+510,+12,+100005,)
[22:03:52] <atom1> was the last 3 lines of the terminal when the toolchange failed
[22:04:25] <atom1> in the MDI window, no tool changes
[22:04:45] <atom1> if i run a file, the regular tool change line will call the dialog box in axis normally
[22:05:08] <cradek> please describe what you see when "toolchange failed" and "no tool changes"
[22:05:50] <atom1> i enter T1 M6 G43 H1 in the dialog
[22:06:01] <atom1> the top bar pause button depresses
[22:06:04] <atom1> that's about it
[22:06:09] <atom1> no tool change occurs
[22:06:31] <cradek> what config are you running? having pause go in is very surprising
[22:06:46] <atom1> i can post it if you like
[22:07:00] <atom1> it's my sherline config from 2.5.3
[22:07:01] <cradek> instead, could you try testing with sim/axis
[22:07:10] <cradek> from master
[22:08:06] <atom1> how do you get it out of estop?
[22:08:26] <cradek> f1 f2
[22:09:03] <cradek> hal_manualtoolchange in master's sim/axis works as expected for me
[22:09:20] <atom1> yes
[22:09:24] <atom1> i agree with that
[22:09:44] <cradek> ok, so it's something special about your config
[22:09:51] <atom1> it does something completely different with my working config from 2.5.3
[22:10:31] <cradek> I do not know whether 2.5 configs are supposed to work unchanged in master
[22:10:43] <seb_kuzminsky> they should work unchanged
[22:10:45] <atom1> well, i just thought i'd mention it...
[22:11:14] <seb_kuzminsky> atom1: does this config work in 2.5.3 and fail in master?
[22:11:20] <atom1> yes
[22:11:30] <atom1> that's what was surprising to me
[22:11:32] <seb_kuzminsky> hmm...
[22:11:34] <cradek> ok, let's see it...
[22:11:42] <atom1> i'll post it somewhere
[22:11:55] <cradek> seb_kuzminsky: I am not nearly as sure as you are :-)
[22:12:08] <seb_kuzminsky> heh
[22:12:33] <seb_kuzminsky> well at least the config for *my* machine works equally well on 2.5 and master ;-)
[22:12:55] <seb_kuzminsky> hal_manualtoolchange changed recently, can you try it before the change?
[22:13:11] <cradek> h_m works for me in master's sim/axis
[22:13:22] <cradek> well for both of us
[22:14:35] <atom1> http://tom-itx.dyndns.org:81/~webpage/cnc/configs/sherline/
[22:14:44] <atom1> i just uploaded those from this run
[22:14:54] <seb_kuzminsky> dewey's change to h_m doesn't look wrong...
[22:15:08] <seb_kuzminsky> atom1: looking...
[22:15:18] <atom1> no that change works very nice in 2.5.3
[22:15:22] <skunkworks> atom1 made the comment that the circular blend branch (a little older than master) has the previous version of the manual tool change - the both acted the same (didn;t work as expected)
[22:15:31] <skunkworks> iirc
[22:15:39] <atom1> skunkworks, it has the new version now
[22:15:48] <atom1> he must have updated something recently
[22:15:52] <skunkworks> ah
[22:16:10] <atom1> i tried it with the old and new h_m
[22:16:14] <cradek> your unexpected pause message points to a problem with this very complicated pause button/toggle2nist/halui stuff
[22:16:30] <cradek> maybe you can narrow it down based on that clue
[22:17:21] <atom1> ok
[22:18:44] <atom1> i'll save it for another day
[22:19:08] <cradek> perhaps just unlink halui.program.pause
[22:19:13] <cradek> then see if you can change tools
[22:21:59] <atom1> ok, time to rest on it for now
[22:22:00] <atom1> thanks
[22:22:28] <cradek> sigh
[22:23:06] <Tom_itx> i got a long day tomorrow or i'd stay up and try it
[22:23:07] <Tom_itx> sry
[22:55:22] <KGB-linuxcnc> 03Sebastian Kuzminsky 05unified-build-candidate-3 63e86df 06linuxcnc 10debian/control.in deb: build-depend on autoconf >= 2.63 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=63e86df
[22:59:18] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder 914e647 06linuxcnc 10(7 files) stepconf -add a second parallel port signal selection page * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=914e647
[22:59:18] <KGB-linuxcnc> 03Chris Morley 05stepconf-GTK-builder b8675d9 06linuxcnc 10src/emc/usr_intf/stepconf/pages.py 10src/emc/usr_intf/stepconf/pport1.glade 10src/emc/usr_intf/stepconf/stepconf.py stepconf -add output presets for TB6560 board * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b8675d9
[23:54:32] <linuxcnc-build> build #3 of package-rtpreempt-wheezy-source is complete: Failure [4failed shell stage debian source package] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/package-rtpreempt-wheezy-source/builds/3 blamelist: Sebastian Kuzminsky <seb@highlab.com>