I'm trying to set up compile farm stuff
when I installed build-dep on the non-rt hardy box it brought in the rtai kernel
I don't think I want that - can I just uninstall the kernel, or is that gonna lead to unmet dependencies
just leave it installed but don't boot it?
that would leave a realtime dir somewhere, which is different from a true sim situation
at a minimum I'll have to edit menu.lst, otherwise I bet it will be booted by default
sorry what's the ultimate goal?
if the complaints are true, then you probably don't have to worry
heh, that's true
to have a VM with a vanilla hardy install, and compile sim mode EMC2 on it
(it seems that the RT kernel doesn't become the default kernel when installed onto a stock Ubuntu system)
I'll have to look at menu.lst and see
but anyway, this system isn't gonna be very "vanilla" if it has a RT kernel (and matching headers, etc) on it
ah, for sim mode, you sure could just uninstall it
you don't need kernel headers or anything
wouldn't that uninstall emc2-dev also, since it appears to be dependent on the RT kernel?
for sim you need a couple things not in the build-dep; configure will tell you what they are
I think libpth is one of them, that is mentioned in the wiki
where do you see that?
Depends: g++, libpth-dev, python (>= 2.4), python (<< 2.5), emc2-sim (= 1:2.2.0), yapps2-runtime
err, maybe not emc2-dev - he did say build=dep
ok - just wondering about jmk's original statement: "when I installed build-dep on the non-rt hardy box it brought in the rtai kernel"
so you must have installed emc2, not emc2-sim
"installed build dep" was the wrong working
apt-get build-dep emc2
I didn't actually _install_ emc2
sure, that's what I thought you meant
there's another package though, called emc2-sim
I didn't install that either
cradek, was that paste from the emc2-sim build deps?
different dependencies for build-dep emc2-sim though
oh, I see - I should have dones "build-dep emc2-sim" on the non-rt systems
that was depends for emc2-dev
for those systems where a sim package exists, which is not all (though I don't recall which ones are missing)
is emc2-sim a hardy only thing?
you said it depended on the kernel, which is incorrect
jmkasunich: I think it's built for dapper only ... maybe
I just tried build-dep emc2-sim on the dapper VM and it couldn't find the source package
that was an assumption based on jmk mentioning that the RT kernel came along with an apt-get build-dep
I'm juggling four systems here......
jmkasunich: deb http://www.linuxcnc.org/emc2
then I'd just uninstall it ;)
(the RT kernel that is)
jmkasunich: sim and non-sim are in different apt repos
gotcha - fixing sources.lst now
damn, I bet I should have uninstalled the RT kernel before I removed the emc2.2 repo from sources.lst
what is the apt command for "get rid of it all"? remove, or is there something else?
apt-get remove --purge ...
got some interesting error/warning messages from that
"the link /vmlinux is a damaged link"
ditto for /initrd.img
and "cannot delete /boot/initrd.img-2.6.15-magma, doesn't exist"
it'll probably still boot
yeah, the generic kernel is at the top of the list, and the default number is 0
rebooting that vm
the dapper RT one should be all good, on to hardy non-rt
for hardy non-rt, is the repostitory line supposed to end "hardy base emc2.2-sim" ?
I don't think there is hardy sim
I already loaded the non-sim repo, and got the build-deps for emc2, then removed the rtai kernel and modules
I bet I can just remove the emc repos from sources.list completely now
yes, you never needed them
well, build-dep emc2 is probably the easiest way to get all the stuff I need to build
cool, after reboots the non-rt systems are running the proper kernels
by the fourth time I do each step it goes pretty quick....
EMC: 03cradek 07TRUNK * 10emc2/share/axis/tcl/axis.tcl: slightly incomplete max velocity control in AXIS
EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: slightly incomplete max velocity control in AXIS
ssh to linuxcnc.org working on all four....
* jmkasunich smacks jepler's DSL
3 checkouts per machine, 4 machines
trunk, 2.2, and 2.1
I suppose 2.1 isn't really needed
surely you could do the three and copy it locally...
I've never moved checkouts around
I suppose as long as all the CVS/ directories get transferred it would work
it's good to insure that the keys are correct (if you're doing non-anon checkouts)
but that would involve tarring it up on one box, scping to the other, untarring, etc
I'd just rather type the checkout commands and let it do its thing
just use a host/client shared directory
SWPadnos: then I'd have to set that up
(for the transfer, not for building)
I just realised that my farm README has 2.0 and 2.1, and omits 2.2
I suppose we really don't need to be doing 2.0 anymore
my old "slot" numbers are a bit of a nuisance
EMC: 03jmkasunich 07TRUNK * 10infrastructure/farm-scripts/ (README index.shtml run_farm): removed versions 2.0 and 2.1 from the farm, added list notification of 'Pass after a Fail', other minor tweaks
why do you need to use "visudo" to edit /etc/sudoers
read the man page, found out that it wasn't going to force me to use vi.....
EMC: 03compile-farm 07Ubuntu 6.06 LTS (dapper) realtime (2.6.15-magma) (2.6.15-magma) * 10emc2head/: build PASSED
EMC: 03compile-farm 07Ubuntu 6.06 LTS (dapper) non-realtime (2.6.15-52-386) * 10emc2head/: build PASSED
EMC: 03compile-farm 07Ubuntu 6.06 LTS (dapper) non-realtime (2.6.15-52-386) * 10emc2.2branch/: build PASSED
EMC: 03compile-farm 07Ubuntu 8.04 LTS (hardy) non-realtime (2.6.24-21-generic) * 10emc2.2branch/: build FAILED ; see http://linuxcnc.org/compile_farm/emc2.2branch_slot3_log.txt
EMC: 03compile-farm 07Ubuntu 8.04 LTS (hardy) non-realtime (2.6.24-21-generic) * 10emc2head/: build PASSED
EMC: 03compile-farm 07Ubuntu 8.04 LTS (hardy) non-realtime (2.6.24-21-generic) * 10emc2.2branch/: build PASSED
EMC: 03compile-farm 07Ubuntu 8.04 LTS (hardy) realtime (2.6.24-16-rtai) * 10emc2.2branch/: build PASSED
EMC: 03compile-farm 07Ubuntu 8.04 LTS (hardy) realtime (2.6.24-16-rtai) * 10emc2head/: build PASSED
what does the debian/emc2-docs.files do?
steve_stallings is now known as steves_logging
I wonder why relative I,J won out. The absolute seems easier to work with. (BOSS uses absolute).
well that's not true - BOSS switches depending on G90/G91
(so I make gcode compatible with both by always doing G91 arcs)
jepler: I just watched http://linuxcnc.org/compile_farm/emc2.2branch_slot3_log.txt
there are some unusual things in there:
../bin/comp --document -o ../docs/man/man9/conv_float_u32.9 hal/components/conv_float_u32.comp
sh hal/components/mkconv.sh float s32 "" -2147483647-1 2147483647 < hal/components/conv.comp.in > hal/components/conv_float_s32.comp
[: 2: ==: unexpected operator
jmkasunich: cool stuff adding 8.04 :)
hope it wasn't too much trouble
not really, just took a while to get around to it
no majour issues with hardy then?
nothing that made it fail compiling
I'm finding some strange behavior with sudo and /etc/sudoers
on all the VMs, I have a line in /etc/sudoers that should let the scripts run ntpdate without a password, to keep the clocks in sync
sorry I ignored your question - because I have no idea
on breezy it works, on dapper and hardy it doesn't
hmm.. did the syntax change?
haven't been able to find anything yet
I've only really started googling today, it was 2am last night when I ran into this'
what's the line?
jmkasunich: can't you just run ntpd?
fenn: no, ntpd and VMs don't play nice together
not 100% sure why, I think it may relate to the fact that time doesn't pass at the same rate for a VM (in some cases)
or it may have been only the RT kernels that had that problem
or, it might have been when I suspend a VM that it got all screwed up - don't remember details, just remember I wasted a day or so trying to make it work
alex_joni: "jmkasunich localhost = NOPASSWD: /usr/bin/ntpdate"
at the end of the file
hmm.. looks ok
works ok on breezy too
maybe try ALL instead of localhost
jmkasunich localhost=(ALL) NOPASSWD: /usr/bin/ntpdate
changing localhost to ALL worked
adding the (ALL) didn't change anything
have I mentioned lately that vi is vile
on dapper, visudo actually give me pico/nano
on hardy, I get vim
and setting EDITOR and/or VISUAL doesn't seem to help
EMC: 03jmkasunich 07TRUNK * 10infrastructure/farm-scripts/README: minor tweak to get passwordless ntpdate
everything working now, thanks again
next step (maybe) is to run the testsuite
I'm a little concerned about that though - compiles either pass or fail, while tests might lock up
Update for Ubuntu 8.04: The default editor for visudo has changed to vi. To change this behavior, using any editor,
[18:47:51] <alex_joni> https://help.ubuntu.com/community/Sudoers#Editing
the sudoers file
"Because sudo is such a powerful program" translation "because of our stupid policy decisions your system will break completely if you make a single typo in /etc/sudoers"
fenn: you mean the decision not to have a root account by default?
keep in mind that Ubuntu was not targeted at linux geeks, it was target the likes of Dave H on the mailing list
well, i guess i'm confusing two separate incidents, one where i made a typo in sudoers, and another where i changed /etc/hosts and it broke sudo
but puking on a single typo is bad behavior in my book
visudo is there to protect you against typos in sudoers
and having a special editor command that you just have to know you have to use, is not even a hack, it's a kludge
there is no getting around the fact that there will be files on a system where typos can screw you
with a long history (vipw, vigr)
grub/menu.lst can keep you from booting
fstab can keep you from mounting things
this is true, but why cant it just ignore the line?
depending on the line, ignoring could either lock you out, or allow attackers in
in the case of an error, guessing what the user meant is bad policy
the problem is it locks you out no matter what the error was
"syntax error reading /etc/sudoers" or something like that
from a security standpoint, that may be the right decision
sure but then who gets to use sudo?
what were we arguing about? haha
if you manage to fsck up sudoers, you reboot into recovery mode and fix it
if you can't reboot into recovery mode, maybe it's because you are an attacker
cradek: arguing about this - fenn: "because of our stupid policy decisions your system will break completely if you make a single typo in /etc/sudoers"
i just thought it was ironic that they tried to cover up this mess with "because sudo is so powerful"
words are imprecise.. oh well
well.. I managed to fsck it up once, by changing the write permissions
after that it didn't want to run, because of improper permissions :)
ha, shop door is wider than my car
I thougth your shop door was a garage door?
no it's a steel double-person door now
so did you pull the car into the shop?
it's so tempting, but I'd have to move a couple things.
I'm trying (probably unsuccessfully) to heat the garage instead
only tempting if you need to work on it or something
yeah, I do
I've been putting it off...
I've been putting off raking leaves
"there are still some on the tree, why rake now?"
heh, and they'll be gone by spring
thats what I thought last year
maybe next spring :D
unfortunately, it's spread uniformly on the yard...
matted down soggy mess that killed the grass
you need an autonomous leaf blower
just run the lawn mower over it
no, I just need to get my lazy ass outside and deal with it
starting right now - bbl
* alex_joni heads to bed
cradek: are you around?
off and on
every time I go looking for a tool I put down somewhere - so, pretty often
how do you go about it?
(in 10 workds or less)
increase P until osc then back off. Add a bit of D. then use ff2?
I am trying to remember what jon did - seemed pretty simple.
set I=0, adjust P to barely oscillate, adjust D to stop oscillation, set up a back-and-forth program, adjust following with FF1 and FF2, add some I until it starts getting screwy, tweak everything for hours
BAS is hooked up. Only running 80v so far.
(big ass servo)