#emc-devel | Logs for 2006-06-09

Back
[01:23:26] <SWPadnos> SWPadnos is now known as SWP_Away
[01:38:15] <SWP_Away> SWP_Away is now known as SWPadnos
[12:03:41] <jepler> alex_joni: having recently built them, can you improve the wiki documentation on building the kernel or rtai-modules at all?
[12:04:03] <jepler> alex_joni: I wanted to try to fix the /dev/rtf udev problems, but I couldn't figure how to put the rtai source in the right location in the first place.
[12:06:25] <alex_joni> jepler: it's a bit more complex to do that
[12:06:33] <alex_joni> you need to debianize it too
[12:06:48] <alex_joni> so I think the easiest is to apt-get source a already done package
[12:06:59] <alex_joni> but it needs to go under /usr/src/modules
[12:08:52] <alex_joni> fwiw it's all in the wiki
[12:09:04] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?UbuntuBreezyPackages <- bottom
[12:09:43] <jepler> "install and untar linux-source, patch it as required install and untar rtai-source (/usr/src/modules/rtai-3.3) " ?
[12:10:06] <jepler> where did you get rtai-source? 'apt-cache show' says there is one, but it's a different version (3.2 vs 3.3mumble)
[12:10:26] <alex_joni> I got it from CVS
[12:10:26] <alex_joni> and debianized it
[12:10:34] <alex_joni> but that's not something I would recomend
[12:10:37] <jepler> is there something I can grab from the dapper repository, then?
[12:10:40] <alex_joni> I have little clue about it
[12:10:43] <alex_joni> yeah, there is
[12:11:11] <alex_joni> apt-get source rtai-modules-2.6.15-magma
[12:11:33] <alex_joni> I think
[12:12:42] <alex_joni> although I think 'apt-get source rtai' should be the magic incantation
[12:12:54] <alex_joni> morning samco
[12:13:01] <skunkworks> morning alex
[12:13:06] <alex_joni> how's it?
[12:13:31] <skunkworks> ended up not taking it home - but ran the latency test all night. looks good
[12:13:39] <alex_joni> great
[12:13:45] <skunkworks> did you see my paste bin?
[12:13:54] <alex_joni> not sure
[12:13:59] <alex_joni> can you send it again?
[12:14:12] <jepler> alex_joni: is it important to do the 'apt-get source' from /usr/src/modules, or not?
[12:14:31] <skunkworks> http://pastebin.com/768446
[12:15:01] <alex_joni> jepler: any apt-get source is important where it happens
[12:15:15] <alex_joni> but you could do it elsewhere and move the directory there lateron
[12:15:35] <skunkworks> if i change rtf/3 to rtf3
[12:15:37] <skunkworks> it works
[12:16:01] <jepler> alex_joni: surely the place where you put the source shouldn't matter -- one person will usually use /home/ernie, another will use /home/bert
[12:16:17] <alex_joni> jepler: yeah, but not if you plan to build modules from it
[12:16:45] <jepler> I thought you were saying that it did *always* matter
[12:16:47] <alex_joni> make-kpkg modules_image expects stuff in /usr/src/modules/*/
[12:17:15] <alex_joni> it matters where you run the command, because there is where you'll end up with the sources
[12:17:40] <alex_joni> skunkworks: it seems that the latest RTAI I packaged uses /dev/rtf3 not /dev/rtf/3
[12:18:53] <alex_joni> skunkworks: updated the wiki to say: created both. can't hurt
[12:20:34] <skunkworks> thanks
[12:23:31] <alex_joni> > I found out that RTAI supports devfs. Is this true? But does it also
[12:23:31] <alex_joni> > supports udev?
[12:23:31] <alex_joni> >
[12:23:31] <alex_joni> There is still something that does not work on certain machines, while
[12:23:31] <alex_joni> it does on other. The issue is evolving in magma and should be really
[12:23:33] <alex_joni> stabilised in 3.4 (not so far away).
[12:24:29] <jepler> bbl
[12:48:14] <alex_joni> https://www.rtai.org/index.php?module=documents&JAS_DocumentManager_op=downloadFile&JAS_File_id=45
[12:48:42] <alex_joni> that's the rtai Manual.. interesting.. I never knew it was there :D
[12:49:09] <SWPadnos> heh
[12:49:20] <SWPadnos> I just went to download it, and I already had a copy
[12:49:24] <SWPadnos> which I didn't know was there ;)
[12:49:25] <alex_joni> lol
[12:49:33] <alex_joni> you're even worse :D
[12:49:41] <SWPadnos> yep.
[12:49:51] <alex_joni> ;)
[12:50:07] <SWPadnos> are you on the forwarding list for webmaster@linuxcnc.org?
[12:51:34] <alex_joni> I think so?
[12:51:56] <SWPadnos> did you get the email today about stepper motors from cnsoyo.com?
[12:52:57] <alex_joni> nope
[12:53:05] <alex_joni> guess I'm not subscribed
[12:53:41] <SWPadnos> ah - hold on
[12:53:46] <SWPadnos> http://www.cnsoyo.com/cp_1_15_e.asp
[12:54:17] <SWPadnos> the email looked like spam, but it's interesting - they make some big steppers
[12:54:23] <alex_joni> how much?
[12:54:47] <SWPadnos> good question. the email said they were looking for importers ... (that's the spam part ;) )
[13:02:27] <alex_joni> SWPadnos: the 8A / phase might be a bit much for a gecko :D
[13:02:39] <SWPadnos> heh
[13:02:57] <SWPadnos> even the 6.5A/phase one has a fair amount of torque
[13:03:07] <alex_joni> yup
[13:03:09] <alex_joni> looks like it
[13:03:53] <alex_joni> http://www.cnsoyo.com/cp_1_19_e.asp
[13:03:58] <SWPadnos> 2973 oz-in, if I did the math right
[13:04:23] <alex_joni> * alex_joni has little clue what on oz is :D
[13:04:28] <SWPadnos> yeah - I had noticed the 300 step/rev motors (and others)
[13:04:35] <SWPadnos> heh
[13:04:51] <SWPadnos> 28g, of course ;)
[13:05:01] <alex_joni> seen that SY1303P280-5003A ?
[13:05:08] <SWPadnos> or 32, if you're measuring precious metals
[13:05:11] <alex_joni> 50Nm Holding torque
[13:05:20] <alex_joni> 22 kg stepper
[13:05:24] <alex_joni> that's a biest
[13:05:26] <SWPadnos> that's a biggie
[13:05:49] <SWPadnos> they have ballscrews as well, though the page is in ??? (no chinese fonts on this machine)
[13:06:01] <alex_joni> I do have fonts.. but still can't read it :D
[13:06:13] <alex_joni> http://www.cnsoyo.com/cp_5_2.asp
[13:06:18] <SWPadnos> right - the ??? are more accurate fo rme as well ;)
[13:06:30] <alex_joni> up to M130 :D
[13:06:38] <alex_joni> that's a HUGE screw
[13:06:43] <SWPadnos> what does that mean?
[13:06:52] <alex_joni> M = metric, 130mm diameter
[13:06:58] <SWPadnos> is that the diameter
[13:07:00] <SWPadnos> oh
[13:07:02] <SWPadnos> that is huge
[13:07:11] <alex_joni> 5"
[13:07:12] <SWPadnos> a person couldn' lift it
[13:07:15] <SWPadnos> couldn't
[13:07:45] <SWPadnos> the ballnut would weigh ~50 pounds, maybe more
[13:07:57] <SWPadnos> wait - more like 50 kg ;)
[13:08:10] <alex_joni> heh, I actually have seen some of those
[13:08:11] <alex_joni> :D
[13:08:15] <alex_joni> about 5-10m long
[13:08:22] <alex_joni> you have no idea how cool they are :D
[13:08:32] <SWPadnos> I can imagine
[13:08:36] <alex_joni> might have been only 100mm
[13:08:40] <alex_joni> diameter
[13:08:50] <alex_joni> but they were tilting a big table
[13:08:58] <alex_joni> about 20 tons of metal
[13:09:22] <SWPadnos> heh - or a dump truck
[13:09:31] <SWPadnos> though those are usually hydraulic
[13:09:33] <alex_joni> no, couple of robots on the table :D
[13:09:44] <alex_joni> it was used for positioning
[13:10:06] <alex_joni> so it was NC
[13:10:30] <SWPadnos> big
[14:57:53] <alex_joni> SWPLinux: can you paste in here?
[15:02:33] <SWPLinux> ok. ready. here's the output from dpkg:
[15:02:38] <SWPLinux> ii rtai-modules-2.6.12-magma 3.3-2+cjr12 rtai modules for Linux (kernel 2.6.12-magma)
[15:02:39] <SWPLinux> ii rtai-modules-2.6.15-magma 3.3-1+aj3 rtai modules for Linux (kernel 2.6.15-magma)
[15:02:47] <SWPLinux> so both are installed, interestingly enough
[15:02:55] <SWPLinux> (this was an upgrade from breezy)
[15:03:22] <alex_joni> ok, that sounds like a problem ;)
[15:03:44] <cradek> alex_joni: I bet you need a Replaces: or something
[15:03:54] <alex_joni> I should make rtai-modules-2.6.15-magma to replace or conflict
[15:03:56] <alex_joni> yeah chris
[15:04:02] <alex_joni> cradek: same for you though ;)
[15:04:16] <alex_joni> SWPLinux: apt-get remove the 12 one
[15:04:20] <alex_joni> * alex_joni goes to lunch
[15:04:20] <alex_joni> brb
[15:04:23] <SWPLinux> ok
[15:04:33] <cradek> SWPLinux: do you have both kernels installed?
[15:04:57] <SWPLinux> yep, they're both there
[15:05:20] <cradek> they shouldn't conflict - the realtime dir is named differently
[15:05:42] <SWPLinux> hmm - lemme look at that
[15:06:00] <SkunkworksD> I followed option 2 on the wiki
[15:06:06] <SWPLinux> yep
[15:06:11] <SkunkworksD> except -rHEAD
[15:06:27] <SkunkworksD> and everything looked good up to the make && sudo make setuid
[15:06:40] <SkunkworksD> (as far as I could tell
[15:06:42] <SkunkworksD> )
[15:06:44] <SWPLinux> I was able to compile just fine (except AXIS)
[15:06:49] <SWPLinux> I just can't run ;)
[15:06:57] <SkunkworksD> sam@sam-desktop:~/emc2/src$ make && sudo make setuid
[15:06:57] <SkunkworksD> Makefile:235: *** KDIR is not set and /lib/modules/2.6.15-magma/build is not a v alid kernel build location.. Stop.
[15:06:57] <SkunkworksD> sam@sam-desktop:~/emc2/src$
[15:07:18] <cradek> ouch
[15:07:34] <cradek> did you apt-get build-dep emc2?
[15:08:06] <skunkworks> sudo apt-get build-dep emc2
[15:08:17] <skunkworks> right of the wiki - 2nd option
[15:08:24] <skunkworks> remember this is dapper
[15:08:28] <cradek> crap, alex has another bug to fix then
[15:08:51] <cradek> I think the kernel install removes that symlink if the headers aren't installed yet
[15:09:11] <cradek> I remember fixing that
[15:09:24] <skunkworks> in your kernel for breezy?
[15:09:27] <cradek> yes
[15:09:44] <skunkworks> wasn't he supposed to use your template ;)
[15:09:56] <cradek> well it didn't quite work out that way
[15:10:00] <cradek> a lot is different.
[15:10:12] <skunkworks> I know - just a little ribbing
[15:10:20] <cradek> I understand
[15:11:08] <skunkworks> it isn't anything I could have done? I just followed the steps from the wiki - copy and pasting.
[15:11:27] <cradek> you're following the steps to build cvs?
[15:11:42] <cradek> do you need the cvs build or are you just testing?
[15:11:49] <skunkworks> 2 through 2.3 on the wiki
[15:12:16] <cradek> it's not your fault - like I said, I remember fixing this behavior
[15:12:22] <skunkworks> I was just testing - I can wait for a fix if thats what you mean
[15:12:51] <skunkworks> no rush - just trying it out - SWPadnos said he was having issues with it - thought I would try it
[15:12:53] <cradek> no I just wondered what you were up to, we need the testing
[15:13:11] <cradek> I haven't installed dapper yet (had some problems making the cd)
[15:13:40] <skunkworks> (wanted to have a way to play with HEAD)
[15:13:44] <skunkworks> and yes that sounds bad
[15:13:56] <skunkworks> been meaning to do it for a while.
[15:13:59] <SWPLinux> cradek - want to see an AXIS build problem?
[15:14:05] <cradek> sure
[15:14:09] <SWPLinux> ok:
[15:14:27] <SWPLinux> make -C /usr/src/linux-headers-2.6.15-magma SUBDIRS=`pwd` CC=gcc-3.4 V=0 -o /usr/src/linux-headers-2.6.15-magma/Module.symvers modules
[15:14:29] <SWPLinux> make[1]: Entering directory `/usr/src/linux-headers-2.6.15-magma'
[15:14:31] <SWPLinux> Building modules, stage 2.
[15:14:33] <SWPLinux> MODPOST
[15:14:35] <SWPLinux> make[1]: Leaving directory `/usr/src/linux-headers-2.6.15-magma'
[15:14:37] <SWPLinux> cp *.ko ../rtlib/
[15:14:38] <SWPLinux> cd axis && env EMCROOT=`cd ../.. && pwd` python setup.py -q install
[15:14:40] <SWPLinux> cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
[15:14:42] <SWPLinux> extensions/emcmodule.cc:21:19: error: GL/gl.h: No such file or directory
[15:14:44] <SWPLinux> extensions/emcmodule.cc: In function ‘PyObject* Logger_call(pyPositionLogger*, PyObject*)’:
[15:14:46] <SWPLinux> extensions/emcmodule.cc:1447: error: ‘GL_FLOAT’ was not declared in this scope
[15:14:48] <SWPLinux> extensions/emcmodule.cc:1448: error: ‘glVertexPointer’ was not declared in this scope
[15:14:50] <SWPLinux> extensions/emcmodule.cc:1449: error: ‘GL_UNSIGNED_BYTE’ was not declared in this scope
[15:14:52] <SWPLinux> extensions/emcmodule.cc:1450: error: ‘glColorPointer’ was not declared in this scope
[15:14:52] <cradek> ok
[15:14:53] <SWPLinux> extensions/emcmodule.cc:1451: error: ‘GL_COLOR_ARRAY’ was not declared in this scope
[15:14:55] <SWPLinux> extensions/emcmodule.cc:1451: error: ‘glEnableClientState’ was not declared in this scope
[15:14:57] <SWPLinux> extensions/emcmodule.cc:1452: error: ‘GL_VERTEX_ARRAY’ was not declared in this scope
[15:14:58] <SWPLinux> extensions/emcmodule.cc:1456: error: ‘GL_LINE_STRIP’ was not declared in this scope
[15:14:59] <SWPLinux> extensions/emcmodule.cc:1456: error: ‘glDrawArrays’ was not declared in this scope
[15:15:01] <SWPLinux> extensions/emcmodule.cc: At global scope:
[15:15:02] <SWPLinux> extensions/emcmodule.cc:547: warning: ‘void dict_add(PyObject*, char*, long int)’ defined but not used
[15:15:04] <SWPLinux> Building AXIS 1.4a0 for EMC2 in /Project/emc2
[15:15:05] <cradek> ok ok ok
[15:15:05] <SWPLinux> error: command 'gcc' failed with exit status 1
[15:15:07] <SWPLinux> make: *** [axis] Error 1
[15:15:09] <SWPLinux> heh
[15:15:16] <cradek> you don't have gl includes
[15:15:17] <SWPLinux> this is current CVS for both AXIS and emc2
[15:15:31] <cradek> did you apt-get build-dep emc2-axis?
[15:15:34] <SWPLinux> perhaps another build dependency?
[15:15:48] <SWPLinux> yep:
[15:15:56] <SWPLinux> 0 upgraded, 0 newly installed, 0 to remove and 8 not upgraded.
[15:16:00] <cradek> hmm
[15:16:12] <cradek> locate GL/gl.h
[15:16:31] <SWPLinux> nada
[15:17:01] <cradek> what are the build-deps for emc2-axis?
[15:17:19] <SWPLinux> I wonder if GL related stuff was removed when I upgraded to dapper - there was a list of packages that were removed (that I didn't memorize or save)
[15:17:22] <cradek> it also bothers me that it says CC=gcc-3.4
[15:17:29] <SWPLinux> duh - how do I find out?
[15:17:33] <cradek> that's not your kernel's compiler
[15:17:42] <cradek> apt-cache show emc2-axis I think
[15:17:46] <SWPLinux> ok
[15:17:56] <skunkworks> (I didn't upgrade from breezy - I did a fresh install)
[15:18:12] <SWPLinux> libglu1 or libglu1-mesa are in there
[15:18:31] <SWPLinux> Depends: python (>= 2.4), python (<< 2.5), emc2, python2.4, python (>= 2.4), python (<< 3), libc6 (>= 2.3.4-1), libgcc1 (>= 1:4.0.2), libgl1-mesa | libgl1, libglu1-mesa | libglu1, libstdc++6 (>= 4.0.2-4), libx11-6, libxmu6, tcl8.4 (>= 8.4.5), tk8.4 (>= 8.4.5), bwidget (>= 1.7), bwidget (<< 1.8), python2.4-tk
[15:18:42] <cradek> sorry it's showsrc
[15:18:47] <SWPLinux> oh
[15:18:48] <cradek> Build-Depends: debhelper (>= 4.1.67), emc2-dev, python2.4-dev, libgl1-mesa-dev,
[15:18:51] <cradek> libglu1-mesa-dev, libxmu-dev, tk8.4-dev
[15:19:13] <SWPLinux> Build-Depends: debhelper (>= 4.1.67), emc2-dev, python2.4-dev, libgl1-mesa-dev, libglu1-mesa-dev, libxmu-dev, tk8.4-dev, emc2, python2.4-tk
[15:19:20] <cradek> right
[15:19:31] <cradek> libgl1-mesa-surely dev should have those files
[15:19:35] <cradek> areerr
[15:19:40] <cradek> ack
[15:19:45] <SWPLinux> can you --reinstall with build-dep?
[15:19:49] <cradek> PLBBBTLBLTTH
[15:19:55] <cradek> I don't know
[15:20:04] <cradek> check to make sure you have libgl1-mesa-dev?
[15:20:08] <SWPLinux> having a Calvin & Hobbes moment? ;)
[15:20:18] <skunkworks> bill the cat
[15:20:22] <SWPLinux> heh
[15:20:26] <cradek> a 1 second lag + bad typing skills
[15:20:32] <SWPLinux> ah
[15:21:28] <SWPLinux> they're listed as installed, latest (6.4.1.0ubuntu8)
[15:21:32] <SWPLinux> I can reinstall them
[15:21:34] <cradek> chris@buster2:~$ apt-file search GL/gl.h
[15:21:35] <cradek> libgl1-mesa-dev: usr/include/GL/gl.h
[15:21:57] <cradek> (breezy)
[15:23:36] <SWPLinux> I reinstalled, and the files are there now. recompiling (after configure)
[15:23:52] <SWPLinux> nope
[15:24:36] <SWPLinux> maybe it's time for a fresh checkout, to eliminate build related issues
[15:27:36] <skunkworks> is this an issue between installing and upgrading ubuntu
[15:28:06] <skunkworks> as I did not get these errors?
[15:28:23] <SWPLinux> probably
[15:28:32] <SWPLinux> this is interesting: at the start of ./configure:
[15:28:50] <SWPLinux> configure: The following RT Signatures were found: /usr/realtime-2.6.12-magma/bin/rtai-config
[15:28:52] <SWPLinux> /usr/realtime-2.6.15-magma/bin/rtai-config
[15:28:54] <SWPLinux> Using /usr/realtime-2.6.12-magma/bin/rtai-config as the RT signature
[15:28:55] <SWPLinux> looks
[15:29:07] <SWPLinux> looks like I can fix it by configuring with --rtai= yadda yadda
[15:29:08] <jepler> libgl-mesa-1 doesn't seem to include GL/gl.h in dapper
[15:30:04] <jepler> dpkg-query -S /usr/include/GL/gl.h
[15:30:04] <jepler> mesa-common-dev: /usr/include/GL/gl.h
[15:30:52] <jepler> but mesa-common-dev was installed when I did 'apt-get install libglu1-mesa-dev' -- libgl-mesa-dev depends mesa-common-dev
[15:32:09] <jepler> so if you have libgl1-mesa-dev I don't see how you wouldn't have /usr/include/GL/gl.h
[15:32:12] <skunkworks> jepler: axis gets built when ./configure --enable-run-in-place is run - doesn't it?
[15:32:20] <SWPLinux> ok. I finally removed rtai2.6.12, and configure found the right RTAI
[15:32:39] <jepler> skunkworks: only if you've put a copy of it in ecm2/src
[15:32:52] <SWPLinux> jepler: I;m not sure how it happened, but it's likely that more stuff was removed during the upgrade than I would have liked
[15:33:30] <SWPLinux> I think anything in the universe / multiverse reopsitories was removed, because the upgrade defaults to maintained / restricted
[15:33:35] <skunkworks> jepler: cvs -z5 -d:ext:anon@cvs.linuxcnc.org:/cvs co -rHEAD emc2 - would this automatically get it?
[15:33:41] <SWPLinux> nop
[15:33:43] <SWPLinux> e
[15:34:29] <SWPLinux> ok. after reinstalling some mesa-dev packages (not all of them, probably), axis built just fine
[15:35:08] <SWPLinux> also, emc runs again, because I removed the older RTAI
[15:35:11] <SWPLinux> yay!
[15:35:26] <skunkworks> well crap - disregard my last statement
[15:35:48] <skunkworks> (s)
[15:36:04] <SWPLinux> skunkworks: that command gets the emc2 source, but axis is on a different server entirely
[15:36:34] <SWPLinux> if you have axis/ under the emc2/src directory (or linked there), it'll get built when you make emc2
[15:36:40] <skunkworks> I had thought I had heard it was part of the emc2 csv now. must have missundersttod
[15:37:29] <skunkworks> yah - I was just reading the wiki - did you run the make && sudo make setuid?
[15:37:32] <SWPLinux> nope. it should be (hint hint at jepler)
[15:37:32] <jepler> nope, it's still off in its own little world
[15:37:55] <SWPLinux> I have a short build script that does that for me, since I'm lazy
[15:38:14] <jepler> SWPLinux: it doesn't make sense to put it in the emc2 cvs when it supports emc1 and the version of emc on bdi4emc.
[15:38:35] <SWPLinux> no. but another module on cvs.linuxcnc.org would make sense
[15:38:58] <jepler> mmmaybe
[15:39:04] <SWPLinux> heh
[15:40:47] <jepler> why do you think it would be an improvement, rather than just a change?
[15:42:10] <jepler> back before I had anon access for axis, I could see it as an improvement. but there is anonymous access now (and has been for months)
[15:42:13] <jepler> it hardly gets used, fwiw
[15:42:54] <SWPLinux> I guess the real improvement would be for it to be included in the emc* checkouts, like tkemc and the other GUIs
[15:43:05] <skunkworks> ah - so I can't build yet (thought I had already built the package). didn't see the make at the begining of the line - duh
[15:43:15] <SWPLinux> but you're right - it's not much of an improvement to just stick it on linuxcnc
[15:43:33] <SWPLinux> can you check in changes with the anon cvs aqccess now?
[15:43:37] <SWPLinux> access
[15:43:58] <jepler> of course not -- it's read-only access
[15:44:13] <SWPLinux> oops. I was wrong before. I still get the same errors trying tro build AXIS. I probably need to reinstall more stuff
[15:44:23] <SWPLinux> well, that would be an improvement then
[15:45:19] <jepler> for all emc2 developers to be able to commit to axis?
[15:45:48] <SWPLinux> possibly
[15:46:09] <SWPLinux> of course, it could be a problem as well, but that is the idea behind open source and collaboration
[15:47:19] <SWPLinux> ok. it built now (after reinstalling everything mesa-related)
[15:47:30] <SWPLinux> there are a couple of warnings:
[15:47:49] <SWPLinux> cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
[15:47:50] <SWPLinux> extensions/emcmodule.cc:547: warning: ‘void dict_add(PyObject*, char*, long int)’ defined but not used
[15:47:52] <SWPLinux> extensions/seticon.c: In function ‘setname’:
[15:47:54] <SWPLinux> extensions/seticon.c:74: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘Atom’
[15:47:55] <SWPLinux> extensions/seticon.c:74: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘Atom’
[15:48:40] <SWPLinux> did you get a bunch of garbage there, or is that just Windows?
[15:48:54] <alex_joni> garbage, but only warnings
[15:48:59] <alex_joni> * alex_joni just came back
[15:49:12] <SWPLinux> cool. just in time - everything's working now ;)
[15:49:43] <alex_joni> great
[15:49:45] <skunkworks> the hell if it is :)
[15:49:52] <alex_joni> skunkworks: what's wrong?
[15:50:14] <skunkworks> oh - hold on - cradek pushed this off to you
[15:50:52] <skunkworks> Makefile:235: *** KDIR is not set and /lib/modules/2.6.15-magma/build is not a v alid kernel build location.. Stop.
[15:50:54] <skunkworks> :)
[15:51:18] <alex_joni> yup, I'll look into it, and build a new kernel deb
[15:51:25] <alex_joni> along with rtai & emc2 & axis
[15:51:30] <skunkworks> no rush - just playing
[15:51:32] <alex_joni> just what I missed doing :)
[15:51:43] <alex_joni> skunkworks: for now you can link it yourself
[15:52:12] <skunkworks> ok - I'll do that :)
[15:52:15] <skunkworks> * skunkworks wonders how
[15:52:17] <alex_joni> ln -s /lib/modules/2.6.15-magma/build /usr/src/linux-headers-2.6.15-magma
[15:52:19] <alex_joni> I think ;)
[15:52:19] <skunkworks> ah
[15:52:25] <alex_joni> might be the other way around
[15:52:30] <skunkworks> I will give it a whirl
[15:52:31] <alex_joni> but I always confuse them :D
[15:52:47] <alex_joni> man ln should help
[15:53:15] <alex_joni> SWPLinux: do you still have the 2.6.12-magma kernel installed?
[15:53:37] <SkunkworksD> sudo
[15:53:48] <cradek> it's the other way around
[15:53:52] <alex_joni> insufficient privileges
[15:54:04] <SkunkworksD> ah
[15:54:25] <alex_joni> SkunkworksD: like I said.. I ALWAYS confuse them
[15:54:38] <alex_joni> even when I try to write it backwards :D
[15:56:10] <SWPLinux> sorry - tow truck just came to bring the van to the shop
[15:56:24] <SWPLinux> no - I had to remove 2.6.12-magma
[15:56:40] <SWPLinux> I also had to reinstall all the mesa related packages to get AXIS to build
[15:57:11] <SWPLinux> I wonder if that has to do with my installing the ati flgrx package yesterday
[15:57:20] <SWPLinux> fglrx, that is
[15:57:27] <SkunkworksD> making - so far
[15:58:25] <jepler> SWPLinux: could be
[15:59:32] <SWPLinux> unfortunately, it doesn;'t seem to be accelerated - I probably have more config work to do
[16:00:00] <SWPLinux> I think a Radeon 8500DV should be able to do more than ~100 fps in glxgears (and fgl_glxgears doesn't run)
[16:17:25] <alex_joni> skunkworks: problems?
[16:18:48] <SkunkworksD> other than locking up - tkemc ran
[16:19:16] <SkunkworksD> other than locking up and rebooting - then sim tkemc ran
[16:19:21] <SkunkworksD> but axis does not
[16:19:47] <SkunkworksD> Can't execute DISPLAY program /home/sam/emc2/bin/axis
[16:20:20] <alex_joni> is it there?
[16:21:10] <SkunkworksD> no
[16:22:59] <SkunkworksD> I untared the axis package and copied it into the scr directory
[16:23:13] <SkunkworksD> can I just build axis and see what happens?
[16:23:18] <jepler> you have to re-run configure for the directory to be noticed
[16:23:43] <SkunkworksD> hmm - ok - then make again?
[16:24:09] <jepler> yes (but no need to 'clean' or anything)
[16:27:12] <alex_joni> SkunkworksD: don't forget --enable-run-in-place
[16:28:20] <skunkworks> right - I coppied it right from the wiki
[16:28:25] <skunkworks> sam issue with axis though
[16:28:28] <skunkworks> same
[16:28:57] <skunkworks> did I copy axis wrong into the src directory - how can I tell
[16:32:25] <skunkworks> or is this the same issue SWPadnos was haveing?
[16:32:41] <SWPLinux> not the same issue
[16:32:44] <alex_joni> skunkworks: not the issue SWPadnos had
[16:32:51] <SWPLinux> I have a link to axis/ in the src directory
[16:33:03] <alex_joni> skunkworks: can you pastebin the output from ./configure --enable-run-in-place ?
[16:33:14] <skunkworks> sure
[16:36:06] <SkunkworksD> http://pastebin.com/770309
[16:36:38] <SkunkworksD> not found - I must have coppied it wrong into the scr
[16:36:45] <SkunkworksD> src directory
[16:37:08] <alex_joni> checking for AXIS source... Not found
[16:37:48] <SkunkworksD> just the untared directory into it - or do I copy the contents of the untared directory?
[16:38:01] <alex_joni> sorry?
[16:38:20] <SkunkworksD> thought that would not make sense
[16:39:25] <SkunkworksD> I downloaded the axis packege to the desktop - untared it there and it made a directory called axis-1.3a2
[16:39:49] <SkunkworksD> do I put the folder into the src directory or the contents of it
[16:39:58] <alex_joni> the whole dir
[16:40:06] <alex_joni> but rename it to axis
[16:43:01] <SkunkworksD> well heck - I didn't know that :)
[16:44:01] <alex_joni> * alex_joni is just guessing
[16:45:01] <SkunkworksD> well it found it - but 'now' I think I am having swp's problem
[16:45:25] <SkunkworksD> * SkunkworksD whats to have swp problem I guess
[16:47:07] <SkunkworksD> http://pastebin.com/770335
[16:47:57] <alex_joni> looks ok to me..
[16:48:03] <alex_joni> did you run make?
[16:48:44] <SkunkworksD> http://pastebin.com/770338
[16:50:08] <alex_joni> looks ok !?
[16:50:50] <skunkworks> really
[16:51:02] <alex_joni> it does to me..
[16:52:09] <SkunkworksD> maybe and issue with the axis version I used with head?
[16:52:12] <SkunkworksD> EMC2 - Prerelease CVS HEAD
[16:52:12] <SkunkworksD> Machine configuration directory is '/home/sam/emc2/configs/sim/'
[16:52:12] <SkunkworksD> Machine configuration file is 'axis.ini'
[16:52:12] <SkunkworksD> Starting emc...
[16:52:12] <SkunkworksD> Traceback (most recent call last):
[16:52:12] <SkunkworksD> File "/home/sam/emc2/bin/axis", line 61, in ?
[16:52:14] <SkunkworksD> import gcode
[16:52:16] <SkunkworksD> ImportError: /home/sam/emc2/lib/librs274.so: undefined symbol: _Z18STOP_ADAPTIVE_FEEDv
[16:52:18] <SkunkworksD> Shutting down and cleaning up EMC...
[16:52:20] <SkunkworksD> Cleanup done
[16:52:28] <alex_joni> probably so
[16:52:32] <alex_joni> get the latest AXIS
[16:52:37] <alex_joni> downloads/nightly
[16:52:45] <skunkworks> hmm
[16:53:06] <skunkworks> thought I did
[16:53:06] <alex_joni> http://axis.unpy.net/downloads/nightly
[16:56:09] <skunkworks> yah
[16:56:12] <skunkworks> that works
[16:56:32] <skunkworks> I don't know what I'm doing - but it hasn't stopped me before :)
[16:56:38] <alex_joni> 1.3a2 should work with 2.0.0 and 2.0.1
[16:57:06] <skunkworks> I just grabbed the latest from the site - not the nightly tarball
[16:58:07] <skunkworks> Thanks - now lets see if the installed 2.0.1 still works :)
[16:59:14] <skunkworks> seems to work also - Life is good - love live emc
[16:59:26] <skunkworks> oops
[16:59:31] <skunkworks> I mean long live emc
[16:59:57] <alex_joni> skunkworks: just make sure you won't mix configs & such
[17:00:05] <alex_joni> I noticed it leads to trouble sometimes..
[17:03:35] <skunkworks> no problem - I have no configs setup for the 2.0.1 yet :)
[17:04:25] <alex_joni> I meant the ones in /etc/emc2