Back
[09:13:20] <seb_kuzminsky> ju-emb: are you Juergen Gnoss on the mailing list?
[09:13:41] <ju-emb> that's right
[09:13:42] <seb_kuzminsky> i gave you bad instructions yesterday
[09:13:44] <ju-emb> hi seb
[09:13:56] <seb_kuzminsky> the kernel debs are on w.l.o, but the linuxcnc debs are on the buildbot
[09:14:05] <seb_kuzminsky> deb
http://buildbot.linuxcnc.org precise master-rt
[09:14:11] <seb_kuzminsky> (unsigned, unfortunately)
[09:14:31] <ju-emb> ok I'll change that
[09:15:20] <ju-emb> the kernel from the first instruction panics on my machine
[09:15:44] <ju-emb> still trying to figure out what's happening
[09:16:51] <ju-emb> Kernel panics and say's he cannot access rootfs of sda3
[09:19:25] <cradek> it seems really broken that the rtai kernel doesn't use an initrd. it seems like lots of hardware is going to fail because of that.
[09:20:53] <ju-emb> what motherboards do you use?
[09:21:42] <cradek> I use free junkbox stuff
[09:22:13] <cradek> currently free junkbox boards are P4 era, and they usually work fine
[09:22:29] <cradek> I have a strong aversion to buying anything new :-)
[09:22:29] <ju-emb> but what's the minimal CPU
[09:22:57] <ju-emb> I have a lot of that junk around here
[09:23:11] <cradek> I still find the faster P3 chips quite usable for everything but development (lots of compiling)
[09:23:29] <cradek> people have different standards - so the question is hard to answer
[09:24:13] <ju-emb> for compiling I use a cluster, so no hard feelings
[09:25:08] <cradek> heck people are using things like the beagles now, which seem about as capable as good mid-90s PCs
[09:25:24] <cradek> they spend a lot of time managing expectations, though
[09:25:30] <ju-emb> last night after the kernel panics, I got to bed but started compiling the kernel on the same machine with i core
[09:25:58] <ju-emb> still compiling
[09:27:04] <ju-emb> the kernel for the beaglebone or pandaboard compiled on the cluster with 2000 cores takes a couple of minutes
[09:30:08] <ju-emb> cradek: I'm not right into the RTAI , what's the hard part of the RTAI compared to the others?
[09:31:44] <seb_kuzminsky> ju-emb: what hardware connects your sda on that machine? is it sata?
[09:31:49] <seb_kuzminsky> oops, bbl, work
[09:32:14] <ju-emb> ATA at that machine
[09:32:46] <cradek> the normal ubuntu kernel boots fine, I assume?
[09:33:00] <ju-emb> that's right
[09:34:58] <ju-emb> the machine has SATA connectors, but HDD is connected with ribbon cable
[09:37:11] <ju-emb> the other machine that was planned to use in that test, stopped working yesterday, I have to change some Cap's in the PSU
[09:37:14] <cradek> I suspect all scsi systems are broken too
[09:38:42] <cradek> if this kernel is made with make-kpkg the fix might (might) be as easy as adding --initrd
[10:09:59] <seb_kuzminsky> cradek: i'll try that
[10:42:27] <mozmck> cradek: I think memleak does not link initrd and didn't he do a lot/most of the work on the new rtai stuff?
[10:42:51] <mozmck> s/link/like
[10:43:15] <ju-emb> seb : the repo
[10:43:17] <ju-emb> deb
http://buildbot.linuxcnc.org precise master-rt
[10:43:34] <ju-emb> is there a repo deb-src as well?
[10:49:34] <cradek> mozmck: I hate to comment on another's feelings, but initrd is positively the linux/debian/ubuntu way to load drivers early enough to boot with, and I suspect trying to go without it will cause suffering
[10:50:07] <memleak> i dont do any .deb packaging, seb does all that
[10:50:26] <mozmck> I don't know enough about it, but I thought remembered memleak saying something like that.
[10:50:46] <memleak> but all the RTAI code i work on.. well.. previously did
[10:50:58] <mozmck> there he is! do you not like initrd? why?
[10:51:11] <cradek> ah ok
[10:51:17] <cradek> I bet seb will fix it then :-)
[10:51:34] <memleak> i dont use initrds because i just have the kernel do its thing
[10:52:49] <cradek> initrd isn't usually needed if you build a kernel special for one machine
[10:53:14] <cradek> and you don't need weirdness like dkms (needed for nvidia etc)
[10:54:07] <memleak> thats exactly what i do. increases performance and decreases the amount of bugs
[10:54:58] <seb_kuzminsky> ju-emb: yes
[10:55:37] <memleak> RTAI likes small kernels anyway
[10:56:52] <ju-emb> ok thank's.
[10:56:54] <ju-emb> after my machine has finished downloading a 3GB file
[10:56:56] <ju-emb> I'll try both repos
[10:57:24] <memleak> but yeah after i rewrote and forked the RTAI tree and brought everything up to speed i just stopped working on RTAI
[10:57:45] <memleak> figured bringing the whole project back to life was enough for now
[11:02:05] <memleak> made me feel good about myself too :)
[11:03:12] <ju-emb> memleak: we're glad to have you working on that
[11:03:58] <ju-emb> I wish I had more time for all that nice stuff
[11:04:59] <memleak> it's not that i don't have time now, but just working on RTAI for so long trying to clean up the mess really took the life out of me
[11:05:23] <memleak> if i didn't mind i'd still be working on it (or was being paid to do it)
[11:07:28] <memleak> thanks ju-emb i appreciate it
[11:12:19] <ju-emb> is there plans to have a commercial supported version of LCNC in the future?
[11:14:22] <memleak> not that i know of nor could i imagine one
[11:15:14] <ju-emb> seb? cradek?
[11:15:43] <ju-emb> I think it will be good to have it
[11:16:19] <memleak> i dont see anything wrong with it as long as there will always be a non-commercial version for general use
[11:16:21] <cradek> I have no idea what that means
[11:16:38] <cradek> I don't plan to form a company to give linuxcnc support, if that's what you're asking me
[11:16:57] <cradek> of course you can, if you want
[11:18:14] <memleak> i think he means to pay developer(s) to add support or do certain things to the tree upon payment, such as special purpose things that wouldn't be practical for the public tree
[11:18:15] <ju-emb> I'm thinking of all that work and time you guys spent on that
[11:18:52] <cradek> I've done contract work like that. I'm sure many others have too.
[11:19:22] <cradek> and if anyone ever wants to give me money for past work I've done for free, I'd consider taking it from them.
[11:19:29] <ju-emb> memleak is right, but it could go into the public tree, because customers pay the time of the developers
[11:20:20] <cradek> some of the code we have was written for pay, and then given to everyone. it's often a very wise thing for someone with money to do.
[11:20:38] <cradek> a smart hardware manufacturer might sure choose to do this, for instance
[11:21:27] <ju-emb> I do such things too, on the hardware front
[11:21:44] <memleak> well there you go! pay cradek :D
[11:21:51] <ju-emb> we design electronics
[11:31:01] <ju-emb> on the devel mailing list you find my e-mail address.
[11:31:02] <ju-emb> so you guys can drop me an e-mail, for the case I've coding work to do and need specialists
[11:35:29] <archivist> we should have a wiki page explaining who can do what for moneyz and where we are
[11:37:25] <ju-emb> I appreciate this
[11:39:08] <archivist> anything from the make it workforme to makeitdoanything
[11:41:01] <ju-emb> It can work like a ticket system
[11:41:34] <ju-emb> funds going direct to Linuxcnc
[11:41:48] <archivist> well sometimes one needs to be local to the user and do real work
[11:42:04] <archivist> one needs to eat
[11:42:12] <ju-emb> that for sure
[11:46:00] <ju-emb> s..t !
[11:46:01] <ju-emb> LD [M] drivers/staging/frontier/tranzport.ko
[11:46:03] <ju-emb> and machine hang's
[12:16:58] <cradek> there is no "linuxcnc" to pay. if you hire someone to do work for you, that is an agreement with that person
[12:20:55] <archivist> and at the moment any of us providing any serving function is currently doing so gratis
[12:21:20] <cradek> yes, I am
[12:21:59] <cradek> and at least two others are
[13:29:08] <ju-emb> Warning: mopost: Found 24 section mismatch(es)
[13:31:39] <memleak> modpost module mismatches you can safely ignore
[13:33:33] <memleak> ive had around 120 once
[13:35:33] <ju-emb> I try to find out why he doesn't build the .deb
[13:35:54] <ju-emb> compiling the kernel and modules is OK
[14:02:15] <ju-emb> does Linuxcnc make use of comedi stuff?
[14:03:11] <memleak> not that i know of
[14:03:39] <ju-emb> that is where the error in my build comes from
[14:09:14] <memleak> is comedi the one that uses scilab?
[14:09:22] <memleak> if so you can turn off comedi in RTAI
[14:10:17] <memleak> linuxcnc doesnt use comedi at all though, it only uses the core parts of it
[14:10:34] <memleak> it meaning RTAI
[14:10:52] <ju-emb> google say's it is a control and measurement interface
[14:11:10] <memleak> just turn it off
[14:11:19] <ju-emb> OK
[14:15:43] <ju-emb> poor seb, he does that all day long
[14:21:17] <seb_kuzminsky> cradek: i added --initrd like you suggested and now the deb makes an initrd
[14:21:30] <seb_kuzminsky> i'll push an updated kernel package to w.l.o tonight
[14:22:20] <cradek> slick
[14:22:27] <cradek> it would be nice to know if that fixes ju-emb's boot
[14:24:59] <seb_kuzminsky> yeah i'm copying it to highlab now
[14:25:58] <ju-emb> so I can get it by just updating ?
[14:30:30] <seb_kuzminsky> not yet
[14:30:57] <jepler> seb_kuzminsky: did you see the question earlier about whether there's a deb-src? Is it in the expected location (i.e., just change deb to deb-src)?
[14:31:04] <ju-emb> yes sure, if you give me a sign
[14:31:26] <ju-emb> yes he did answer that with yes
[14:31:33] <jepler> oh ok, I missed the answer
[14:31:34] <jepler> good
[14:36:53] <ju-emb> on my build I forgot to put --revision how do I know that I've build an RTAI kernel?
[14:38:01] <seb_kuzminsky> ju-emb:
http://highlab.com/~seb/linuxcnc/rtai-for-3.4-prerelease/
[14:38:13] <seb_kuzminsky> fetch the -rtai-2 debs, install, reboot, see if it works
[14:38:14] <cradek> seb_kuzminsky: is that the only change you made?
[14:38:17] <seb_kuzminsky> yes
[14:38:23] <cradek> nice, thanks for doing it
[14:38:28] <cradek> I hope my advice was worth something
[14:38:42] <seb_kuzminsky> the rtai-modules are packaged poorly, so you have to uninstall the old rtai-modules before you can install the new ones
[14:39:06] <ju-emb> OK
[14:39:14] <seb_kuzminsky> cradek: your advise made the linux-image maintain an initrd, which is certainly better than before, i hope it also fixes ju-emb 's booting problem
[14:39:15] <ju-emb> Thank's Seb
[14:39:23] <seb_kuzminsky> yep! thanks for testing :-)
[14:39:27] <seb_kuzminsky> bbl
[15:01:35] <seb_kuzminsky> wow, robert ellenberg gets git, that's awesome
[15:05:13] <skunkworks> He seems very smart.
[15:06:24] <skunkworks> it didn't take him long to get to a working x depth TC
[15:06:39] <skunkworks> heh TP
[15:09:09] <skunkworks> for line segmets - and falls back to parabolic blends for things not handled yet
[15:09:28] <skunkworks> he might be my new man crush
[15:09:34] <cradek> awww I thought I was.
[15:09:38] <cradek> darnit.
[15:09:41] <skunkworks> heh
[15:09:59] <skunkworks> you will always have a special place
[15:09:59] <cradek> I'm probably getting a little old for you.
[15:10:47] <skunkworks> I do look for arm candy...
[15:12:11] <seb_kuzminsky> haha
[15:12:30] <cradek> well SOME people LIKE grey hair.
[15:17:29] <skunkworks> long distance relationships never work....
[15:21:29] <seb_kuzminsky> there's some kind of joke in there about long distances working better if you can traverse the path between the endpoints more quickly...
[15:24:12] <PCW> TP question? does the TP provide a velocity pin?
[15:24:24] <cradek> current-velocity?
[15:24:53] <PCW> Yes
[15:25:16] <PCW> forward difference
[15:26:38] <PCW> I was messing about with the hardware stepgen and found that I could do better with a simple P+FF1 PID loop than the driver code
[15:27:14] <cradek> 21 float OUT 0 motion.current-vel
[15:27:18] <cradek> 21 float OUT 0 motion.requested-vel
[15:27:54] <cradek> so yeah (would have to try it if you need it to work in all modes - not sure about that)
[15:28:21] <PCW> OK that would be better to hook in to the FF1 than the PID comps difference
[15:28:42] <PCW> (since its a cycle late)
[15:29:44] <PCW> it will be pretty obvious if its not right in some modes (instant following error)
[15:29:56] <cradek> should we make pid.error-previous-target the default in master?
[15:30:16] <PCW> I had to use that for the Steppper PID to work
[15:30:23] <cradek> PCW: you're going to hook it to pid.command-deriv?
[15:30:36] <PCW> Yes
[15:30:55] <cradek> cool, that might just work
[15:31:08] <PCW> well this is just to model a replacement of the current driver stepgen code
[15:31:58] <PCW> but its already about 2-3 times as good at dealing with lousy latency
[15:32:40] <PCW> (trust the hardware for short term timing and linuxCNC for long term)
[15:37:17] <PCW> (the current driver code is way too picky about latency, it should live with a few hundred uSec without serious problems)
[15:40:41] <cradek> it would be great if you could fix that
[15:41:36] <PCW> Yeah its pretty far from optimal
[15:42:15] <PCW> (and especially noticeable on Ethernet where the jitter is worse)
[15:44:24] <PCW> I can paper over the issue by using the DPLL to sample the stepgen position (I may do this anyway)
[15:44:25] <PCW> but the current stepgen driver behavior with any significant jitter is bad
[15:45:20] <PCW> (I should say this is only the Mesa hardware stepgen I have no knowledge of other drivers characteristics)
[16:39:33] <ju-emb> seb & cradek: here comes your flowers
[16:39:49] <seb_kuzminsky> haha
[16:39:57] <seb_kuzminsky> i think that means it boots now?
[16:40:01] <ju-emb> Linux lcnc01 3.4.55-rtai-2 #1 SMP PREEMPT Fri Dec 13 10:53:29 MST 2013 i686 athlon i386 GNU/Linux
[16:40:07] <seb_kuzminsky> aww yea!!
[16:41:18] <seb_kuzminsky> that's great! I'll put the new rtai kernel debs on w.l.o this weekend, and mail out a howto to the users list for trying it out
[16:41:19] <ju-emb> that's great: Thank you guys:
[16:41:21] <ju-emb> let's build lcnc on it
[16:41:21] <seb_kuzminsky> thanks for testing
[16:41:52] <ju-emb> thanks to you guys
[17:02:49] <ju-emb> seb: do you recommend try 2.6 on top of that new kernel?
[17:04:13] <ju-emb> 2.6 is git or exists as deb too?
[17:09:48] <seb_kuzminsky> there is no 2.6 yet
[17:10:00] <seb_kuzminsky> there is 2.5 and master
[17:10:17] <seb_kuzminsky> master is also called "2.6~pre", and will become 2.6 at some point in the future
[17:10:24] <seb_kuzminsky> both should work for you
[17:10:29] <seb_kuzminsky> both are available as debs from the buildbot
[17:10:46] <seb_kuzminsky> neither is available in the debian archive at w.l.o yet
[17:12:35] <ju-emb> sorry for the wrong expression 2.6~pre, that's what I meant.
[17:13:00] <ju-emb> so I go for that
[17:13:06] <seb_kuzminsky> great!
[17:13:28] <seb_kuzminsky> master (2.6~pre) on rtai on precise is what i run on my bridgeport, no problems so far (fingers crossed)
[17:14:27] <seb_kuzminsky> hmm, "fingers crossed" can mean both "i'm hoping for good luck" and "i'm lying"... i meant that i'm hoping the good stability continues
[17:18:51] <ju-emb> is that what I have to get ?
[17:18:53] <ju-emb> deb
http://buildbot.linuxcnc.org/ precise scratch-rt
[17:18:55] <ju-emb> deb-src
http://buildbot.linuxcnc.org/ precise scratch-rt
[17:19:07] <seb_kuzminsky> scratch is all experimental branches
[17:19:14] <seb_kuzminsky> you want master-rt or v2.5_branch-rt probably
[17:19:37] <ju-emb> so replace scratch-rt with master-rt
[17:19:41] <seb_kuzminsky> exactly
[17:19:46] <ju-emb> ok
[17:21:53] <seb_kuzminsky> ju-emb: that looks good
[17:22:21] <ju-emb> do you see what I'm doing there?
[17:22:56] <seb_kuzminsky> i'm watching the webserver logs
[17:24:15] <ju-emb> WARNING: The following packages cannot be authenticated!
[17:24:17] <ju-emb> linuxcnc linuxcnc-doc-en
[17:24:19] <ju-emb> Install thesWARNING: The following packages cannot be authenticated!
[17:24:21] <ju-emb> linuxcnc linuxcnc-doc-en
[17:24:23] <ju-emb> Install these packages without verification [y/N]? ye packages without verification [y/N]? y
[17:24:29] <ju-emb> sorry was double pasted
[17:25:02] <seb_kuzminsky> yes, the buildbot does not sign its deb archive correctly :-(
[17:26:49] <seb_kuzminsky> the real packages at www.linuxcnc.org are signed correctly, but not the buildbot ones
[17:28:53] <ju-emb> install perfect,
[17:28:56] <ju-emb> starting lcnc say's I've to run kernel 3.4.55-rtai-1
[17:33:29] <ju-emb> on install I see a line that say's:
[17:33:32] <ju-emb> Setting up rtai-modules-3.4.55-rtai-1 (3.9-shabby-memleak-2013.08.05) ...
[17:33:41] <ju-emb> is that critical?
[17:34:03] <seb_kuzminsky> yes that's not right :-/
[17:34:43] <seb_kuzminsky> you can grab the new rtai-modules-3.4.55-rtai-2 package from the same place where you got the new rtai-2 linux-image debs
[17:35:30] <seb_kuzminsky> but even so, the debs from the buildbot have a dependency on the -rtai-1 kernel, which is overly restrictive
[17:36:06] <seb_kuzminsky> we probably should figure out a better way for linuxcnc.deb to depend on linux-image.deb
[17:38:22] <seb_kuzminsky> once i put the new linux-image.deb and rtai-modules.deb in the deb archive at w.l.o i can update the buildbot, and then any debs it builds will run on the new -rtai-2 kernel (but not on the old -rtai-1 kernel)
[17:38:41] <seb_kuzminsky> this is obviously overly restrictive
[17:40:06] <seb_kuzminsky> for rtai builds we've always had explicit dependencies on a specific kernel version, and we've updated our kernels seldom enough that it was never painful
[17:40:08] <ju-emb> here you can go over results of install process if you need it:
[17:40:11] <ju-emb> http://pastebin.com/wNKjLU3b
[17:42:45] <ju-emb> So I wait for the new deb's before going on?
[17:42:48] <ju-emb> or can I try a git repo, help finding what need to be changed
[17:44:06] <ju-emb> tell me what you need me to do, if I should wait, no hard feelings
[17:44:52] <seb_kuzminsky> ok, what happened there was you installed the linuxcnc deb from the buildbot, and it has a dependency on the previous version of the rtai kernel, so it installed that
[17:45:23] <seb_kuzminsky> it also looks like you didnt install the new version of rtai-modules, since linuxcnc.deb successfully installed the old version
[17:45:31] <seb_kuzminsky> try this:
[17:46:05] <seb_kuzminsky> dpkg --purge linux-image-3.4.55-rtai-1 rtai-modules-3.4.55-rtai-1
[17:46:13] <seb_kuzminsky> apt-get install rtai-modules-2.4.55-rtai-2
[17:46:19] <seb_kuzminsky> oops, 3.4.55
[17:46:20] <ju-emb> yes that's true, I was a bit confused with the modules
[17:46:41] <seb_kuzminsky> then build from git on that machine
[17:46:43] <seb_kuzminsky> that should work
[17:48:38] <ju-emb> looks like I have to deinstall linuxcnc first before ermoving the kernel stuff
[17:49:09] <ju-emb> remove or purge for linuxcnc?
[17:50:34] <ju-emb> remove did it
[17:51:08] <seb_kuzminsky> either should be fine
[17:51:57] <seb_kuzminsky> oh, also, if this is a fresh machine that's never run linuxcnc before, don't forget to bump up the memlock limit:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?LockedMemory
[17:56:50] <ju-emb> what git repo should I clone for that?
[17:57:28] <seb_kuzminsky> the standard linuxcnc one:
[17:57:54] <seb_kuzminsky> git clone
http://git.linuxcnc.org/git/linuxcnc.git linuxcnc-dev
[18:09:11] <ju-emb> configure is looking for the rtai-1
[18:10:05] <ju-emb> at least for the linux-headers-3.4.55-rtai-1
[18:10:09] <seb_kuzminsky> aha
[18:10:24] <seb_kuzminsky> install linux-headers-3.4.55-rtai-2
[18:11:54] <ju-emb> checking /usr/src/linux-headers-3.4.55-rtai-1/include/linux/version.h usability... no
[18:11:56] <ju-emb> checking /usr/src/linux-headers-3.4.55-rtai-1/include/linux/version.h presence... no
[18:11:58] <ju-emb> checking for /usr/src/linux-headers-3.4.55-rtai-1/include/linux/version.h... no
[18:12:00] <ju-emb> configure: error: version.h not found - Is the kernel headers package installed ?
[18:12:22] <seb_kuzminsky> what's "uname -r" say?
[18:12:51] <ju-emb> 3.4.55-rtai-2
[18:12:54] <ju-emb> as expected
[18:13:53] <seb_kuzminsky> hmm
[18:14:04] <seb_kuzminsky> dpkg --remove linux-headers-3.4.55-rtai-1
[18:14:13] <seb_kuzminsky> maybe it's not expecting to find multiple realtime headers
[18:14:35] <ju-emb> dpkg: warning: there's no installed package matching linux-headers-3.4.55-rtai-1
[18:15:29] <seb_kuzminsky> do you have the new rtai-2 headers installed?
[18:15:38] <ju-emb> yes
[18:15:44] <seb_kuzminsky> hmm
[18:16:20] <ju-emb> jgnoss@lcnc01:/home/seb$ sudo dpkg -i linux-headers-3.4.55-rtai-2_2_i386.deb
[18:16:23] <ju-emb> Selecting previously unselected package linux-headers-3.4.55-rtai-2.
[18:16:25] <ju-emb> (Reading database ... 169482 files and directories currently installed.)
[18:16:27] <ju-emb> Unpacking linux-headers-3.4.55-rtai-2 (from linux-headers-3.4.55-rtai-2_2_i386.deb) ...
[18:16:29] <ju-emb> Setting up linux-headers-3.4.55-rtai-2 (2) ...
[18:16:31] <ju-emb> Examining /etc/kernel/header_postinst.d.
[18:17:04] <seb_kuzminsky> what rtai-modules do you have? i bet the rtai-1 ones
[18:17:33] <seb_kuzminsky> dpkg -l 'rtai-modules*'
[18:18:19] <ju-emb> Desired=Unknown/Install/Remove/Purge/Hold
[18:18:21] <ju-emb> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
[18:18:23] <ju-emb> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
[18:18:25] <ju-emb> ||/ Name Version Description
[18:18:27] <ju-emb> +++-===================-===================-======================================================
[18:18:29] <ju-emb> un rtai-modules-3.4.55 <none> (no description available)
[18:18:31] <ju-emb> ii rtai-modules-3.4.55 3.9-shabby-memleak- Real Time modules for linux-image-3.4.55-rtai-2
[18:18:45] <seb_kuzminsky> hmm, that looks right too
[18:23:21] <ju-emb> I checked, that there isn't anything installed related to the rtai-1
[18:24:37] <seb_kuzminsky> what do you get from 'ls -d /usr/realtime*'?
[18:25:51] <ju-emb> /usr/realtime-3.4.55-rtai-1
[18:26:03] <seb_kuzminsky> ok, that's the problem
[18:26:45] <seb_kuzminsky> it's a bug in my new rtai-modules package
[18:27:30] <ju-emb> is it enough to rename it?
[18:28:41] <seb_kuzminsky> dont do that, it'll confuse the packaging system
[18:28:45] <seb_kuzminsky> i'm rebuilding the debian package now
[18:28:56] <ju-emb> OK
[18:29:59] <ju-emb> It's nice to be here working with you guys
[18:30:15] <seb_kuzminsky> re-fetch the rtai-modules...rtai-2 deb
[18:30:23] <seb_kuzminsky> dpkg --remove and dpkg --install it
[18:30:28] <seb_kuzminsky> then configure might work, maybe?
[18:30:32] <ju-emb> ok
[18:31:27] <seb_kuzminsky> bbl
[18:43:06] <seb_kuzminsky> ok, i'm back, for a bit
[18:48:49] <ju-emb> resolving missing packages
[18:48:51] <ju-emb> do you know what GTK package to install
[18:49:12] <ju-emb> GTK2 missing
[18:50:08] <ju-emb> I make notes what packages I have to install in addition to a virgin ubuntu install
[18:50:32] <seb_kuzminsky> ju-emb: that should be already known
[18:50:39] <seb_kuzminsky> you can ask what you need this way:
[18:51:07] <seb_kuzminsky> cd debian; ./configure -a; cd ..; dpkg-checkbuilddeps
[18:51:33] <ju-emb> yeahh I forgot about that
[18:51:52] <seb_kuzminsky> easier than finding them one by one ;-)
[18:51:55] <ju-emb> I did that before
[18:54:02] <ju-emb> just as note:
[18:54:05] <ju-emb> ./configure -a
[18:54:07] <ju-emb> your kernel '3.4.55-rtai-2' is not known. There might be needed dependencies which won't get set automatically.
[18:54:09] <ju-emb> successfully configured for 'Ubuntu-12.04'-'3.4.55-rtai-2'..
[18:54:49] <seb_kuzminsky> yeah, that's sketchy-sounding but ok
[18:58:11] <ju-emb> installing missing packages ...
[18:59:56] <seb_kuzminsky> bbl
[19:21:20] <ju-emb> building lcnc ...
[19:38:04] <seb_kuzminsky> great!
[20:00:35] <ju-emb> congrat's to seb:
[20:00:38] <ju-emb> http://imagebin.org/282209
[20:42:38] <seb_kuzminsky> great!
[20:43:05] <seb_kuzminsky> but really memleak and shabby did all the heavy lifting :-)
[20:49:49] <brianmorel> Is there any documentation for compiling / building on a remote system (not the system it will be installed on)?
[21:11:45] <seb_kuzminsky> if the distro & binary arch is the same, you just build like usual
[21:12:21] <seb_kuzminsky> if tjey differ you need to build in a chroot or a virtual machine, or otherwise cross-compile
[21:12:47] <seb_kuzminsky> i dont think we have any real docs on these techniques
[21:17:23] <brianmorel> Ya, i'm trying to build it in my VM that I used to build the RTAI kernel. Right now I'm stuck because the configure script can't find version.h