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