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