PCW_ is now known as PCW
what is the normal command to build emc2 packages? dpkg-buildpackage?
there's two convenient ways
the most debian-like way is dpkg-buildpackage
the quick & easy way is "debian/rules binary"
run from the top-level dir of your git checkout
first you need to run "configure" in the debian dir
I used dpkg-buildpackage before and I didn't know if it did something different or more than fdr binary
I did that, and edited "configure" for my kernel too.
dpkg-buildpackage can do some extra things like sign the packages & changes files
Can I get the script that you are using to update the changelog?
I'm making packages of the 2.4 branch for karmic.
you can see the exact sequence of steps the buildbot does if you like, by clicking on the links of the builds on the waterfall page
I've done some before, and they're on experimental, but I'm making an updated set
I'll do that...
it'd be cool if you made a karmic buildslave, we'd get automatic karmic debs on each commit
My plan is to start building packages for Lucid as soon as RC1 comes out.
that'd be super useful
How would I do that?
you need a computer that can check out and compile the emc2 git, and make one additional TCP connection out (to the buildmaster)
then you need to install the buildbot package
that's about it
it's pretty easy
They (jepler, cradek) already said I'm elected to build the Lucid packages, so I figure I better practise.
here's some instructions i typed up a while ago, not sure if they still work but it's a start: <http://emc2-buildbot.colorado.edu/buildslave-admin-guide.html>
oops, there's at least one bug on that page, we no longer use cvs...
I need to get input on how to configure the kernel. I'm doing it as generic as I can for smp on karmic.
This has worked for me on as least three single core computers.
as well as dual-core
32-bit or 64?
ah, there's one more thing needed on the buildslave to build the debs, you need to set up a pbuilder chroot environment
I use 'debuild' to build and sign packages
cradek: well the good thing about standards is that there are so many to choose from
oops I forgot to measure the thing, brb
I'll try and look at the buildbot stuff when I get a chance.
mozmck: that'd be super awesome, i'd love to have a karmic machine in the buildbot
one of the cool things with buildbot is it's designed to make it easy to run slaves - all the smarts & configuration is on the buildmaster
neat! is that something you wrote?
no, i'm not nearly that cool ;-)
it's a widely used piece of build/test infrastructure
I see :)
I guess for people to run 2.4 rt they would need my kernel and rtai packages.
I need to get someone to upload them to experimental for me sometime here.
mozmck: that sounds right
cradek: THAT'S WHAT SHE SAID!!!
seb_kuzminsky: now I'm afraid to say that 5/8 is a very tight fit
ok i'll look for 4/8ths
pretty sure 5/8 will fit (I couldn't find a bolt, but I had a dowel - bolts are slightly under nominal), but there won't be much wiggle available
maybe 1/2-13 is better - certainly more available
i better get a long 1/2" drill bit too, so i can drill through the foot-hole to ensure alignment
I bet a spade bit would be easiest
surely we have one
1/2-13 grade 8 "clamp load" 13k lb, whatever "clamp load" is
I lost the waterfall page...
hm, maybe not that long
it'd be nice not to have to spot the floor, move the mill, drill the floor, then move the mill back to the exact same spot
yeah I was just typing how we could mark through the holes and then move the mill...
mozmck: everything's linkef from here: http://emc2-buildbot.colorado.edu/
ah, just found it.
mozmck: the buildmaster does things in two phases
first it builds & runs the tests on all supported the platforms
if that all works, it then builds debs on the platforms that support it
so if you start at the leftmost column, scroll down to where it says "build 157", that's where it noticed jeff's most recent checkins
the tall green box above that is where it triggered "build & test" runs on all platforms that support it
those triggered builds show up in the columns to the right
over there you can see the steps taken (some steps consist of multiple shell commands on the buildslave)
after they all pass, the first step in the leftmost column is finished (the first green box is done), and it starts the second, which triggers the debs
i think it can look a bit confusing how it all fits together, until you sort of grok what it's doing, then it makes perfect sense ;-)
:) I haven't grokked it all, but it makes some sense.
right now I'll just build the packages, but I'll look at the buildbot stuff some more. I'll probably need some pointers when I get to that.
sure, i'm here, or if i'm not feel free to email me off-list
setting up a buildslave is really pretty easy
so I just run update-dch-from-git with no arguments?
look at the master-package-sim-hardy-source builder (second from left)
the second step it does updates the changelog
[03:42:16] <seb_kuzminsky> http://emc2-buildbot.colorado.edu/buildbot/builders/master-package-sim-hardy-source/builds/115/steps/update%20changelog/logs/stdio
it runs "debian/update-dch-from-git master"
from the checkout root dir
ah, but be careful, that modifies the changelog, which is a file controlled by git
so be careful to not check it in!
I see. so for v2.4_branch I would use that instead of master?
"git checkout debian/changelog" will discard any local changes you have to that file
ok. I wondered about that. how do you handle a pull then on the buildbot?
the buildbot has a "pristine" checkout that it never builds in, and it copies it to a temporary "build" checkout before doing anything to it
see the output of the first step ("update") of that builder: http://emc2-buildbot.colorado.edu/buildbot/builders/master-package-sim-hardy-source/builds/115/steps/git/logs/stdio
I just saw that. I'm getting the hang of the waterfall page now I think....
it runs several shell commands on the buildslave: remove the "build" directory, update the checkout in the "source" directory, do some other git bookkeeping stuff, then copy the "source" dir to "build"
and then the "build" dir has the change that was just committed (that we're trying to build now), it's all fresh and pristine, and we're free to mess it up by compiling and changing files and stuff
is that all part of the buildbot package?
it's part of the buildmaster config that i wrote
it's on the emc2-buildbot.colorado.edu computer
slaves connect to it, and the master uses its config to tell them what to do
oh, maybe you asked this: the sequence of git steps *is* part of the buildbot package, buildbot has a notion of revision control systems, and the buildmaster config has a single command in it that says "refresh the slave's git checkout to this commit on this branch"
sounds really neat
it's the knee's bees
and boy howdy would i like to have your karmic buildslave in the emc2 buildbot :-)
I don't know how I'll set it up right now. my internet router is running an older version of debian.
the router shouldnt care
the buildslave connects out to the buildmaster
What is the port number? I would have to open it on that machine.
the port number on the buildmaster is 51332
(that's 5-13-3-2, for e-m-c-2, funny joke)
I think that's how I have it setup....
does your router block outgoing tcp syns? that's unusual
heh, I told it to. It's just a debian linux box that I set up as a router and firewall
I think I set it up to block everything except what I allowed.
what's a tcp syn?
it's a connection request, how you start a tcp connection
try this on your karmic box: telnet emc2-buildbot.colorado.edu 51332
cool, then setting up a buildslave should be very easy
I may have changed my settings. been too long and I just learned what I needed at the time and forgot most of it now
great. I'll look at that.
it's a bit of a commitment, having a computer that's often checking out and compiling emc2 and running the test suite
if you take it down or disconnect it from the network it'll make a red splotch on the waterfall page
yuck! I normally leave it up anyhow, but sometimes the internet here can be down for a while.
here's a plot of people downloading debs from the buildbot: http://emc2-buildbot.colorado.edu/~seb/billions-served/
I'm on wireless and if it rains too hard or something it's liable to be down for half a day or so.
* seb_kuzminsky is busted!
but 60 downloads of the debs in the past few weeks is pretty good i think :-)
yeah, not too bad! is there a link on the wiki for them?
i think not yet
but jeff recently announced it to the emc-users list, it started getting more hits after that
now that it's announced i should add a link on the wiki...
* seb_kuzminsky edits the wiki
oh no, there is a link already: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Installing_EMC2#Debs_of_recent_git_versions
any hickups building emc2 on karmic so far?
I need to make a couple of edits to build on my machine.
I have to add --with-tclConfig=/usr/lib/tcl8.5/tclConfig.sh --with-tkConfig=/usr/lib/tk8.5/tkConfig.sh
to the configure command
maybe our configure should be smarter
i think a guy(?) named clytle on #emc was running emc2 on karmic the other day
I think I have tcl/tk 8.4 as well as 8.5 so it needs that.
it needs both? strange...
I've built for karmic since the first week karmic was out.
no, but I have both and it confused configure
have you tried the languid lemur alphas, or are you waiting for rc1?
but I'm not sure how I would handle that with a buildbot. I have to change debian rules
no, I haven't tried them yet.
the best would be if our configure didnt get confused
that way not only would the buildbot work smoothly, but users would be less annoyed
oh yeah, i get a ton of compiler warnings when building sim on karmic...
I get warnings like dpkg-shlibdeps: warning: dependency on libpangoft2-1.0.so.0 could be avoided if "debian/emc2/usr/bin/halscope debian/emc2/usr/bin/classicladder debian/emc2/usr/bin/halmeter" were not uselessly linked against it (they use none of its symbols).
somebody should stop all that useless linking ;)
yes, i get those too (and so does the buildbot, and everyone else)
i've been meaning to fix that
looks like it built emc2 and emc2-dev packages, but I don't see any sim
should it do that automatically?
you configure the source dir for either sim or rt
and it builds either (emc2 and emc2-dev) or (emc2-sim and emc2-dev)
it's a bit confusing, i think, but what you saw is what it's "supposed" to do
so how would I make it build sim? (with dpkg-buildpackage that is)
configure --enable-simulator && dpkg-buildpackage
but debian/rules reruns configure doesn't it?
(cd debian; ./configure sim) && dpkg-buildpackage
or... "apt-get install buildbot" and let the buildmaster worry about it ;-)
ah, I forgot about the debian/configure sim
packages install and run!
do the runtests pass?
what are those?
there's a pile of unit tests in the git repo, they're in /tests
you can only run them if you configure for run-in-place, i think
then you "source scripts/emc-environment" and "runtests"
works for both rt and sim
oh, I didn't know about those.
they're great :-) saved me much embarrasment
so can I run them on an installed emc?
no, only run-in-place i think
ie, configure without a --prefix, so it wants to run out of the dir where you checked out and compiled it
so I have to recompile for run-in-place to run them?
the test sweet is suite
what all does it test?
the tests all live in /tests
in the git repo
I was running master a few days ago testing some hardware.
there are targeted tests for several of the hal components
the g-code interpreter, trajectory planner, etc
not the tp, unfortunately
a wide swath of sanity checks
pretty heavily tests the interpreter (so easy to break)
oh, right, i think the stuff i was thinking of was the list of canon commands output by the interpreter(?)
yeah big chunks aren't covered
yeah that's how the interp is tested
it tests the "comp" program (i know this because i broke it the other night and the test suite complained)
but nothing says motion will follow those commands right
all runtests passed
that just means we dont have enough tests yet ;-)
hmm, so there are no mesa-firmware packages anymore?
not as part of the emc2.git, they're in a separate repo now
[04:47:14] <seb_kuzminsky> http://emergent.unpythonic.net/
so do I need to build a package for them as well?
just install jeff's debs
they're on linuxcnc.org
I need someone to upload these packages I made to experimental/Karmic in place of what is there.
i dont think i have write access to linuxcnc.org
the hm2 firmware debs are mentioned here: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UPDATING#hostmot2_firmware_images
ok. I think SWPadnos did it last time.
i think they're in the "base" component of the debian archive there, but i'm not sure
mozmck, stick them somewhere and post a link here. I'll stick them on linuxcnc.org in the morning, if someone else hasn't gotten to it by then
[04:52:00] <mozmck> http://192.168.0.1:8090/emc2/
oh. maybe I'll do it now then :)
but there are no mesa fimewares
good, there are supposed to be none :-)
um. I'd need an externally accessible IP address first though
that's my server here. not the fastest link but not too bad
You can't get to it?
no. 192.168.0.1 is my router here :)
192.168 is a non-routed IP, it's only visible behind your home router
mine too sorry
(192.168.x.x isn't supposed to be forwarded over the internet, it's for private networks)
[04:55:01] <mozmck> http://22.214.171.124:8090/emc2/
ah. significantly better, thanks
I know, that's what I had my browser pointed to and forgot
and these packages are for Karmic (9.10)?
yes. the kernel and rtai packages are there as well
replace everything in experimental/Karmic with these.
oh, probably don't know linux-doc
let me remove that right quick
argh. can't do wildcards with http (using wget)
is there an http fuse yet?
do you have an FTP server on that machine?
how'd you do it last time?
don't think so.
I don't know, but if there is, I probably don't have access to it on DreamHost
and I'd rather transfer directly there instead of downloading here (at 2Mb/sec) and the re-uploading (at 256kb/sec)
ok, I can copy/paste the names reasonably quickly
no index, not sure how it would get the listing
right-clicking works very well here, so the files are on their way
sure. and thank you
"wget -r" then mozmck's url works here, it started to getch the first deb before i killed it
and by getch i mean fetch
ok, that's probably what I used last time
it's easy to forget those things when you use them once per season or so
heh, that's why I like gui's for a lot of things
remote GUIs on systems that don't support them are difficult ;)
yeah, but some folks don't like GUIs for anything. I can't remember all the commands for everything if I don't use it often.
I better get to bed. thanks again!
thanks mozmck :-)
me too. night guys
EMC: 03seb 07master * rf0a6040452b5 10/src/hal/utils/Submakefile: avoid linking to a couple of unused libraries
EMC: 03seb 07master * re38906703379 10/src/emc/ (rs274ngc/Submakefile sai/Submakefile): link librs274 against libemcini
well i thought i was going to be
"just one more fix" i thought
EMC: 03seb 07master * r4d32b8906113 10/src/Makefile: fix linking when compiling for installation
EMC: 03seb 07master * r4b75c00edcd8 10/src/Makefile: fix a stupid bug in my previous commit
SWPadnos: you around?
SWPadnos: SeaMonkey looks pretty nice
not that different from OE
is it better than firefox/thunderbird?
I'm here now
it looks like the files all got transferred
looks like! would it be too much trouble to make a dir and separate the new ones from the old?
mozmck, sure. I backed up the old ones (in .old), I'll clean it up now
ok. it just looked like they were all in there.
I do note that these packages weren't all made on the same day though - some of them are dated 3/5, others 3/12
no kernel changes for the last week I guess :)
does it make sense for you to make new source packages?
for the kernel?
I used the "proper" ubuntu method for this kernel and it made a nearly empty source package.
kernel, RTAI, or emc2
there are also two kernel headers packages, with an extra "rtai" thrown into one of the names
I think I have to pass it another arg to make the rest of the source in a different package.
yes, the "proper" ubuntu way makes more packages.
are they both needed?
the one is the generic headers, and it looks like the other contains the extra stuff from the rtai patch
I think they are both needed
not sure if there's a way to make it put them all in one package or not.
should I leave the old firmware packages?
I don't know! stuff has changed so I don't know if those will work or not.
well, I'll leave them then
no sense messing up the clutter
probably good. they might work.
hmmm. what about the RTAI packages?
source, doc, librtai*
there's only one for the new one
ok, so all the old ones can go
one package. I used the rules file jepler used for hardy and it only made the one packages
will we want an rtai source package for the release?
I'd assume so
ok, take a look now
I guess the "old" directory could be visible
yeah, someone might want to mess with that still
doesn't look like the rtai debian/rules or the emc2 debian/rules will build source packages
you might remove the firmware packages now from the main dir because they are in OLD
or maybe it doesn't matter...
if they work, then people with mesa cards need them
so I left them in the main dir such that there's a complete set there
yep, and I think they will install. doesn't look like they depend on a specific version of emc
if they don't work, I'll delete them (or better yet, replace them with new ones :) )
Looks like the new way to get the firmware for right now is from here according to seb: http://emergent.unpy.net/01267622561
I wonder what it takes to make packages for them?
hmmm. that's an auto-built set of firmwares, I don't think it's meant to be "the" way to get them
jeff managed to make some scripts that cause the Xilinx tools to generate the bitfiles. it looked like it wasn't easy
I don't know. I just know that debian/rules doesn't build them anymore.
that's a couple GB download from Xilinx, and hours of processing time
huh. I have ise 10.x
that could work. I don't remember which version the scripts were developed with
I think he said 9 something, but not sure
make backups of your chip description files, I think Pete said they're dropping support for the Spartan 2 from the free version
(but you can add it back by copying the chip description files to the right place)
I see. clever of xilinx. sell more new chips!
sell more software to people who have to support old chips
they always make the free version work with the current "mainstream" - if you're using the biggest chips you have to pay, and if you're using the oldest chips you have to pay
makes sense - a single large FPGA costs 5x as much as the software, so you might as well buy it
and if you're supporting old stuff, it's probably not a hobby :)
(plus they can't sell chips for that design any more, since they're old)
"dpkg-buildpackage -S" builds the source package. it doesn't depend on any rule in debian/rules
I think the kernel is an exception to that, but usually it's done with dpkg-buildpackage
the hostmot2-firmware packages in the hardy deb repository will probably install on any system, because they have no Depends:
fwiw, you guys are my heroes for dealing with this stuff
how can I make lathe to work like this: http://www.youtube.com/watch?v=5AB_etoHesI
(I mean C axis like spindle or something simmilar)
micges: I will look later - no flash here
hex milling on the GTV-27
"this is particularely easy on the Fagor control.."
"You select XC plane and program the tool path in cartesian coordinate. No need to use polar coordinates."
alex_joni: maybe you have idea how to enforce emc to control such a machine?
for hex milling?
just setup the spindle as axis C
different config maybe
or switch using a custom M-code
micges: maybe there's an aspect I'm not aware of..
I must check how can I switch spindle with encoder
micges: not following..
here or on #emc ?;)
I know how can I switch from spindle to C axis but there will be huge ferror if I simply do that
spindle has encoder
you need to reset the encoder count on switching
is it make ferror in oposite direction? I have C=100 and enc counts=1000 and if I reset it I'll have enc counts=0 and C pos cmd=100, still ferror (I think)
not reset to 0
reset to the current cmd
while the spindle works as a spindle you have a fb<->cmd loopback
as soon as you want to switch you need to preload the encoder with the cmd value
and then switch, I got it
I think in your case it's best to make a custom component, then try to do it with muxes and other hal gates
i want to merge 2.4 into master, to get the first batch of packaging fixes
jepler, cradek, does that sound ok?
sure I think you can do that anytime
EMC: 03jepler 07master * r0782f7deb097 10/src/Makefile: don't put stuff in /usr/local
EMC: 03jepler 07master * r3162ca884d3d 10/src/Makefile: Don't install lib*.so files, they're not needed
EMC: 03jepler 07master * rc9981698411d 10/docs/src/gcode/main.lyx: NURBS is so broken it's not worth documenting
EMC: 03jepler 07master * rabcb2c18b7cc 10/src/ (8 files in 8 dirs): undo the previous broken commit
EMC: 03jepler 07master * rc2c7bcac8eb3 10/docs/src/gcode/main.lyx: improve G96 discussion
EMC: 03jepler 07master * re289537f81b8 10/src/ (8 files in 8 dirs): stop pretending that unversioned .so's are useful
EMC: 03jepler 07master * rdd8c21350ac9 10/ (debian/emc2-dev.files debian/emc2.files.in src/Makefile): Put the unversioned .so symlinks in emc2-dev.deb
EMC: 03jepler 07master * r78dabc105291 10/src/Makefile: make the unversioned .so symlinks a bit simpler
EMC: 03jepler 07master * r3ebf987130f2 10/src/hal/components/steptest.comp: ensure maxvel is reached during jogging by setting target further from current
EMC: 03jepler 07master * r5005549d698e 10/src/hal/drivers/mesa-hostmot2/hm2_test.c: Fix up some comments
EMC: 03jepler 07master * r5471aa23dbc6 10/tests/hm2-idrom/broken-load-test.hal: be more verbose when testing
EMC: 03jepler 07master * rf7d1c9a14ecd 10/src/hal/drivers/mesa-hostmot2/pins.c: fix an off-by-one error when counting IOPort instances
EMC: 03jepler 07master * rd1dfaf1651bb 10/ (10 files in 6 dirs): Merge commit 'origin/v2.4_branch'
seb_kuzminsky: there you go. like cradek says, you could have done it yourself if you'd wanted.
EMC: 03jepler 07master * r70fca8469127 10/ (3 files in 2 dirs): add a test with IO Pins but no IOPort module instances
SWPadnos: found one thing I don't like about seamonkey.. it doesn't show status for forwarded,replied emails