wtf is this crap from ubuntu.... update complete system restart required? they think this is windows or something?
except I'm running the magma kernal
you don't have to restart, but of course you won't be running the updated kernel until you do ...
I don't want the updated kernel
you still have the non=magma kernel installed. technically, you should be able to remove it
gotta look at grub/menu.lst and see if they changed my default
I don[t know if that'll screw up anything else though
yeah - I was thinking of that as well
I don't have a burning desire to experiment on my system
but that stupid "please restart" icon in the corner of the screen is gonna annoy me
automatic updates are the blessing and curse of Ubuntu
killall -9 update-manager
I want most updates
just not kernel ones
I wonder if it is deadly to remove the non-RT kernel package
the new kernel is now default for grub, no doubt
no, they didn't do that
but the did add "quiet splash" to every fscking entry in menu.lst
I've only remove that gawd damned crap about ten times
_and_ changed the fscking metacomments so it wouldn't come back
actually, there's probably a "linux-kernel" package that always gets modified to depend on the latest kernel - if you uninstall the empty package, you should stop getting kernel updates
but it comes back anyway!
you need to put the default line and the config you want outside the "package managed" section. unless that doesn't work ;)
## additional options to use with the default boot option, but not with the
## e.g. defoptions=vga=791 resume=/dev/hda5
# defoptions=quiet splash
I changed that line specifically so it wouldn't put the quiet/splash crap in
and it restored the line
* jmkasunich_ googles update-grub
did you remove the line or make it #defoptions=
made it #defoptions=
[01:59:28] <SWPadnos> http://ubuntu-tutorials.com/2006/12/29/tweaking-grub-ubuntu-510-6061-610/
hmmm - that isn't too helpful, I guess
its update-grub that is doing the dirty deed
[02:01:53] <SWPadnos> https://launchpad.net/ubuntu/+source/grub/+bug/21412
it is a bug (IMO) in update-grub
if you have #defoptions = foo, it will respect your wishes
(and add foo to every kernel)
but if you have "#defoptions =" it decides that you must want quiet splash, and replaces your defoptions line
who the hell are they to override my configuration?
update-grub is a shell script, so at least you can hack on it
it makes no distinction between a menu.lst that doesn't contain "defoptions", and one that contains "#defoptions="
in either case it uses its default (which is quiet splash)
seems to me if someone explicitly puts a "#defoptions=" line, it means they don
they don't want any steenkin options
jmkasunich_: last resort, make the file read-only?
update-grub is a script - I can change its defaults pretty easily
that will last at least until the next time grub is updated
or I can put "#defoptions=foo", where "foo" is some option that the kernel will ignore
(dunno what that might be)
how about "nosplash"
this is what I ended up with
if you don't use software suspend, resume= won't be used
I used panic=0
0 is the default for panic anyway
I think that 'key=value' for unrecognized key is acceptable, and is put in the environment of 'init'
yeah, thats what I read... the trick is making sure you pick something that is indeed unrecognized by both kernel and init
nosplash is probably a good choice - if its recognized, it should do the right thing, and if not, oh well...
update-grub is just _wrong_ though... its one thing to read "comments" and use them to modify the file
but it rewrites those commands
and it even erases other comments, ones with ## in front of them
(I added a ## comment explaining why the "#defoptions=panic=0" line was there, and update-grub deleted it
messing with comments violates the principle of least astonishment
jmkasunich_: I notice your rueful checkin comments -- if you install the RT kernel you can compile emc for it without booting that kernel. you may need to specify --with-realtime= though
jmkasunich_ is now known as jmkasunich
I gotta figure out a better way to run the farm
total organic farming?
with only one running at a time, build times are 5-6 minutes
with all running at once, it just explodes
[04:03:46] <jmkasunich> http://pastebin.ca/359929
any clue why the system keeps forgetting where libesmtp is?
I run ldconfig /usr/local/lib, and it works again
for a while
I dunno if it just randomly dies, or if its happening when I reboot
I'm sure I forget to do the ldconfig after a boot
but it doesn't seem like I should have to
man ldconfig still talks about /etc/ld.so.conf, where you can list directories - however that doesn't exist on my machine
I was just looking into that
that used to be the trick, not sure if it still is
maybe I'll try a one-line file that lists /usr/local/lib
yeah that's what I suggest
does ldconfig run at boot?
I think so
ldconfig, being a user process, must be run manually
from the bugs part of the manpage
ld.so.conf does make ldconfig read the dir when run with no args
I'm not gonna reboot to test further
jmkasunich: if it's only a problem on the ubuntu machine, why not install the esmtp package from universe?
you could also recompile the binary using libesmtp with -Wl,-rpath,/usr/local/lib in the link step
I've got libgnomeprintui2.2-0 on my system but config is looking for libgnomeprintui-2.2-0. Is that an intensional difference?
the debian package name is libgnomeprintui2.2-dev, the pkg-config package name is libgnomeprintui-2.2
Why doesn't config find it on my setup?
This is a 2.1.0 installed from the latest CD.
what does this print? pkg-config --libs libgnomeprintui-2.2
did you install libgnomeprintui2.2-dev? It shold have been installed by apt-get build-dep emc2.
Nope not installed.
let me try that build dep again and see if it finds it.
Doesn't seem to "need" that package.
OK -- now I spot the error
you should be able to install that package by hand
I'll check in a fix so that after emc 2.1.1, libgnomeprintui2.2-dev is installed by build-dep
I updated emc2-cvs-build-dep
Okay I'm curious. If latex2html isn't required, how do we get html for docs and man?
rayh: HTML documentation is not included in the .deb, so therefore latex2html is not required to build the deb
SWPadnos_ is now known as SWPadnos
it is still required if you specify --enable-build-docs=yes or --enable-build-docs=html
And the second half. Making man pages into html?
that is also not done when building the .deb package
(or need not be, since those files are not included in the .deb)
I guess I'm thinking less legal and more proceedural.
What package or scripts are used to produce them if a user asks.
latex2html for .tex -> html and groff for man -> html
that is not changed
what is changed is that a user need not install those to rebuild the .deb package, and that's what debian/control Build-Depends: is for
Okay I get it.
Thanks for the lesson.
I explain things as well as I can...
You did great.
jepler: have you touched/used automake before?
alex_joni: no. it's a butt ugly pile of crap, and I advise you to stay away from it at all costs
SWPadnos_ is now known as SWPadnos
jepler: lol, I can see that from the first 5 minutes around it
a steaming cow patty?
* jmkasunich hides from GuestXXX
uh oh there must be something wrong with my /ignore
dear friends, I am confused
it's a different IP address this time
* jepler ignores it and moves on
ignore a whole /16? I hope that remains overkill
heh. I haven't noticed whether the third byte is the same, it could be a /8
jack seems to not really understand what he's doing ...
no, they're different, 200.180.186 and 200.180.89
what can you do ...
just popping in #emc and saying one has a problem is not really usefull
jmkasunich: is there any reason *not* to provide an option to set pins to a known value on shutdown? I understand it's not a substitute for other safeguards, but it seems like a nice characteristic
he also said "hi friends" - don't forget that
jepler: good question
the only thing I can think of is how to config it
jepler, there is no reason to prevent it, but it isn't useful since you can never know the state before EMC runs, and that has to be made safe by hardware
I guess there could be params
run a HAL file at shutdown: unlinkp parport.0.pin-01-out; setp parport.0.pin-01-out TRUE
that is a far more general method
I like the shutdown hal file better
and I thought about suggesting it to owhite
in that case It would be a feature of the emc runscript
but I didn't want to have to explain it :-(
just like the postgui might be
jepler: right now the pustgui hal file is AXIS specific.. right_
alex_joni: yes, there's not a generic way to say whether the gui is ready, and it's not needed for any gui *but* axis since only it creates HAL pins
even a simple script like the pyvcp could do that... set stuff up, open a pyvcp, do a waitusr pyvcp, after the waituser, set output states, then sleep long enough to know that they have been written to the hardware, then clean up
so it's really not a HAL feature, but just a way of designing your HAL-using system
I'd much prefer that to having to add shutdown states to every single output driver
you can always spawn a halcmd out of a hal file
because I'm a lazy coder
make it wait on some process, and run the shutdown .hal after that
[20:48:39] <jepler> http://pastebin.ca/360958
make [HAL]SHUTDOWN be a HAL script that is run after the GUI is shut down
uh, not quite
I haven't tested it ..
what you wrote will use [SHUTDOWN]HALFILE as the shutdown script
thats a detail, the general idea is great
yup, I like it too
Cleanup() has both the task of cleaning up *this* emc instance *or* an old instance that didn't exit
so shutdown should do that too :)
is it appropriate to run *this* emc's [HAL]SHUTDOWN when it's shutting down *another* emc session?
maybe I should only do this when "$1" != "other"
if you have multiple EMC configs for the same machine/hardware, seems like the shutdown script that renders them safe will be the same for all
the worst that can happen is having a halfile referring to a driver not loaded
but if it's an rogue emc2 it shouldn't matter much
might want a -kf in there, so if there is something missing it will finish up anyway
although.. as usual.. people running this can seriously cause havoc (e.g. run a config with a shutdown file that triggers a selfdistruct of the machine)
that's why I'm leaning towards changing it to do nothing in the "shutting down some other emc instance" case
[21:14:41] <jmkasunich> http://www.drawblog.com/images/20070217011416651.jpg
handy little tool
go to drawblog.com, sketch, submit, post URL
for those cases where a pic is worth a thousand words
it is a masterpiece
what is it?
it would be really nice if the drawing tool would let you do text
needs flash tho
undo is cool - but it is pretty hard to erase sections
yeah, there are definitely limits
but hey, its free
pastebin, imagebin, and now this
all handy to have
you can change the color to white - I guess
[21:19:06] <alex_joni> http://www.drawblog.com/images/20070217011851225.jpg
I wonder what percentage of the sketches are obscene
usemap=#20070217012102381 border=0><MAP NAME="20070217012102381"><AREA HREF="http://www.drawblog.com"
ALT="Free Sketch Hosting" SHAPE=RECT COORDS="0, 269, 80, 277"></map>
[21:21:58] <skunkworks> http://www.drawblog.com/images/20070217012102381.jpg
jmkasunich: skunkworks just posted the first obscene one
alex_joni: you must have a dirty mind
besides, I'm sure its far from the first