Back
[17:49:15] <andypugh> Would one expect to be able to compile a 2.5~pre on the Mozmck packages?
[17:49:30] <andypugh> "make" is failing with:
[17:49:40] <andypugh> usr/realtime-2.6.32-22-rtai/include/asm/rtai_hal.h:924: error: invalid type argument of ‘unary *’ (have ‘int’)
[17:50:08] <andypugh> I am wondering if there is an important step that I have missed out.
[17:51:12] <jthornton> I'm on 10.04 but have not set up a RIP yet
[17:51:34] <andypugh> 'make' goes fine up to a point:
http://www.pastebin.ca/1908124
[17:53:23] <jthornton> sorry Greek to me...
[17:54:01] <jthornton> I just switched from the quad core to this one so everything is brand new again :/
[17:54:44] <andypugh> Yes, I have the same issue.
[17:55:40] <andypugh> I could wander out to the garage and turn on the other EMC machine to try out with, but the one that is in the same room just seems more sensible.
[17:58:30] <jthornton> I reckon I better git started or just go take a nap
[18:12:06] <andypugh> Why is "make" in the EMC2 src directory compiling (or, more specifically, failing to compile) files that are in usr/realtime.....
[18:20:05] <jepler> andypugh: #include uses files from those directories. If this is 10.04, it's probably the kernel headers package problem.
[18:20:30] <jepler> andypugh: basically an update from ubuntu will overwrite one of the packages from mozmck, and then nothing using realtime will compile anyway
[18:20:33] <jepler> anymore
[18:20:53] <andypugh> I don't think I have updated, but perhaps I did
[18:21:14] <andypugh> Woulf reinstalling the mozmck headers.deb fix it?
[18:21:41] <jepler> yes, I think specifically it's this one:
http://linuxcnc.org/mozmck/linux-headers-2.6.32-22_2.6.32-22.35.rtai_all.deb
[18:21:44] <jepler> (there are two)
[18:22:10] <andypugh> Not that I have anything to compile anymore, I seem to have suffered a git accident
[18:22:34] <jepler> what happened?
[18:22:45] <andypugh> What was wrong with this sequence?
[18:23:39] <andypugh> git clone. new branch. edit file, save file, checkout. checkout master, git pull, checkout new branch, no changes to be seen.
[18:24:58] <alex_joni> "save file, checkout"
[18:25:04] <alex_joni> that should have been check-in
[18:25:19] <andypugh> I was using git-gui
[18:25:41] <alex_joni> checkout (if that is what you really did) reverts your changes, and grabs a fresh copy
[18:25:44] <jepler> does 'git reflog' show you any commits?
[18:25:54] <andypugh> So it is more likely that I have misremebered the name of the button than done the wrong thing. In fact, the word was "commit"
[18:26:22] <andypugh> So, it was save file, commit.
[18:26:27] <jepler> if it's a fresh clone then 'git reflog' won't print more than a few lines, so you can just paste them all if you wish.
[18:27:00] <andypugh> 856d490 HEAD@{0}: checkout: moving from master to motenc
[18:27:01] <andypugh> 815ce96 HEAD@{1}: pull : Merge made by recursive.
[18:27:01] <andypugh> f9a4ec3 HEAD@{2}: commit: Add velocity and filter pins to Motenc driver
[18:28:01] <jepler> I think if you use 'gitk master', you'll see that contrary to what you intended, your change is on branch master, not branch motenc.
[18:28:29] <jepler> I assume that f9 is the work you are talking about
[18:28:51] <jepler> perhaps you only issued the command to create a new branch, not to switch to it?
[18:29:05] <andypugh> Quite possibly. I am a clueless noob
[18:29:14] <jepler> in any case, if you're on branch motenc now and there's just that one commit, one easy way to get it on your branch is to cherry-pick it: git cherry-pick f9a4ec3
[18:31:18] <andypugh> I think I could like Git, if i understood how to work it. :-)
[18:31:25] <andypugh> That did the trick
[18:32:32] <jepler> the lesson for today is, if you commit it and then screw up, you can probably get your work back. but yes, it's a program with a learning curve..
[18:37:48] <andypugh> And reverting the headers appears to have worked well too.
[18:38:24] <andypugh> Is the headers problem that the mozmk kernel is a patched ubuntu kernel, not a patched vanilla kernel?
[19:09:02] <andypugh> Is insmod: error inserting '/home/andypugh/emc2.5-dev/rtlib/hal_motenc.ko': -1 No such device
[19:09:02] <andypugh> an error from hal_init? It doesn't match any of the error messages in the hal_motenc code.
[19:14:09] <micges> andypugh: check dmesg
[19:14:18] <andypugh> That was from dmesg
[19:15:00] <andypugh> I am expecting a "no motenc cards found" error, but it seems to be failing at hal_init, which seems odd.
[19:15:54] <micges> see hal_motenc.c line 319 and 351
[19:17:33] <andypugh> Indeed, that is the error I would expect to see in dmesg. But I don't.
[19:18:07] <andypugh> I might have the debug level wrong (how do you set the debug level in halcmd?)
[19:18:17] <micges> increase rtapi debug level
[19:20:51] <micges> (don't remember how to do this)
[19:51:26] <alex_joni> andypugh: check rtapi.conf
[19:51:30] <alex_joni> it's in scripts/ iirc
[19:51:37] <alex_joni> the default HAL debuglevel is there
[19:51:50] <andypugh> Aha! That beats editing the source :-)
[19:52:10] <alex_joni> or you could do a 'echo 5 > /proc/rtapi/debug' after starting realtime, before loading the hal_motenc driver
[20:00:01] <andypugh> rtapi.conf seemed easier, and it is, indeed, exiting with a "no card found" error. I actually suspect that the debug level of that message is wrong.
[20:01:15] <andypugh> It's set RTAPI_MSG_WARN, so most of the time will never get seen.
[20:12:45] <alex_joni> feel free to fix it
[20:12:50] <alex_joni> but as a separate commit
[20:14:02] <andypugh> It's probably easier for somebody else to fix it.
[20:15:13] <andypugh> (rather than me send a patch to the mailing list and hoping that somebody picks it up and commits it)
[20:43:12] <alex_joni> right, but less likely
[21:21:34] <micges> good night all