Back
[14:15:33] <norbert> Is there anyone, who knows about gremlin? It is not dealing correct with G53! Just test G17 G21 G54 G40 then F200 then G53 G0Z-2 then G38.2 Z-40 and M2 and see what gremlin does, it begins the move over the coordinate system and went another from under the coordinate system, so if your workpiece is not as high as the move it will result in an error exceeding the limits. I need help to solve that.
[14:22:36] <norbert> To see the matter with g53 and gremlin better, just move your G54 origing and see the result. OK who is the gremlin expert?
[14:27:16] <eric_unterhausen> what's a gremlin?
[14:27:38] <norbert> That is the preview from axis or other GUI.
[14:37:23] <cradek> I don't understand what you mean by "begins the move over the coordinate system and went another from under the coordinate system"
[14:37:24] <KGB-linuxcnc> 05vfd-b-3 59c4195 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=59c4195
[14:39:19] <norbert> cradek: Just do a move G53 Z-2 and after that a G38.2 Z-40 If you see it OK, the move Z axis down by 20 mm and set G54 Origin here and see the plot, now you have a move much longer than 40 mm.
[14:40:05] <KGB-linuxcnc> 05vfd-b-2 fbc7cc4 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fbc7cc4
[14:40:22] <cradek> I think you might be misunderstanding how G53 works but I am still not quite sure
[14:40:43] <cradek> do you expect the G53 to still have some affect after that line? if so your expectation is wrong
[14:40:51] <cradek> effect
[14:41:06] <cradek> g53 only applies to the line it is on
[14:42:21] <cradek> http://linuxcnc.org/docs/html/gcode/gcode.html#sec:G53-Move-in
[14:42:46] <norbert> I know this, but I must move the machine over the tool probe with G53 and the move of G38 should begin at the position the machine is and not from G54 , or am I wrong?
[14:43:34] <norbert> So why gremlin makes also a move from G54 origin?
[14:44:22] <norbert> If you are with G54 origin only 30 mm over negativ limit, you are not able to probe, because you get an error traveling over joint2 negativ limit.
[14:44:32] <cradek> do you mean there's a line in the preview you don't expect, or do you mean there is motion you don't expect?
[14:45:23] <norbert> Both, the line sjould not be there and the mentioned code should work, even if my G54 is only 2 mm over the negativ limit
[14:45:23] <cradek> your probing move can not have a programmed endpoint outside the limits of the machine. but this has nothing to do with previews...?
[14:46:15] <cradek> if your origin is 2mm above the limit and you program a move to Z-40 in G91 mode it should certainly be an error
[14:46:22] <cradek> G90
[14:46:28] <norbert> My probe point does not have a endpoint outside the limit! It starts at G53 Z -2 and goes -40 mm
[14:46:32] <norbert> Yes G90
[14:46:50] <norbert> My Z axis has 100 mm
[14:47:00] <cradek> are you in g90?
[14:47:05] <norbert> yes!
[14:47:22] <cradek> then your probe move is programmed to go to the active system's Z-40
[14:47:51] <norbert> Let me try with G91, one moment
[14:47:52] <cradek> in your example code above that active system is G54
[14:48:08] <norbert> yes and it must be this way
[14:50:00] <norbert> Ah that is the secret! I think it is OK , I will do some more tests!
[15:15:30] <owhite> hello people, I just installed linuxcnc on ubuntu 12.04 using the docs here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LinuxCNC_On_Ubuntu_Precise which went reasonably well thanks to you all. But it looks like it did not install the mesa hostmot2. At least it's reporting "hm2/5i20/SVST8_4.BIT not found" and I believe they are supposed to be present in /lib/firmware/hm2 - and I dont have that directory. Any suggestions?
[15:16:42] <cradek> install the firmware package you need
[15:16:52] <cradek> I think they are something like hostmot2-firmware-*
[15:17:08] <owhite> where can I get them?
[15:17:22] <owhite> at the mesa site?
[15:17:31] <cradek> use apt
[15:17:33] <seb_kuzminsky> owhite: it's on the linuxcnc.org debian archive
[15:17:55] <owhite> ok....
[15:18:09] <cradek> looks like these instructions have you end up with buildbot packages
[15:18:33] <cradek> er no, linuxcnc.org/precise/base should do it
[15:18:41] <cradek> you should be able to just install them with apt the usual way
[15:19:42] <seb_kuzminsky> cradek: they do, because there's no precise rtai debs on w.l.o yet
[15:20:15] <cradek> you mean precise 2.5 debs?
[15:20:29] <cradek> ah you mean precise 2.5-on-rtai debs
[15:20:51] <seb_kuzminsky> precise anything-on-rtai
[15:21:00] <cradek> ok right
[15:21:09] <cradek> but there are precise rtai-debs
[15:21:24] <seb_kuzminsky> linux-image-rtai.deb, yes
[15:21:36] <cradek> I understand now
[15:21:47] <cradek> the instructions are exactly right
[15:21:48] <seb_kuzminsky> and next time we make a release, which should be in 2099 or so, we'll get linuxcnc-rtai.deb for precise
[15:22:06] <owhite> thank you people, apt-get install hostmot2-firmware-5i20
[15:22:14] <seb_kuzminsky> yay!
[15:22:17] <cradek> don't promise a schedule!
[15:22:21] <seb_kuzminsky> haha
[15:22:51] <owhite> A schedule? Let me log this chat to the github repository announcement board.
[15:24:26] <seb_kuzminsky> now i've done it
[15:33:29] <seb_kuzminsky> zultron: thanks for that explanation
[15:34:45] <seb_kuzminsky> i had thought that the unified build built a single flavor-less package that would detect at runtime which flavor it was running on, and use the right part of itself for that environment, am i wrong about that?
[15:38:28] <zultron> Hi seb_kuzminsky
[15:39:44] <zultron> The UBC needs to be broken up among flavor packages for the big distros, since they won't carry the build deps for all flavors.
[15:40:28] <zultron> Also, for kernel threads it's useful to be able to update just the flavor pkg when the kernel is updated, and not the whole linuxcnc package.
[15:41:03] <zultron> However, if you're just trying to get the buildbot building packages, building everything in one pkg seems like an acceptable shortcut until these problems are worked out.
[15:43:03] <seb_kuzminsky> i see - that makes sense
[15:43:19] <zultron> Oh, 'big distros' point not finished: 3rd-party distros can then build flavor pkgs against the big distro -devel pkgs in the cases where the big distro doesn't have the build deps.
[15:54:16] <andypugh> I am looking at why MDI_COMMANDS and switching from manual to MDI mode in 2.5.3 with non-trivial kinematics cause an undesirable switch back to joint mode.
[15:55:04] <andypugh> I have previously proved that it still happens even if halui is the only ui, which gets all the GUIs off the hook.
[15:55:36] <andypugh> What I hadn't previously noticed was that it only actually happens if you have load halui. Axis without Halui seems to work as-expected.
[15:55:53] <seb_kuzminsky> zultron: i had thought that at compile-time (or at configure-time before), the available flavors would be enumerated, and a binary would be built that supported them all, but i understand now that i was wrong about that
[15:57:45] <andypugh> Is there anyone online who understands task well enough to take a look at emctask.cc, and the emcTaskSetMode function (line 201) and see if it makes sense? It _looks_ like setting mode to manual explicitly sets EMC_TRAJ_MODE_FREE, which deesn't seem like it makes sense to me
[15:58:28] <seb_kuzminsky> andypugh: i know task a little bit, but i'm elbows-deep in something else at the moment, sorry :-/
[15:59:28] <andypugh> Are you in the way in or the way out? It can wait several hours :-)
[16:10:23] <zultron> seb_kuzminsky, that's not wrong. At configure time, flavors are enumerated, and binaries are built.
[16:10:42] <zultron> The per-flavor binaries are mostly module binaries, plus the rtapi_app binary.
[16:11:12] <zultron> After that, the 'realtime' script sets things up to select the flavor at run time.
[16:12:42] <zultron> For the packages, sooner or later, the flavor-specific binaries will be packaged separately. The realtime script will detect any binaries that are installed and select the best flavor.
[16:12:52] <seb_kuzminsky> aha
[16:23:40] <seb_kuzminsky> ok, so it is the way i thought
[16:23:48] <seb_kuzminsky> i think that way makes sense
[16:24:33] <seb_kuzminsky> the only difficulty then for building for the big distros is that we sort of violate the notion of build-dependencies, right?
[16:25:27] <seb_kuzminsky> all of ubc3 and master and 2.5 do this: they don't build-depend on any particular kernels, but they detect what kernels are available and build binaries for them
[16:26:05] <zultron> The big distro packages will include only base binary pkg plus the posix and rt-preempt module pkgs. No violations.
[16:26:52] <seb_kuzminsky> no violations, agreed
[16:27:13] <seb_kuzminsky> just a bit of extra hassle to tune the source package to build-depend on the kernels we humans know are available on those platforms
[16:27:31] <zultron> If a 3rd-party wants to ship kthread packages, they should be built against the big distro pkgs, with those pkgs as deps. Also, they will be built against some particular kernel, and that kernel ABI needs to be a dep.
[16:27:43] <seb_kuzminsky> yep
[16:28:26] <zultron> Not sure I understand about the source pkg tuning?
[16:29:05] <seb_kuzminsky> debian wheezy has linux-image-rtpreempt, but ubuntu precise does not
[16:29:31] <seb_kuzminsky> the linuxcnc source package that builds on wheezy should build-depend on linux-image-rtpreempt-headers, so that the rtpreempt flavor gets built
[16:29:44] <zultron> Ah, so the source pkg needs to skip the rtpreempt pkging for precise.
[16:29:59] <seb_kuzminsky> but the linuxcnc source package that builds on precise must not build-depend on that kernel-headers package or it will fail to build
[16:30:03] <seb_kuzminsky> yes
[16:30:28] <seb_kuzminsky> i wish there was a way to express "build-recommends", but there isn't (at least in debian source packages, dont know about redhat and the others)
[16:30:51] <seb_kuzminsky> it's not just that the precise build needs to skip packaging for rtpreempt, it's worse than that
[16:31:22] <seb_kuzminsky> source packages are built into binary packages in chroots, like the pbuilder that you set up for the kernels, and that the buildbot uses
[16:31:34] <zultron> I see what you mean. Yes, the packaging will need some config variable that enables some pkgs and disables others.
[16:31:59] <seb_kuzminsky> the chroots start out with the minimal set of packages installed, and the source package that's being built specifies what other packages it needs to build itself
[16:32:16] <zultron> Right, same with RH.
[16:32:17] <seb_kuzminsky> those build-dependencies are installed into the chroot before the source package is built
[16:32:21] <seb_kuzminsky> righ
[16:32:23] <seb_kuzminsky> t
[16:32:28] <zultron> The build deps are only installed if the packaging calls for them.
[16:32:33] <seb_kuzminsky> right
[16:32:49] <seb_kuzminsky> so either the source package build-depends on the rtpreempt headers (for example), or they dont
[16:33:03] <seb_kuzminsky> the build automation satisfies the build-dependency or it fails the build
[16:33:15] <zultron> I don't really know how .deb pkging works. For my RH RPMs, I have switches to turn off flavors.
[16:33:31] <zultron> Those also turn off the build deps for those flavors.
[16:33:50] <seb_kuzminsky> does RH use source packages that build into binary packages? it must
[16:34:36] <zultron> Yes, but for the big distros, I'd have the 'exotic' flavors turned off.
[16:34:37] <seb_kuzminsky> and the source package runs some code to determine what its build dependencies are? that's cool. i think debian has a similar mechanism, called gencontrol, that we don't currently use
[16:35:13] <zultron> Yes, that's what the .deb packaging needs: control file built on the fly.
[16:35:33] <seb_kuzminsky> we sort of do that, but in a wonky nonstandard way with debian/configure
[16:36:09] <seb_kuzminsky> i'll look into it and see if debian/gencontrol can do what we want, if so i think the deb packaging issue will be solvable
[16:36:09] <zultron> It's all fuzzy, but I looked at gencontrol some time ago, and it may not be flexible enough to do what we need.
[16:36:17] <seb_kuzminsky> uh-oh
[16:36:35] <zultron> That's not really a problem, though, since we can do what we need with a shell script/makefile recipe.
[16:37:15] <zultron> There's nothing special about gencontrol. It simply writes the control file. A script can do the same thing.
[16:37:53] <seb_kuzminsky> you're right, gencontrol wont work
[16:38:47] <zultron> That wacky kpkg stuff rewrites its own control file, sometimes even when you don't want it to. :P
[16:38:49] <seb_kuzminsky> i don't think a shell script or makefile (in scripts/ or src/ or whatever) will fix the problem i'm thinking about
[16:39:30] <zultron> Well, I'm sure there're things I don't understand.
[16:39:48] <seb_kuzminsky> by the time we're running our build system, the build dependencies specified by the source package have already been enumerated and installed
[16:40:04] <zultron> Yes.
[16:40:11] <seb_kuzminsky> grumble
[16:40:35] <zultron> Wait, is that the problem?
[16:40:50] <zultron> Why?
[16:41:05] <zultron> Why is it a problem?
[16:41:44] <seb_kuzminsky> say you're trying to build linuxcnc for a debian distro, inside a minimal chroot
[16:42:00] <seb_kuzminsky> you copy the source package into the chroot, chroot into it, and unpack the source package
[16:42:19] <seb_kuzminsky> now you want to know what packages this source-package needs installed, in order to build
[16:42:38] <seb_kuzminsky> these build dependencies are listed in the source package metadata, in debian/control
[16:42:58] <zultron> Right.
[16:43:02] <seb_kuzminsky> *if* linux-headers-rtpreempt is listed in that file, then the rtpreempt headers will be installed, otherwise they wont
[16:43:21] <zultron> Yes.
[16:43:32] <seb_kuzminsky> after all the build-dependencies are installed, the package builder runs the source package's own build system, which looks to see what realtime flavors are available
[16:44:01] <seb_kuzminsky> if the source package called for rtpreempt headers to be installed, the build system will enable the rtpreempt flavor, otherwise it wont
[16:44:07] <zultron> Right.
[16:44:24] <zultron> So the source pkg needs to be pre-configured with which flavors it will build.
[16:44:31] <seb_kuzminsky> then all the enabled flavors get built & packaged and everything is copacetic
[16:45:01] <zultron> Yes, that's right.
[16:45:25] <zultron> Where's the problem? (My blood sugar's low)
[16:45:26] <seb_kuzminsky> exactly, that's what i meant when i said we need to tune the source packages to the distro we're building for
[16:45:37] <zultron> Ah, yes. That's right.
[16:45:58] <zultron> Each distro will have a slightly different pkg configuration.
[16:46:24] <zultron> For RH, that's not a problem, anyway. Why is it for Deb?
[16:47:13] <seb_kuzminsky> we currently build our deb source packages from our git repo, i guess we'll add a step to that to enumerate the available falvors and make the source package build-depend on their kernel headers
[16:47:30] <seb_kuzminsky> it's not a problem, just different from how we currently do it
[16:48:09] <zultron> In your buildbot, you'd point at a git repo where all flavors are enabled.
[16:48:39] <seb_kuzminsky> i dont think that's the way to do it
[16:48:42] <zultron> When it comes time to pkg for an upstream distro, the flavor list would need to be tweaked.
[16:49:32] <seb_kuzminsky> i'd prefer a script that examines the available packages (on whatever distro it finds itself running on) and builds a source package that build-depends on all the kernel header flavors it finds
[16:49:36] <seb_kuzminsky> maybe that's what you meant
[16:50:22] <seb_kuzminsky> that way we dont need a different branch in the git repo for each distro we target, we can have a script that runs equally well on all supported distros and does the tuning right for all of them
[16:50:22] <zultron> Yes, the same config going in should be the same config in the resulting source pkg.
[16:51:04] <seb_kuzminsky> alright, cool, thanks for talking me through this
[16:51:14] <zultron> So here's where I'm unclear about the upstream packaging flow.
[16:52:04] <zultron> Where does Debian get its sources from, and must they be identical to the project's sources?
[16:52:15] <seb_kuzminsky> i was on the debian developer track many years ago, never finished the gauntlet, but i do know the answer to that
[16:52:39] <seb_kuzminsky> debian doesn't care about git or cvs or anything like that, they care about dsc (debian source packages)
[16:52:53] <seb_kuzminsky> how you make your dsc is up to you, and many devs use git or something similar
[16:53:07] <seb_kuzminsky> but at the end, you locally build a source package (dsc) and upload it to their build automation
[16:53:15] <zultron> RH pkgs take a pristine tarball release from the project, and then has a 'specfile' that contains the rules for building it, equiv. to the /debian directory.
[16:53:34] <zultron> There are opportunities to add patches or tweak variables in the specfile.
[16:53:34] <seb_kuzminsky> makes sense
[16:53:44] <seb_kuzminsky> that sounds just like debian
[16:54:37] <zultron> I assumed that the Debian packager grabs something from the project, as with RH, and then has a way to make further changes.
[16:54:38] <seb_kuzminsky> debian makes a slight distinction between "native" debian packages, where debian/ is part of the upstream project (like linuxcnc), and non-native packages where the debian/ directory is supplied as a patch to the upstream original tarball (along with debian-specific patches)
[16:54:54] <zultron> Ah ha.
[16:55:30] <seb_kuzminsky> debian never fetches tarballs as part of the build, all the sources are packaged in the source package
[16:55:41] <zultron> Could LinuxCNC be called 'non-native', but the patch only tweaks a couple of lines inside the existing /debian directory?
[16:56:34] <seb_kuzminsky> we could do it that way, but we'd be tuning the patch file anyway, right? i think it'd be simpler to just tune the control file directly, like we already do now
[16:56:36] <zultron> No, RH doesn't fetch the tarballs as part of the build, either. The packager must upload them.
[16:56:44] <seb_kuzminsky> ah ok, good!
[16:57:14] <zultron> But in RH, the packaging materials (specfile, patches, etc.) are assumed to be separate from the tarball.
[16:57:50] <seb_kuzminsky> here's one of the debian source repos on the buildbot:
http://buildbot.linuxcnc.org/dists/precise/master-rt/source/
[16:57:53] <zultron> In Deb, they can be integral for 'native' pkgs, or separate for 'non-native', if I understand your explanation.
[16:58:07] <seb_kuzminsky> yes that's right
[16:58:31] <seb_kuzminsky> you can see we have native packages, because we dont have diffs along with our .dsc and .tgz files
[16:59:50] <zultron> Right. Would it be easy enough for the Debian or Ubuntu packager to simply include the necessary diff for the distro?
[17:00:51] <seb_kuzminsky> i think that could work
[17:01:38] <seb_kuzminsky> i'm not real familiar with non-native packages, and i dont know if we'd need to move the whole debian/ tree out of the main tarball and into the diff, or what
[17:01:45] <zultron> My hope was that it would be a small patch that wouldn't need to change when LinuxCNC is updated, and LinuxCNC wouldn't have to do anything weird (like separate branches per distro) at release time.
[17:02:10] <seb_kuzminsky> separate branches per distros would be a nightmare to maintain, agreed
[17:02:21] <zultron> Me neither. We'll figure it out. :)
[17:03:02] <seb_kuzminsky> we currently rewrite the source package control file when we build the source package, so adding this extra list of flavors at that time seems easy
[17:03:37] <zultron> Great!
[17:03:55] <seb_kuzminsky> i dont know if you're running your buildbot or if it's michael or someone else, but if you look at the 'package-mumble-mumble-source' build factories, you'll see how we currently do it
[17:04:58] <seb_kuzminsky> it's the step that runs debian/configure that updates the control file with information about this particular platform:
[17:05:01] <seb_kuzminsky> http://buildbot.linuxcnc.org/buildbot/builders/package-rt-precise-source/builds/91/steps/configuring%20debian/logs/stdio
[17:05:55] <zultron> Ok.
[17:05:57] <seb_kuzminsky> i think it'd work to teach debian/configure to look for linux-headers-rtpreempt (on the machine building the source package), and add a build-dependency on it if present
[17:06:32] <seb_kuzminsky> it wouldnt need the flavor-headers installed, it could use 'apt-cache search' to see if it's available at all
[17:06:42] <zultron> About debian/configure, that's a non-standard thing in re. Debian packaging, right?
[17:06:50] <seb_kuzminsky> yeah....
[17:07:39] <seb_kuzminsky> i bet lots of debian packages have some mechanism like that to tune the source package a source-package creation-time, but i think there's no standard way to do it unfortunately
[17:07:40] <zultron> Will it be needed for big distro packaging, or will a pre-configured source pkg not need that?
[17:08:11] <seb_kuzminsky> debian/configure is only used to create the source package, it would never be used by the big distro package builders
[17:08:23] <seb_kuzminsky> (they'd just receive an already tuned dsc from us)
[17:08:26] <zultron> Ok. (whew!)
[17:08:29] <seb_kuzminsky> heh
[17:08:58] <seb_kuzminsky> we just need to make sure we build our dsc with the same set of flavor build-dependencies available as will be available to the big distro package builder automation
[17:09:25] <seb_kuzminsky> which should be easy, we just use the standard deb archives, none of our project-specific ones
[17:09:45] <zultron> My RH packages do something like you said: it runs package queries to see what's installed, and then flips those switches as needed.
[17:10:06] <seb_kuzminsky> i'll try to add this to ubc3
[17:10:29] <zultron> Well, actually it uses them to generate version deps for kernel and Xenomai, it doesn't turn flavors on/off.
[17:11:39] <zultron> The package says "Build-requires: kernel-xenomai", and then generates e.g. "Requires: kernel-xenomai-3.5.7-foo" for the binary RPM.
[17:12:06] <seb_kuzminsky> that sounds perfect
[17:12:37] <zultron> That way, when the kernel version gets bumped, the package can be rebuilt without changes, but the resulting binary packages have the correct kernel version deps.
[17:12:44] <seb_kuzminsky> i just need to teach debian/control to add the right Build-requires line to the source package
[17:12:52] <seb_kuzminsky> (although it's spelled Build-Depends in debian)
[17:13:04] <zultron> Sure.
[17:13:45] <zultron> (That's why it's so hard to switch distros: all those details to drive one mad!)
[17:13:50] <seb_kuzminsky> heh
[17:14:07] <seb_kuzminsky> you need one packaging geek for each distro you want to support
[17:14:58] <zultron> Yes. My sole purpose for the kernel auto-builder thing was to make it easy to give to someone else. >:D
[17:15:18] <zultron> Alright, I gotta go eat.
[17:15:23] <seb_kuzminsky> alright
[17:15:36] <seb_kuzminsky> thanks for chatting, it really solidified a bunch of thoughts i had
[17:15:48] <zultron> Thanks for looking at this stuff. As I said, it's not easy, and very not easy for me.
[17:39:27] <norbert> cmorley: could you check, why gscreen does not set dro_is_metric right for gmoccapy? I could not find a reason.
[17:45:42] <cmorley> yes - on my todo list
[17:47:20] <norbert> Thanks, I got finaly the remap think working and I am including at tat this time.
[17:47:54] <norbert> As it is now here 00;30 I go to bed now. Good night
[17:54:21] <norbert> cmorley: I just found out, that also the tooledit widget is affected.
[17:55:05] <norbert> Sorry not tooledit offsetpage! I must go to bed ;-)
[18:16:45] <skunkworks> master seems to require libtk-img but ./configure doesn't notice that it isn't there..
[18:30:57] <seb_kuzminsky> skunkworks: by ./configure you mean src/configure? and by "require libtk-img" you mean there's some program that won't run unless libtk-img is installed?
[18:37:58] <mozmck> I ran into that too - I tried gmoccapy and axis and neither would run without that. Linux MINT 16 (Ubuntu 13.10 based)
[18:56:21] <skunkworks> if you build master without the libtk-img depencancy - linuxcnc will build but not start
[18:56:38] <skunkworks> you get an error pointing to IMG
[18:57:24] <mozmck> Seems like there was another one too that I ran across.
[20:12:06] <seb_kuzminsky> linuxcnc-build: force build checkin
[20:12:07] <linuxcnc-build> build #1631 forced
[20:12:07] <linuxcnc-build> I'll give a shout when the build finishes
[20:12:17] <linuxcnc-build> build #0 of wheezy-amd64-rtpreempt-rip is complete: Failure [4failed git] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/wheezy-amd64-rtpreempt-rip/builds/0
[20:15:17] <mozmck> That was the other one - I needed python-gtkglext1
[20:15:24] <mozmck> to run linuxcnc master
[20:16:05] <mozmck> and python-xlib for the gladevcp_tab sample config
[20:17:27] <seb_kuzminsky> cool, will you add those to the Depends: line for the main package, in debian/control.in?
[20:21:18] <mozmck> Looks like libtk-img is there already, did it just get added?
[20:21:41] <seb_kuzminsky> git blame will tell you when a line was changed
[20:22:05] <seb_kuzminsky> if you're using run-in-place, the dependencies are not automatically handled
[20:22:58] <linuxcnc-build> build #1 of wheezy-amd64-rtpreempt-rip is complete: Failure [4failed clear-dmesg configure-debian-control] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/wheezy-amd64-rtpreempt-rip/builds/1
[20:23:06] <mozmck> I'm actually just running simulator, but I ran dpkg-checkbuilddeps to get the dependencies.
[20:23:41] <cradek> that confusion has bitten me before - building and running dependencies are different
[20:24:00] <mozmck> oh, I see.
[20:25:42] <mozmck> Is there a way to query the run dependencies?
[20:25:54] <seb_kuzminsky> mozmck: not that i know of :-(
[20:26:22] <mozmck> look at the control.in? ;)
[20:26:31] <cradek> yeah I guess at least they're in a list
[20:26:37] <cradek> it's not ideal
[20:26:42] <seb_kuzminsky> right! the command is 'grep'
[20:29:03] <seb_kuzminsky> linuxcnc-build: force build --branch=unified-build-candidate-3
[20:29:03] <linuxcnc-build> you must provide a Builder, try 'force build [--branch=BRANCH] [--revision=REVISION] [--props=PROP1=VAL1,PROP2=VAL2...] <WHICH> <REASON>'
[20:29:07] <seb_kuzminsky> linuxcnc-build: force build --branch=unified-build-candidate-3 checkin
[20:29:14] <linuxcnc-build> The build has been queued, I'll give a shout when it starts
[20:29:43] <cradek> that help is not helpful
[20:29:57] <cradek> apparently you have to provide <WHICH> but not <REASON> even though they look the same
[21:15:50] <linuxcnc-build> build #1631 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1631
[21:15:50] <linuxcnc-build> build #1632 forced
[21:15:51] <linuxcnc-build> I'll give a shout when the build finishes
[21:16:27] <linuxcnc-build> build #4 of wheezy-amd64-rtpreempt-rip is complete: Failure [4failed apt-get-update install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/wheezy-amd64-rtpreempt-rip/builds/4
[21:18:20] <linuxcnc-build> build #5 of wheezy-amd64-rtpreempt-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/wheezy-amd64-rtpreempt-rip/builds/5
[21:29:29] <linuxcnc-build> build #1632 of hardy-amd64-sim is complete: Failure [4failed configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1632
[21:30:27] <linuxcnc-build> build #1630 of hardy-i386-sim is complete: Failure [4failed configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1630
[21:30:50] <linuxcnc-build> build #1627 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/1627
[22:12:11] <linuxcnc-build> build #1632 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1632
[22:12:44] <linuxcnc-build> build #6 of wheezy-amd64-rtpreempt-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/wheezy-amd64-rtpreempt-rip/builds/6
[23:04:15] <linuxcnc-build> build #7 of wheezy-amd64-rtpreempt-rip is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/wheezy-amd64-rtpreempt-rip/builds/7
[23:42:47] <seb_kuzminsky> linuxcnc-build: force build --branch=unified-build-candidate-3 checkin
[23:42:47] <linuxcnc-build> build #1633 forced
[23:42:47] <linuxcnc-build> I'll give a shout when the build finishes
[23:54:14] <linuxcnc-build> build #1633 of hardy-amd64-sim is complete: Failure [4failed configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1633
[23:55:15] <linuxcnc-build> build #1628 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/1628
[23:55:19] <linuxcnc-build> build #1631 of hardy-i386-sim is complete: Failure [4failed configuring configure] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1631