Back
[00:00:07] <BigJohnT> I just did an update and get "./configure: line 3: syntax error near unexpected token `<<<" during the make :?
[00:00:21] <seb_kuzminsky> prolly a merge conflict
[00:00:45] <BigJohnT> ok, I'll do a clean download
[00:00:47] <seb_kuzminsky> you had local changes to your configure script?
[00:01:00] <BigJohnT> Oh yes I did!
[00:01:07] <seb_kuzminsky> ;-)
[00:01:17] <BigJohnT> let me run autoconf again
[00:01:28] <BigJohnT> your right on top of things seb_kuzminsky
[00:01:53] <seb_kuzminsky> speaking of which, time to go get the kids from preschool!
[00:01:54] <seb_kuzminsky> bbl!
[00:02:07] <BigJohnT> see you later
[00:10:26] <alex_joni> good night all
[00:10:46] <BigJohnT> oh boy now I can move everything around
[00:10:52] <BigJohnT> goodnight alex_joni
[00:52:27] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/axis.lyx: minor edit
[02:34:53] <jmkasunich> hello guys
[02:34:59] <jmkasunich> I have a cvs weirdness here
[02:35:14] <jmkasunich> all the farm updates are failing
[02:35:44] <jmkasunich> cvs update" move away `configs/plasma-thc/emc.nml'; it is in the way
[02:36:00] <jmkasunich> C configs/plasma-thc/emc.nml
[02:36:54] <jmkasunich> same message about plasma-thc-sim/emc.nml
[02:43:37] <CIA-2> EMC: 03compile-farm 07BDI-4.51 (2.6.16.20-rtai) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot6_log.txt
[02:44:32] <jmkasunich> ok, who broke it?
[02:50:41] <SWPadnos> is that from the change that Alex made to break it on purpose?
[02:50:46] <jmkasunich> no
[02:50:57] <jmkasunich> I had a cvs issue, I fixed that (removed the offending files)
[02:51:03] <SWPadnos> ah
[02:51:14] <jmkasunich> the build failure above is real
[02:51:19] <jmkasunich> it happened only on BDI though
[02:51:29] <jmkasunich> both hardy and both dapper succeeded
[02:51:37] <jmkasunich> (both = RT and non-RT)
[02:51:43] <jmkasunich> starting breezy builds now
[02:51:44] <SWPadnos> huh
[02:51:55] <SWPadnos> no uint32_t definition?
[02:52:12] <jmkasunich> yeah
[02:53:05] <jmkasunich> the farm has been down for less than 48 hrs, quite a coincidence the someone committed a build-breaker in that period
[02:53:32] <SWPadnos> heh
[02:53:37] <SWPadnos> synchronicity
[02:54:34] <jmkasunich> jepler did it!
[02:54:42] <SWPadnos> of course, it's halmodule.cc
[02:55:25] <SWPadnos> maybe a change to make ints work where unsigned should be (or the opposite)
[02:55:37] <jmkasunich> breezy builds succeeded
[02:55:59] <jmkasunich> he was trying to fix some 64 bit thing
[02:56:10] <jepler> ugh, I'll look at it
[02:56:22] <SWPadnos> wasn't there a long long thing and a signed/unsigned thing?
[02:56:37] <SWPadnos> (no comments on the long long thing)
[02:59:11] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/hal/halmodule.cc: use the same names that are behind hal typedefs to fix a bdi build error
[02:59:54] <SWPadnos> yay!
[03:00:09] <jepler> Python likes to use 'long' and 'unsigned long' for converting Python integral types to C. On 64-bit systems, these have greater ranges than the hal integral types. The change that caused a problem is one that makes halmodule correctly error when presented with values in the range of platform (unsigned) longs that don't fit in hal integral types.
[03:01:02] <jepler> (have a look at tests/halmodule.0 for a test of this)
[03:02:14] <SWPadnos> I thought I remembered some code that looked for num>(something_big) || num<0
[03:03:18] <CIA-2> EMC: 03compile-farm 07BDI-4.51 (2.6.16.20-rtai) * 10emc2head/: build PASSED
[03:03:23] <jmkasunich> yay!
[03:03:27] <jepler> that may have been one of the variations I tried along the way -- that gives an undesirable warning on 32-bit systems, because 'num>(something big)' is a comparison that is always false
[03:03:36] <SWPadnos> yep
[03:03:51] <SWPadnos> strangely, I was just thinking about that in relation to cruise ships
[03:04:17] <jepler> You are going to have to explain yourself a bit more
[03:04:58] <SWPadnos> I thought we had cabin M254 on a cruise 10 years ago, and I was thinking remembered it because that's the largest value you can compare in a byte variable while still having a valid "greater than" result
[03:05:06] <SWPadnos> I was wrong though, ir was M246 anyway
[03:05:09] <SWPadnos> it
[03:11:34] <jmkasunich> heh, the fail message just arrived
[03:11:46] <jmkasunich> jepler is really good - he fixed it before it failed
[03:12:00] <SWPadnos> non-causal bugfixes
[03:12:05] <SWPadnos> someone should patent that
[05:44:34] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/src/libnml/cms/cms_srv.cc: only dereference non-NULL pointers (another coverity fix)
[06:45:17] <CIA-2> EMC: 03seb 07v2_2_branch * 10emc2/src/libnml/cms/cms_srv.cc: dont dereference NULL pointers, even in the 2.2 branch
[06:54:49] <CIA-2> EMC: 03seb 07TRUNK * 10infrastructure/farm-scripts/emc2_mail.py:
[06:54:49] <CIA-2> EMC: Added a buildbot change source that parses CIA emails and triggers the
[06:54:49] <CIA-2> EMC: proper builds. (JMK feel free to move this if i committed it in the
[06:54:53] <CIA-2> EMC: wrong place)
[06:55:44] <seb_kuzminsky> ok that's enough bouncing the buildbot for tonight
[06:56:07] <seb_kuzminsky> i've switched it over to triggering on email instead of polling the repo
[06:56:43] <seb_kuzminsky> also, i think it now shows the changed files and the author of the commit properly, instead of always saying "seb changed /"...
[06:57:21] <seb_kuzminsky> good thing there was still a coverity bug for me to make test commits with :-)
[07:13:27] <seb_kuzminsky> alex_joni: something's wrong with the buildbot grid display in 0.7.9, it's super slow
[08:14:37] <alex_joni> seb_kuzminsky: ah, I see
[12:00:19] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/Getting_EMC.lyx: minor edit
[13:24:51] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/images/ (26 files): update images
[13:26:48] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/ (pyvcp.lyx pyvcp_AXIS.png): update images
[13:30:15] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/images/pyvcp_axis_lathe.png: add image
[13:36:20] <alex_joni> BigJohnT: now it's official :D
[13:36:28] <alex_joni> Build Source Stamp: HEAD
[13:36:28] <alex_joni> Blamelist: bigjohnt
[13:36:28] <alex_joni> BUILD FAILED: failed compile
[13:47:01] <BigJohnT> alex_joni: did it build before I commited the image?
[13:50:37] <alex_joni> probably so ;)
[13:51:02] <alex_joni> it now builds the debs too, so if docs fail you'll see a message on the commit list
[13:51:11] <jepler> if the pdf docs fail
[13:51:14] <BigJohnT> I saw that
[13:51:17] <jepler> the deb doesn't contain html docs
[13:51:39] <BigJohnT> does it try again after the next commit or something like that?
[13:53:44] <alex_joni> BigJohnT: it recompiles on each commit
[13:54:00] <alex_joni> well if there are a couple bundled then it doesn't.. it waits for the last one
[13:54:08] <alex_joni> (but it depends how much timeout there is)
[13:54:10] <alex_joni> hi jepler
[13:55:03] <BigJohnT> then it should have compiled after I added the last image...
[13:55:33] <alex_joni> http://emc2-buildbot.colorado.edu/buildbot/one_box_per_builder
[13:55:36] <alex_joni> yup, it did..
[13:56:38] <alex_joni> jepler: I was looking over this list:
http://emc2-buildbot.colorado.edu/buildbot/builders/hardy-x86-trunk-realtime-deb/builds/622/steps/compile/logs/warnings
[13:58:42] <BigJohnT> heh, now I don't have to wait for jepler to say "did you forget an image" it is automagic now :)
[13:59:08] <jepler> alex_joni: yeah those warnings have been mentioned before
[13:59:55] <jepler> alex_joni: some are "should be fixed, but who cares" and others are "dpkg-shlibdeps is dumb, but who cares". I didn't spot any "real" problems, where I would define "real" as dpkg-shlibdeps including a library package as a dependency when it shouldn't be.
[14:00:02] <jepler> * jepler <-- not losing sleep
[14:00:10] <alex_joni> I know.. was wondering if we can make them go away
[14:00:17] <jepler> >/dev/null 2>&1
[14:00:20] <alex_joni> the mandb warnings can go away with -q as a flag
[14:00:57] <alex_joni> some suggest to pass -Wl --as-needed to get rid of the linker problems
[14:01:15] <jepler> as far as I read in the scrollback, mandb -q will eventually hide real errors (.so of a manpage that doesn't exist)
[14:01:27] <alex_joni> only warnings
[14:01:46] <jepler> which is worse -- to have 20 warnings one of which might be real, or to hide all warnings just for the sake of seeing 0 warnings? I don't know.
[14:02:02] <alex_joni> I suspect >/dev/null 2>&1 would do the same ;)
[14:02:10] <alex_joni> or worse ..
[14:02:11] <jepler> yes that's why it was a sarcastic suggestion
[14:02:18] <alex_joni> :P
[14:02:56] <alex_joni> maybe they'll fix dpkg-shlibdeps eventually
[14:03:02] <alex_joni> * alex_joni runs home
[14:03:22] <jepler> if it's supported on even our older platform *cough*BDI*cough*, -Wl,--as-needed looks like it's not a bad idea
[14:03:43] <jepler> but you'll still be left with "dpkg-shlibdeps: you used shared libraries in a way I don't understand, so here are 20 warnings plus 100 more I won't print"
[14:39:52] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/tool_compensation.lyx: minor edit
[14:55:23] <seb_kuzminsky> alex_joni, BigJohnT: i had turned off the buildbot tree-idle-timer when i was using the polling cvs script (because tree-idle-time doesnt really make sense in that setup)
[14:55:34] <seb_kuzminsky> i re-enabled it just now, it's 2 minutes
[14:55:56] <seb_kuzminsky> so when it's idle and it notices a commit, it waits for 2 minutes with no commit before it starts the build
[14:56:41] <BigJohnT> Ok, cool
[14:57:21] <BigJohnT> now if I screw up and forget I have 1:45 to fix it :) it only took jepler about 30 seconds to notice :)
[14:57:28] <seb_kuzminsky> heh
[14:57:38] <seb_kuzminsky> we could make it longer ...
[14:59:03] <BigJohnT> seb_kuzminsky: I'm finally getting 2.3 installed on the computer with the 5i20 in it :)
[14:59:38] <seb_kuzminsky> cool!
[15:08:52] <seb_kuzminsky> bbl
[15:18:20] <Guest176> Guest176 is now known as skunkworks_
[15:40:43] <seb_kuzminsky> i wonder why the buildbot fail message didnt show up on planet-emc
[15:45:45] <SWPadnos> buildmaster, why are you so quiet?
[15:46:05] <SWPadnos> buildmaster: do you require a colon instead of a comma?
[15:46:06] <seb_kuzminsky> buildmaster: hello
[15:46:06] <buildmaster> yes?
[15:46:12] <seb_kuzminsky> buildmaster: commands
[15:46:12] <buildmaster> buildbot commands: commands, dance, destroy, excited, force, hello, help, join, last, leave, list, notify, source, status, stop, version, watch
[15:46:32] <SWPadnos> I guess we'll never know
[15:46:50] <SWPadnos> somebody should make an infocom-like bot for IRC applications
[15:47:06] <SWPadnos> buildmaster, wrap towel around grue
[15:58:53] <skunkworks_> buildmaster: dance
[15:58:55] <buildmaster> 0-<
[15:58:57] <buildmaster> 0-/
[15:58:57] <buildmaster> 0-\
[15:59:06] <seb_kuzminsky> buildmaster: notify on failed
[15:59:06] <buildmaster> The following events are being notified: ['failed']
[15:59:07] <skunkworks_> uh - yah
[15:59:23] <SWPadnos> buildmaster, help notify
[15:59:23] <buildmaster> Usage: notify on|off|list [<EVENT>] ... - Notify me about build events. event should be one or more of: 'started', 'finished', 'failed', 'success', 'exception', 'successToFailed', 'failedToSuccess'
[15:59:42] <seb_kuzminsky> buildmaster: you lie, you dont understand successToFailed or failedToSuccess
[15:59:50] <cradek> neat
[15:59:52] <SWPadnos> buildmaster, notify on failedToSuccess
[15:59:52] <buildmaster> try 'notify on|off <EVENT>'
[16:00:00] <SWPadnos> silly buildmaster
[16:00:24] <seb_kuzminsky> buildmaster: notify list
[16:00:24] <buildmaster> The following events are being notified: ['failed']
[16:00:38] <seb_kuzminsky> buildmaster: What happen ?
[16:00:39] <buildmaster> Somebody set up us the bomb.
[16:00:52] <SWPadnos> ok, coffee prep time ;_)
[16:01:01] <seb_kuzminsky> buildmaster: make me a coffee
[16:03:14] <alex_joni> guess you'll get no coffee from buildmaster
[16:03:48] <seb_kuzminsky> and now for something completely different: did we talk about github already?
[16:03:49] <seb_kuzminsky> http://github.com/djmitche/buildbot/tree/brian
[16:03:54] <seb_kuzminsky> it's what the buildbot folks use
[16:04:27] <alex_joni> what's github?
[16:04:35] <seb_kuzminsky> it's like sourceforge or launchpad
[16:04:46] <seb_kuzminsky> social coding/project hosting site
[16:05:04] <alex_joni> I see
[16:05:32] <alex_joni> the link "pricing and signup" doesn't sound promising though
[16:07:53] <cradek> I'm enamored with launchpad's online i18n stuff
[16:08:18] <alex_joni> and it's gonna be OSS soon (most parts of it anyways ;)
[16:30:07] <SWPLinux> so, I compiled EMC2 (sim only so far) on Jaunty Alpha3 (probably A4 now, since I've been doing updates)
[16:30:14] <SWPLinux> and got an error
[16:30:20] <SWPLinux> http://pastebin.ca/1336177
[16:30:37] <SWPLinux> if I comment out the offending lines in axis, it runs fine
[16:31:34] <SWPLinux> (the three ...delete("end") lines)
[16:32:16] <SWPLinux> and just for the record, I can't build docs either, but I haven't really looked into that
[16:32:51] <BigJohnT> did you do a make clean?
[16:33:33] <SWPadnos> I did a clean checkout ;)
[16:33:48] <SWPadnos> but I can try make clean also, what the heck
[16:34:02] <BigJohnT> I've noticed when I do a make clean it bails then a make works
[16:34:18] <BigJohnT> usually after I shuffle something around
[16:36:12] <SWPadnos> hmmm
[16:36:27] <SWPadnos> I'll have to try this again. this time, and the time before, I use "make -j6"
[16:36:43] <SWPadnos> something errors, so all make processes eventually stop
[16:37:30] <SWPadnos> I see some errors in building docs at that point
[16:37:35] <SWPadnos> then I try "make" after that, and a whole lot of stuff gets done - more compiling and linking of various things
[16:38:01] <SWPadnos> then more doc building, and an eventual error "Error 1" building the Master_User PDF
[16:42:09] <SWPadnos> non-parallel make didn't work
[16:42:55] <jepler> you're the third person to encounter an unknown problem with post-Hardy LyX and our documentation. seb_kuzminsky and tissf are the other two I know of.
[16:43:22] <SWPadnos> ok
[16:43:23] <jepler> as for the python traceback, I can't tell what the problem is. widgets.menu_view should never be None.
[16:43:35] <SWPadnos> huh. ok
[16:43:35] <jepler> it should be a Python wrapper of a tk widget
[16:43:43] <SWPadnos> it's python2.5, if that helps at all
[16:43:56] <SWPadnos> I did have to install python-tk (or similar)
[16:44:08] <jepler> python 2.5.2 on hardy, so that's not much difference
[16:44:11] <jepler> yes of course you did
[16:44:18] <SWPadnos> which wasn't in the build-deps. didn't notice if it was in the emc2 deps
[16:44:23] <jepler> yes of course it is
[16:44:36] <SWPadnos> heh
[16:44:50] <SWPadnos> maybe I should install all those too then :)
[16:44:58] <jepler> well, python-imaging-tk is, and I expect it to pull in python-tk
[16:45:13] <jepler> oh there it is a bit further onL python@PYTHON_VERSION@-tk
[16:45:31] <SWPadnos> ah. I probably missed the -tk part of that
[16:46:12] <SWPadnos> oh, there are several I missed. thanks for the pointer
[16:52:03] <jepler> ah, they brokef it:
http://svn.python.org/view/python/branches/release25-maint/Lib/lib-tk/Tkinter.py?rev=65624&r1=65400&r2=65624
[16:52:19] <jepler> http://svn.python.org/view?rev=65624&view=rev
[16:53:43] <jepler> it is trying to find the Python object that is the menu entry's command -- but there isn't one (the command is a Tcl string)
[16:56:20] <SWPLinux> crap. what was the incantation to get gobs of debug infor out of make?
[16:56:37] <jepler> "--debug=b,m" is useful when Make: failed to rebuild Makefile
[16:56:44] <SWPLinux> hmm
[16:57:29] <SWPLinux> ah, i gives the commands issued (I think)
[16:58:32] <SWPLinux> wow. that is a shitload of stuff printed on the terminal
[16:58:36] <jepler> yes there is
[16:58:39] <SWPLinux> with --debug=v,i :)
[16:59:09] <jepler> SWPLinux: for the delete problem, try putting this file as lib/python/Tkinter.py:
http://svn.python.org/view/*checkout*/python/branches/release25-maint/Lib/lib-tk/Tkinter.py?content-type=text%2Fplain&rev=65400
[17:00:40] <SWPLinux> yep, that seems to fix it
[17:01:38] <jepler> ok, that's useful to know. can you put a report on sf or something with that info?
[17:01:57] <SWPLinux> sure
[17:02:14] <jepler> I hate progress
[17:02:18] <SWPLinux> he
[17:02:20] <SWPLinux> h
[17:04:21] <SWPLinux> it's a little bit puzzling why make is building docs well before the compiling and linking are done
[17:04:28] <SWPLinux> I thought docs were done last
[17:04:57] <cradek> if there is not a dependency, it will do whatever it feels like
[17:05:07] <SWPLinux> but I guess with -j, the last dependency chain (docs) might get started a long time before the others are done
[17:05:09] <SWPLinux> yep
[17:05:28] <cradek> there is some dependency - comps get preprocessed and make manpages that get put in a pdf (I think)
[17:05:33] <cradek> but most of it is independent
[17:07:52] <jepler> SWPLinux: making sure that you don't have the replacement Tkinter on your python path (e.g., you haven't ". scripts/emc-environment"), tell me if this program exits normally or prints an error like the one you got from axis:
http://emergent.unpy.net/files/sandbox/menu_delete.py
[17:10:14] <SWPLinux> running it with "python menu_delete.py" gives no error
[17:10:19] <jepler> ok
[17:10:41] <SWPLinux> it also displays nothing, if that matters
[17:10:54] <jepler> yes that's fine
[17:13:35] <jepler> (you didn't have the replacement Tkinter in the same directory as where you ran menu_delete.py did you? that would also use it instead of the system one)
[17:14:19] <jepler> (er, the same directory where menu_delete.py resides)
[17:14:32] <SWPLinux> err. whoops
[17:14:41] <SWPLinux> download dir to the - err - rescue
[17:15:04] <SWPLinux> same result after moving tkinter to a subdir
[17:15:12] <jepler> hm
[17:15:22] <SWPLinux> ah-ha
[17:15:37] <SWPLinux> different result when I also move the generated Tkinter.pyc file
[17:15:43] <SWPLinux> same error
[17:15:43] <jepler> oh -- yeah
[17:15:51] <jepler> #
[17:15:52] <jepler> AttributeError: 'NoneType' object has no attribute 'remove'
[17:15:54] <jepler> ^^ this one?
[17:16:03] <jepler> _tkinter.TclError: can't delete Tcl command
[17:16:05] <jepler> ^^ or this one
[17:16:22] <jepler> (I get that one)
[17:16:34] <jepler> (when I put a newer Tkinter.py on my hardy system)
[17:18:04] <SWPLinux> number 2, "can't delete TCL command"
[17:18:37] <jepler> so it's still not quite the same thing as above
[17:19:52] <SWPLinux> true, sorry about that
[17:20:36] <SWPLinux> http://pastebin.ca/1336226
[17:22:13] <SWPLinux> note to self: always exit from script session before viewing the log file
[17:27:30] <jepler> OK, remove Tkinter.py and .pyc from lib/python and try this patch (rebuild after, because it changes a .in file):
http://emergent.unpy.net/files/sandbox/jaunty_menu_delete.patch
[17:30:02] <SWPLinux> interesting. "make" didn't appear to do anything other than try again to build some docs
[17:30:54] <jepler> o rly
[17:31:02] <jepler> * jepler scratches his head
[17:31:33] <SWPLinux> I'm doing make clean ' make just to be sure, but it certainly didn't print anything before
[17:32:50] <jepler> $(INFILES): %: %.in config.status
[17:32:50] <jepler> @./config.status --file=$@
[17:33:01] <jepler> The command is @'ed and config.status must not print anything ?
[17:33:22] <SWPLinux> you know, it looks like the pdf file got created, but lyx returned 1 so make thought it didn't work
[17:33:34] <SWPLinux> when I run the command manually, I get a manual :)
[17:33:40] <SWPLinux> (and an exit status 1)
[17:33:59] <jepler> fucking fuck fuckers -- LyX succeeds and then exits with result 1?
[17:35:58] <SWPLinux> it appears that way, but I'm not sure
[17:36:00] <SWPLinux> yet
[17:36:11] <seb_kuzminsky> SWPadnos: are you using lyx 1.6.1?
[17:36:30] <SWPLinux> there are some conditions that it tells me about - things like fonts being not exactly right or something
[17:36:42] <jepler> when I touch nf.in and make, make prints: config.status: creating ../lib/python/nf.py
[17:36:55] <SWPLinux> seb_kuzminsky: yes
[17:37:06] <SWPLinux> jepler: in the emc2/lib/python dir?
[17:37:36] <SWPLinux> where does that come from anyway, I tried to make sure I had patched it correctly and cvs doesn't know anything about that file
[17:37:45] <jepler> lib/python/nf.py.in
[17:37:54] <jepler> I typed nf.in at least once, but that's not the right path
[17:39:12] <SWPLinux> ok, I must have done a thinko/typo also
[17:39:23] <SWPLinux> I'll try the touch trick
[17:40:14] <SWPLinux> I wonder if it's trying to make the docs (which fails) before fiddling with the nf.py.in file
[17:40:40] <jepler> that's possible; you could "make -k" to continue after errors..
[17:40:47] <SWPLinux> yep
[17:41:21] <SWPLinux> I have a 2.7M lyx log file, if anyone wants to look at it :)
[17:42:30] <SWPLinux> make will delete object files that may have been created if the program appears to have failed, right?
[17:43:50] <jepler> `.DELETE_ON_ERROR'
[17:43:50] <jepler> If `.DELETE_ON_ERROR' is mentioned as a target anywhere in the
[17:43:50] <jepler> makefile, then `make' will delete the target of a rule if it has
[17:43:50] <jepler> changed and its commands exit with a nonzero exit status, just as
[17:43:50] <jepler> it does when it receives a signal. *Note Errors in Commands:
[17:43:53] <jepler> Errors.
[17:43:58] <jepler> (I don't think we have DELETE_ON_ERROR but I didn't grep to check)
[17:44:26] <SWPLinux> ok, it doesn't look that way now anyeay
[17:44:42] <SWPLinux> make -k didn't do the job, though it did try to process nf.py
[17:45:09] <SWPLinux> well, it probably did, but it said "target blah blah not remade because of errors"
[17:45:20] <SWPLinux> the change didn't solve the problem, let me make sure it got changed
[17:45:50] <SWPLinux> yep, looks it
[17:46:07] <SWPLinux> I get "can't delete Tcl command"
[17:46:16] <jepler> so it changed from the first error to the second error?
[17:46:52] <SWPLinux> yes
[17:46:58] <SWPLinux> (I guess ...)
[17:47:45] <SWPLinux> http://pastebin.ca/1336245
[17:50:17] <jepler> next patch (half the same as the old patch):
http://emergent.unpy.net/files/sandbox/jaunty_menu_delete-2.patch
[17:52:10] <SWPLinux> one sec - make hasn't finished (I didn't use -j this time)
[17:53:31] <jepler> if you toss the lyx log somewhere I'll try to look at it later
[17:58:52] <CIA-2> EMC: 03tissf 07TRUNK * 10emc2/src/po/ (fr_axis.po fr_rs274_err.po): french translation recent change
[17:59:40] <cradek> http://emc2-buildbot.colorado.edu/buildbot/waterfall
[17:59:44] <cradek> waiting!
[18:00:30] <seb_kuzminsky> 2 mins wouldnt have saved bjt from that failure earlier
[18:00:43] <seb_kuzminsky> there was a 6-min window when the tree was unbuildable
[18:04:08] <cradek> yeah, but that was just a mistake he made, I think
[18:04:39] <cradek> this wait is plenty long for related commits in different directories, done one after another
[18:20:13] <SWPLinux> jepler:
http://www.linuxcnc.org/dropbox/lyxlog
[18:23:48] <SWPLinux> jepler: result from patch 2 at
http://pastebin.ca/1336282
[19:24:09] <jepler> SWPLinux: ah, I'll give it another try later
[19:35:04] <jepler> SWPLinux: as for lyxlog, I'm not enlightened
[19:36:25] <SWPadnos> heh
[19:36:27] <SWPadnos> me either
[19:36:48] <SWPadnos> I'll have to experiment more over the weekend
[19:37:19] <jepler> I hear the lyx in hardy-backports has the same (?) problem. if I get bored, I'll try that.
[19:37:30] <SWPadnos> is that also 1.6.1?
[19:37:33] <jepler> most of that stuff looks like it comes from debug categories that are not interesting, like 'bind'
[19:37:36] <jepler> yes, I think so
[19:37:50] <SWPadnos> oh, I just did -dbg all, so I'm sure there's mostly noise in there
[19:37:50] <jepler> so refining the -dbg flag would help
[19:37:53] <SWPadnos> heh
[19:38:09] <SWPadnos> it looked like some of those messages might have been "pseudo-errors"
[19:38:24] <SWPadnos> there was something I noticed about a font size that wasn't available
[19:38:49] <SWPadnos> (something like 8.9 point size)
[19:39:55] <jepler> if you want to call my attention to a specific line, you should give me a searchable string or a line number
[19:40:08] <SWPadnos> I'll do that later. I can't really work on it at the moment
[19:40:13] <jepler> heh
[19:42:08] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/po/it_axis.po: update from Ernesto Lo Valvo
[19:45:06] <jepler> ihttp://emergent.unpy.net/files/sandbox/jaunty_menu_delete-3.patch
[19:45:09] <jepler> s/^i//
[19:48:13] <SWPLinux> that one works
[21:05:15] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/lib/python/nf.py.in: fix axis on jaunty alpha (thanks swp for testing the patch)
[22:11:49] <jepler> I've determined that whatever makes lyx 1.6.1 throw a fit for Master_User.pdf is in gcode/tool_compensation.lyx
[22:11:57] <jepler> removing only that include allows that pdf to be built
[22:12:19] <SWPadnos> oh, cool
[22:14:03] <jepler> and processing just that file, there's an actuall TeX error in the log
[22:14:05] <jepler> ../../src/LaTeX.cpp(696): line: 71
[22:14:05] <jepler> Desc: LaTeX Error: Not in outer par mode.
[22:14:05] <jepler> Text: \begin{figure}[h]
[22:14:05] <jepler> You've lost some text. Try typing <return> to proceed.
[22:14:07] <jepler> If that doesn't work, type X <return> to quit.
[22:14:44] <jepler> line 71 of what, I dunno :-P
[22:15:14] <skunkworks_> line 71 of png file.. ;)
[22:27:36] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/docs/src/gcode/ (tool_compensation.lyx tool_compensation_fr.lyx): subcaptionText seems to give LyX 1.6.1 (jaunty, hardy-backports) fits.
[22:29:19] <jepler> (that still leaves two more pdfs that don't build)
[22:40:42] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/docs/src/config/ini_config_fr.lyx: another construct that gave lyx 1.6.1 fits
[22:40:43] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/docs/src/hal/ (rtcomps_fr.lyx tutorial_fr.lyx): another construct that gave lyx 1.6.1 fits
[22:40:46] <jepler> (that finishes it, I think)
[22:41:08] <SWPadnos> heh. I was just about to say that the same two (probably) weren't working here
[22:42:25] <SWPadnos> ok, that seems to work
[22:42:30] <SWPadnos> thanks a lot for that!
[22:42:43] <jepler> yay
[22:42:51] <SWPadnos> testing a clean biold now
[22:42:53] <SWPadnos> build
[22:42:57] <SWPadnos> using -j as well
[22:47:43] <jepler> ... and ?
[22:47:49] <jepler> (it's been minutes!!!)
[22:48:02] <SWPadnos> oh sorry, got sidetracked
[22:48:06] <SWPadnos> it appeared to work
[22:48:20] <SWPadnos> (in 2m 18.816s)
[22:50:18] <jepler> the pdfs look ok on my system
[22:56:00] <SWPadnos> damn. now what the heck do they call kpdf now
[22:56:17] <SWPadnos> ah, okular
[22:56:36] <SWPadnos> sounds like a bad guy that Steve Austin would have fought
[23:02:36] <SWPadnos> hmmm
[23:02:46] <SWPadnos> actually, the TOC section 11 looks funny
[23:02:50] <SWPadnos> G codes
[23:03:21] <SWPadnos> the subsection numbers spill over the names
[23:03:32] <SWPadnos> (see subheads 11.10 and up)
[23:17:28] <jepler> yeah that's true
[23:17:31] <jepler> I tried to ignore it
[23:21:46] <alex_joni> the NO_FORCE_HOMING will surely cause a stirr when 2.3 is out ;)
[23:22:18] <SWPadnos> it may be that we want to put it in the sample configs (that use trivkins)
[23:26:37] <jepler> bah
[23:50:10] <BigJohnT__> BigJohnT__ is now known as BigJohnT
[23:58:39] <jepler> short downtime coming up for cvs to reboot the machine where its vmware image lives
[23:58:49] <jepler> thanks ubuntu for the copious security updates :-P
[23:58:54] <SWPadnos> heh