[00:00] <Keybuk> yes
[00:00] <Keybuk> any problems after >1hr are real problems ;)
[00:00] <jono> Keybuk, thanks for your work on this :)
[00:00] <Keybuk> jono: thank slangasek, cjwatson and lamont more than me
[00:00] <maxb> Is there a package we can watch for to know we've got all the updates that are expected to make things work again?
[00:00] <jono> thanks slangasek, cjwatson :)
[00:01] <jono> right, gonna go buy an ethernet cable so I can upgrade in a bit :)
[00:01]  * maxb wonders what this means:
[00:01] <maxb> Setting up rsyslog (4.2.0-2ubuntu3) ...
[00:01] <maxb> restart: Unknown instance:
[00:01] <Keybuk> it's upstart's way of saying "not running"
[00:01] <squirrelpimp> will the changes be published on the xy.archive.ubuntu.com mirrors? Or only on some master servers?
[00:01] <Keybuk> squirrelpimp: in the usual fashion
[00:02] <squirrelpimp> which i don't know :(
[00:02] <Keybuk> squirrelpimp: the changes are published to a master archive, from which the primary mirrors sync from
[00:02] <Keybuk> other mirrors may sync from other mirros
[00:02] <squirrelpimp> ok
[00:02] <slangasek> jono: thank cjwatson and lamont, I'm just watching and waiting to be able to start CD builds :)
[00:03] <squirrelpimp> and that master-archive it the one without any country-code in front of it i guess...
[00:03] <Keybuk> slangasek: I'd like to sneak in a couple of bug fixes before you do that
[00:03] <squirrelpimp> i think i'll go to bed and test it in the morning
[00:03] <jono> cheers lamont too :)
[00:03] <Keybuk> (you can say "no" if you like, and we'll just release note them <g>)
[00:03] <lool> slangasek: Do you know at what time livecd-rootfs is updated by any chance?
[00:03] <slangasek> Keybuk: what are they?
[00:04] <Keybuk> slangasek: mountall can run fsck and mount simultaneously on raid devices that change
[00:04] <Keybuk> X crashes during updates that reload D-Bus
[00:04] <slangasek> I still have to get software-store binaries into main before I can rebuild ubuntu-meta before I can start CD builds, so you have a bit of time
[00:04] <Keybuk> mountall won't work if you don't have /dev/.initramfs/varrun
[00:04] <Keybuk> ok, cool
[00:04] <Keybuk> I have the uploads ready, just wanted to wait for a full publish and your ok ;)
[00:04] <cjwatson> slangasek: d-i needs to be built against the new linux, which hasn't built yet
[00:04] <Keybuk> oh, and n-m shouldn't depend on HAL
[00:04] <slangasek> Keybuk: heh - yes, go ahead with them
[00:04] <Keybuk> (and shouldn't be restarted when HAL is)
[00:04] <slangasek> Keybuk: ^^ ah, cjwatson says you've got plenty of time
[00:05] <cjwatson> slangasek: unless you want to relax the rule about d-i being up-to-date with the kenrel
[00:05] <cjwatson> kernel
[00:05] <Keybuk> given that the kernel in question has the ext3/4 fixes ... does that make a difference ?
[00:05] <slangasek> cjwatson: would rather not, no :)
[00:05] <cjwatson> Keybuk: that isn't the only change
[00:05] <cjwatson> I confess I don't know what all the others do
[00:06] <cjwatson> d-i is also several kernel revisions old, I think
[00:07] <slangasek> cjwatson: I can take care of the d-i rebuild once the kernel's available
[00:08] <cjwatson> thanks
[00:08] <slangasek> cjwatson: anything else I should put on my todo list so you can have some time away? :)
[00:08] <cjwatson> I think that's actually about it, I cleared up my pending eucalyptus stuff earlier, and did a ubiquity upload
[00:09] <cjwatson> yeah, don't expect me in too early tomorrow :)
[00:09]  * slangasek grins
[00:11] <andersk> Is it known that the initscripts upgrade does not actually remove the old init.d scripts (see http://wiki.debian.org/DpkgConffileHandling )?
[00:13] <Keybuk> andersk: yes, they're still there for now so it's possible to rescue things that way
[00:13] <Keybuk> but if you could file a bug to remind me to remove them lest I forget
[00:14] <andersk> Will do.
[00:15] <jdub> Keybuk: i still have usplash bits in my initramfs
[00:15] <Keybuk> jdub: possible
[00:15] <Keybuk> try the next update
[00:15] <jdub> ok
[00:15] <jdub> also, there's a fly in my soup.
[00:16] <pochu> try the next libsoup
[00:16] <Keybuk> ok
[00:16] <Keybuk> I'm out of here for a bit, going to chill out while the publisher runs
[00:16] <Keybuk> will come back in an hour so, do some testing, and upload the three bug fixes
[00:17] <maxb> Is something supposed to remove the old scripts from /etc/init.d/ ?
[00:18] <ion> maxb: Look a few centimeters above this line.
[00:19] <maxb> ah :-)
[00:24] <maxb> Something weird is happening with karmic for me - supposedly clean shutdowns don't seem to be unmounting my root partition cleanly, and ext3 journal recovery happens on boot
[00:24] <maxb> has anyone else noticed that one?
[00:25] <TheMuso> 8/c
[00:28] <jpds> maxb: Maybe bug #427822 ?
[00:29] <maxb> No, that's something that goes wrong in *response* to a dirty unmount, not a cause thereof
[00:42]  * kees wonders when it will be safe to dist-upgrade
[00:43] <slangasek> kees: half hour, maybe?
[00:44] <kees> slangasek: ok, cool.
[00:44] <chrisccoulson> heh, i probably should have waited
[00:44] <kees> i'm curious how apparmor and ufw will turn out.
[00:44] <slangasek> chrisccoulson: just don't reboot until the next upgrade :)
[00:45] <chrisccoulson> slangasek - too late, i already did that ;)
[00:45]  * chrisccoulson is glad for live CD's
[00:46] <maxb> i386 seems ok already
[00:47] <maxb> amd64 looked like it might be, but I don't want to reboot yet
[00:47] <chrisccoulson> maxb - i run amd64 here;)
[00:48] <squirrelpimp> maxb: i just tried amd64 with no luck
[00:55] <cjwatson> archive and gb.archive appear to have the complete set noww
[00:55] <cjwatson> -w
[00:55] <cjwatson> other mirrors may have to wait longer
[00:55] <cjwatson> depending on network distance etc.
[00:56] <LaserJock> ugg, edubuntu's livefs build died a horrible death
[00:57] <cjwatson> yes, along with the rest of the world
[00:58] <cjwatson> don't worry about it, it should be fixed tomorrow
[00:58] <chrisccoulson> my machine is pretty screwed then, it still doesn't boot with the full set of packages
[00:58] <chrisccoulson> i'll have to look at that tomorrow though
[00:58] <squirrelpimp> cjwatson: yes, lot's of packages arrived here as well
[00:58] <squirrelpimp> still no booting :(
[00:59] <cjwatson> ok, Keybuk will have to follow up on that when he gets back I guess
[00:59]  * cjwatson &
[01:04] <jdub> Keybuk: changing initramfs to MODULES=dep is pretty winful too
[01:05] <jdub> Keybuk: is that more or less aggressive than your proposed changes?
[01:05] <bgamari> NetworkManager seems to fail to start at boot
[01:05] <bgamari> On newly fixed karmic system
[01:05] <bgamari> Starting manually works fine
[01:05] <bgamari> How is NetworkManager supposed to be started at this point?
[01:06] <bgamari> ahh, never mind; init.d
[01:07] <ion> /etc/init/network-manager
[01:12]  * Keybuk returns
[01:12] <squirrelpimp> wb
[01:15]  * ion gosubs
[01:17] <squirrelpimp> still the last line i get is "/dev/mapper/vg0-root: clean, ... files..."
[01:19] <Keybuk> squirrelpimp: you're running an up-to-date karmic system
[01:19] <Keybuk> amd64?
[01:19] <squirrelpimp> yes
[01:19] <Keybuk> can you get files from that system to IRC?
[01:19] <Keybuk> (without just typing them)
[01:19] <Keybuk> ie. upload them somewhere, or get them to pastebin, etc.
[01:19] <squirrelpimp> yes, i can boot it with a livecd
[01:20] <Keybuk> ok
[01:20] <Keybuk> I need you to try booting with init=/bin/bash
[01:20] <squirrelpimp> before i do that, shall i copy something from the hung up boot process
[01:20] <squirrelpimp> ok, i'll try that
[01:20] <Keybuk> then at the shell, run mountall --debug > /dev/mountall.log
[01:20] <Keybuk> (you may want an & there too)
[01:21] <Keybuk> then try running "udevd --daemon" and "udevadm trigger"
[01:21] <Keybuk> after that, move the log to the root filesystem if you can, and upload it so I can read it
[01:21] <Keybuk> (usb key is another option, btw)
[01:22] <ion> IIRC, the last time i tried, mountall refused to start from init=/bin/bash because it failed to connect to Upstart. It’s been a while from that attempt, though.
[01:22] <Keybuk> oh
[01:22] <Keybuk> right
[01:22] <Keybuk> that will probably happen
[01:22] <Keybuk> d'oh
[01:22] <Keybuk> err
[01:22]  * Keybuk thinks
[01:23] <Keybuk> you may have to write an upstart job to give you a shell ;)
[01:23] <Keybuk> start on startup
[01:23] <Keybuk> console owner
[01:23] <Keybuk> exec /bin/bash
[01:23] <Keybuk> ;-)
[01:23] <squirrelpimp> where should i place that?
[01:23] <Keybuk> squirrelpimp: in /etc/init
[01:24] <squirrelpimp> there's already a script called mountall-shell
[01:24] <Keybuk> yes, but that will only fire if mountall exits with a failure
[01:25] <Keybuk> you're reporting "hanging"
[01:25] <squirrelpimp> right
[01:25] <Keybuk> that to me implies that mountall is still waiting for something
[01:25] <Keybuk> another option, btw
[01:25] <Keybuk> is to change mountall.conf and put the --debug there
[01:25] <Keybuk> and if you can, take a photo of the screen at the point it hangs and upload that somewhere
[01:25] <squirrelpimp> i'll prefer pastebin if that's ok
[01:26] <Keybuk> sure
[01:26] <squirrelpimp> in the file goes: start on startup\n console owner\n exec /bin/bash\n
[01:26] <ion> Probably should also comment out ‘console output’ and remove --daemon, since daemonize^H^Hse reopens std{out,err} to /dev/null IIRC.
[01:26] <ion> Er
[01:26] <Keybuk> ion: mountall doesn't use daemonize ;)
[01:26] <ion> comment out ‘expect demon’. Brainfart.
[01:27] <squirrelpimp> ctrl+d gave me a kernel panic
[01:27] <Keybuk> squirrelpimp: yes.
[01:27] <ion> Ah
[01:27] <squirrelpimp> k, reboot
[01:27] <squirrelpimp> do i have to change kernel line?
[01:27] <Keybuk> shouldn't need to
[01:28] <squirrelpimp> k, i have the shell again
[01:29] <Keybuk> squirrelpimp: "status mountall" from that shell
[01:29] <squirrelpimp> ok, i started mountall to a logfile with &
[01:30] <squirrelpimp> running 1322
[01:30] <squirrelpimp> but pidof gives 2 pids
[01:30] <Keybuk> sure, because you just started a second copy
[01:30] <Keybuk> but that's ok
[01:30] <squirrelpimp> yes
[01:30] <Keybuk> do "start udevtrigger"
[01:30] <Keybuk> (rather than the other udev stuff I mentioned)
[01:30] <squirrelpimp> sits there doing nothing
[01:30] <squirrelpimp> not returning to shell
[01:31] <Keybuk> the udevtrigger doesn't return to the shell?
[01:31] <squirrelpimp> no
[01:31] <Keybuk> you should be able to ^C it
[01:31] <squirrelpimp> i was
[01:31] <Keybuk> status udevtrigger says?
[01:32] <squirrelpimp> udevtrigger start/starting
[01:32] <Keybuk> that's weird
[01:32] <Keybuk> ps ax | grep udev
[01:32] <Keybuk> what do you see?
[01:33] <squirrelpimp> upstart-udev-bridge --daemon, 3 times udevd --daemon, bluetoothd --udev
[01:33] <Keybuk> ok
[01:33] <Keybuk> if you run "udevadm trigger" what happens?
[01:33] <squirrelpimp> returns to shell
[01:33] <Keybuk> anything else?
[01:33] <squirrelpimp> exited with 0
[01:33] <squirrelpimp> nothing alse
[01:33] <Keybuk> ok
[01:33] <Keybuk> send your mountall SIGTERM now
[01:33] <Keybuk> and then copy the log out of /dev
[01:34] <Keybuk> reboot into your live cd, and upload the log somewhere
[01:34] <squirrelpimp> SIGTERM to both mountalls?
[01:35] <squirrelpimp> i put it on the usbstick
[01:35] <Keybuk> if you like
[01:35] <squirrelpimp> http://pastebin.com/d3d904e3e
[01:36] <squirrelpimp> there you go
[01:42] <squirrelpimp> Keybuk: how does it look to you?
[01:43] <squirrelpimp> as it doesn't seem to be mentioned in that file, my /home is encrypted using luks
[01:45] <Keybuk> right
[01:45] <Keybuk> it looks like it's waiting for your /home and /boot to show up
[01:46] <squirrelpimp> ok
[01:46] <Keybuk> and they haven't
[01:46] <squirrelpimp> i can comment /home and encrypted swap as well
[01:46] <squirrelpimp> boot is sda1 ext2
[01:46] <Keybuk> can you run blkid -p /dev/sda1 for me
[01:46] <Keybuk> and paste the output
[01:47] <squirrelpimp> ambivalent result (Probably more filesystems on the device)
[01:47] <Keybuk> eep
[01:47] <Keybuk> ok
[01:47] <Keybuk> so that's why it's refusing that
[01:47] <Keybuk> I've no idea about the LUKS stuff
[01:47] <squirrelpimp> how can that happen?
[01:47] <Keybuk> how does it work? ?p
[01:48] <squirrelpimp> the volumes are configured in /etc/crypttab and setup by /etc/init.d/cryptdisks-early and /etc/init.d/cryptdisks
[01:48] <slangasek> Keybuk: using an init script that's not converted over yet
[01:48] <squirrelpimp> after that they are used like regular devices in /dev/mapper
[01:48] <Keybuk> that explains it then
[01:49] <slangasek> hmm, this is that use case we discussed in the bug :-P
[01:49] <Keybuk> huh?
[01:49] <squirrelpimp> so will it help to fix the sda1 problem?
[01:49] <Keybuk> squirrelpimp: no
[01:50] <slangasek> Keybuk: the "you can use cryptsetup in a way that doesn't actually prompt you for a passhprase" :)
[01:50] <slangasek> ("but why would you want to")
[01:50] <Keybuk> slangasek: it still should be a udev rule not an init script ;)  I've been telling them that for years
[01:50] <Keybuk> I thought they were using udev rules
[01:50] <slangasek> Keybuk: oh, absolutely
[01:50] <Keybuk> in fact, I remember writing them
[01:50]  * slangasek shrugs helplessly
[01:50] <squirrelpimp> there goes my encryption
[01:51] <squirrelpimp> what can i do to prevent the sda1 error ?
[01:51] <Keybuk> squirrelpimp: is your /dev/sda1 secretly part of a RAID?
[01:51] <squirrelpimp> nope
[01:51] <squirrelpimp> it was created during karmic setup and not changed
[01:52] <squirrelpimp> karmic from sept 10
[01:52] <Keybuk> strange that it has multiple signatures
[01:53] <squirrelpimp> so for now, karmic won't work with encryption? then i'll copy over the files to unencrypted partitions and leave that for now
[01:53] <squirrelpimp> if i can fix the sda1 thing
[01:53] <slangasek> it should work for encrypted rootfs; just not for encrypted (separate) /usr
[01:53] <Keybuk> sda1 you can fix the same way, just copy the files elsewhere, mkfs the device again, and copy back
[01:53] <squirrelpimp> ok, i'll give that a try
[01:54] <squirrelpimp> first however i should get some sleep.:)
[01:54] <squirrelpimp> I'll come back with my findings
[01:54] <squirrelpimp> slangasek: so setting up cryptsetup for the whole physical volume will work?
[01:55] <squirrelpimp> Keybuk: thanks for all the help. if you happen to be near karlsruhe germany, i'll make you a pizza.
[01:56] <squirrelpimp> :)
[01:56] <Keybuk> squirrelpimp: thanks for the testing!
[01:56] <slangasek> squirrelpimp: *should*, yes; I haven't tested yet myself (my test comes after the next publisher run)
[02:01] <Keybuk> slangasek: I'll look into cryptsetup interaction tomorrow
[02:01] <Keybuk> do you think we should RN it or fix it?
[02:02] <slangasek> Keybuk: fix it
[02:02] <Keybuk> ok
[02:04] <squirrelpimp> HEH..
[02:04] <squirrelpimp> err
[02:04] <squirrelpimp> heh... the rescue-shell failed on me after mkfs.ext4 /dev/sda1
[02:04] <squirrelpimp> now it has to wait till tomorrow
[02:04] <squirrelpimp> night
[02:12] <YokoZar> Is mpt on vacation?
[02:14] <Keybuk> ion: thought, for physical disks, specified by name, we shouldn't bother with what udev thinks
[02:14] <Keybuk> if someone puts /dev/sda1 in their fstab, blkid output should be irrelevant?
[02:14] <Keybuk> (probably only true for hdX and sdX though)
[02:22] <chrisccoulson> hmmm, it seems that mountall does not like the bindfs mounts i have in my fstab
[04:04] <slangasek> Keybuk, lamont: do you know why util-linux is failing to configure as part of the bootstrap in livefs builds? that seems to be the only thing failing presently
[04:06] <robbiew> slangasek: I think Keybuk has passed out for the evening ;)
[04:08] <slangasek> yeah
[04:08] <slangasek> shot in the dark, but it's going to take me a while to sort through without him
[04:30] <TheMuso> slangasek: I have a new RT kernel to upload for studio. The mainline rt patch came out overnight, and I've had to do some test building and running today before I can upload it. Unfortunately its an ABI bump due to being against mainline.
[04:30] <TheMuso> Unfortunately this is needed, as the current RT kernel doesn't boot which is why we didn't do alpha 5, and I'd prefer to get this in for alpha 6.
[04:51] <robbiew-afk> slangasek: I suppose karmic is now a little happier of a place ;)
[04:54] <ScottK> TheMuso: Sounds like the downside risk of updating is low.
[04:55] <TheMuso> ScottK: My thoughts as well.
[05:00] <lifeless> is there a mips/mipsel machine we can log into ?
[05:00] <lifeless> friend of mine writes some audio codec stuff and has a bug report for mipsel, but he can't reproduce etc...
[05:02] <ScottK> lifeless: I think NCommander has some.  Dunno if it can be remotely logged into.
[05:02] <lifeless> NCommander: ^
[05:03] <lifeless> ScottK: thanks
[05:03] <StevenK> lifeless: mahler.debian.org ? :-)
[05:04] <lifeless> down?
[05:12] <NCommander> lifeless, at the moment is completely dead, I ripped its HDD out for beta testing ;-)
[05:42] <HenryLoke> hahah
[05:42] <HenryLoke> dearest ubuntu chat room
[05:42] <HenryLoke> need your guy help me a bit
[05:52] <slangasek> TheMuso: yes, please upload; you don't need to clear such things with me before uploading, the studio-specific packages are frozen for your sake, not mine. :)
[07:10] <dholbach> good morning
[07:28] <TheMuso> slangasek: More as a heads up, since binary newnig will be required.
[07:28] <squirrelpimp> good morning
[07:34] <slangasek> TheMuso: ok - I'll try to keep an eye out for it, but if the binaries show up in the queue while I'm asleep, don't wait for me :)
[07:34] <TheMuso> slangasek: ok
[07:35] <pitti> Good morning
[07:35] <TheMuso> Morning pitti.
[07:37] <pitti> hey TheMuso
[07:37]  * slangasek waves
[07:38] <squirrelpimp> oh, new packages for upstart and mountall again
[07:58] <dholbach> james_w: what do we do about bug 414298?
[08:07] <slangasek> Keybuk, lamont: util-linux sorted
[08:09] <slangasek> Keybuk: wrt debhelper, why is it necessary to diverge from Debian and add an update-rc.d -f remove call?  I can't see how that would be necessary unless there's a bug elsewhere, and that sounds like a bug that'll be a blocker for getting Debian changed over once someone stumbles across it
[08:25] <squirrelpimp> well.. i have the exact same behaviour with unencrypted /home and swap
[08:25] <squirrelpimp> Keybuk is still sleeping i guess
[08:25]  * slangasek wonders why netbase only recommends: ifupdown, when it ships an init script that doesn't work without it
[08:26] <slangasek> squirrelpimp: what's the behavior you're seeing?
[08:27] <slangasek> I think I only caught part of that conversation before
[08:28] <squirrelpimp> the system hangs during startup, on the console i can see the mount of / and then it stops
[08:28] <slangasek> hmm, ok
[08:28] <squirrelpimp> Keybuk directed me to run mountall --debug and to make a log of that
[08:29] <squirrelpimp> then he figured out, that it was encrypted swap and /home and a wrongly labeled sda1 on /boot, which prevented mountall from succeeding
[08:29] <squirrelpimp> i removed swap, /home and recreated sda1
[08:29] <slangasek> so what does running mountall --debug now do?
[08:30] <squirrelpimp> i made another logfile
[08:30] <squirrelpimp> http://pastebin.com/d5232464d
[08:31] <squirrelpimp> are the live-cds already built with the new system btw?
[08:32] <squirrelpimp> not yet it seems
[08:32] <squirrelpimp> i copied home to a new volume called "home", which is not encrypted
[08:32] <squirrelpimp> i also tried commenting swap, home and tmpfs in fstab, so there was only /root (and the other default stuff) left
[08:32] <squirrelpimp> again, no luck
[08:33] <slangasek> hmm, the log doesn't give me any insight
[08:33] <slangasek> I guess we'll have to wait for keb
[08:33] <squirrelpimp> and the behaviour is the same as last night. "start udevtrigger" does not return to the shell
[08:33] <slangasek> for Keybuk, even
[08:34] <squirrelpimp> i'm tempted to just reinstall the box from a live-cd as it was a pretty fresh install and i did a backup before running the update in the first place
[08:35] <squirrelpimp> so keybuk or livecd, whoever comes first
[08:35] <squirrelpimp> :)
[08:35] <slangasek> the liveCD is about 40 minutes out
[08:38] <squirrelpimp> + download and burn it'd 70 minutes to wait
[08:38] <squirrelpimp> :)
[08:38] <pitti> slangasek: FYI, I cleaned up the translation related mess on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[08:44] <squirrelpimp> slangasek: now the system bootet to some further point, despite the shell.conf in /etc/init/ still being present
[08:44] <squirrelpimp> how can i remove that file, if it boots beyond /bin/bash
[08:44] <squirrelpimp> ?
[08:45] <squirrelpimp> ah, i can appent init=/bin/bash in grub
[08:45] <squirrelpimp> never mint
[08:46] <\sh> Keybuk: start on (filesystem and started hal) (your patch on gdm) but hal and not even dbus is started via upstart...hopefully you or someone is working on that ;)
[08:47] <squirrelpimp> slangasek: now it startet including X, which presents an error message from libgconf2-4/gconf-sanity-check-2 and tells me, theres an issue with the configuration server
[08:52] <slangasek> \sh: sounds to me like you need to upgrade hal and dbus
[08:52] <pitti> tseliot: do you know why -vmmouse now wants to go back to universe?
[08:52] <slangasek> squirrelpimp: are all your filesystems mounted?
[08:52] <pitti> tseliot: in the past it was a dependency of -input-all
[08:52] <squirrelpimp> yes... i think it might be a wrong mode in /tmp
[08:52] <pitti> tseliot: is it obsolete now, or was it a merge error?
[08:52] <squirrelpimp> i set that to 1777 to be sure and try again
[08:53] <\sh> slangasek: apt-get update ; apt-get dist-upgrade should be enough, right? it came after the last dist-upgrade...
[08:53] <\sh> slangasek: this morning I have to mention
[08:53] <slangasek> \sh: both hal and dbus are shipping upstart jobs in the current versions
[08:53] <tseliot> pitti: I don't think it's obsolete and I have yet to merge it with debian's version
[08:53] <\sh> slangasek: I had to manually start hal ; start dbus ; start network-manager ; start gdm
[08:54] <pitti> tseliot: merge error in -input-all, I mean
[08:54] <squirrelpimp> ok, i have gdm login
[08:54] <\sh> slangasek: dbus 1.2.16-0ubuntu3 (the latest upload of dbus e.g.) is on the system
[08:55] <tseliot> pitti: oh, it could be. Can you file a bug report about that and assign it to me, please?
[08:55] <pitti> tseliot: will do; but I wasn't sure whether it was a bug, or deliberate
[08:56] <tseliot> tjaalton: do you know anything about this ^^ ?
[08:56] <\sh> slangasek: so I checked the last uploads with scotts updates from yesterday, everything has the correct version on the system..so I'm confused now ;)
[08:58] <slangasek> \sh: then perhaps I misunderstood what you were saying, because the jobs are certainly there in the packages
[08:59] <squirrelpimp> i get "rc main process" stopped/continued lots of times during reboot
[08:59] <squirrelpimp> is that expected?
[09:00] <pitti> tseliot: done, bug 430532
[09:00] <tseliot> pitti: thanks
[09:01] <pitti> tseliot: I'll test it by installing -vmmouse into the live system once today's images land
[09:01] <pitti> tseliot: i. e. whether it still actually works
[09:01] <tseliot> pitti: ok, let me know
[09:04] <\sh> slangasek: right...but they are not started .. so after reboot (kernel update) I'm on the console...and "start gdm" doesn't work...and after investigating why it's not started, I realized that hal and dbus are not started, too
[09:05] <tjaalton> tseliot: it's fixed in git, and according to the changelog entry it should be uploaded already (on 3rd of August)
[09:05] <squirrelpimp> slangasek: it seems, that if i put /dev/vg0/home in fstab, it won't work
[09:05] <squirrelpimp> but if i replace it with /dev/mapper/vg0-home it will
[09:06] <tjaalton> tseliot: but looks like it wasn't
[09:08] <slangasek> squirrelpimp: ah; possibly because one is the kernel's "true" name for the device, and one is an alias
[09:09] <squirrelpimp> might be
[09:09] <slangasek> \sh: which version of mountall do you have installed?
[09:09] <squirrelpimp> but it would be nice if either worked
[09:09] <slangasek> squirrelpimp: yes - but knowing why is the first step :)
[09:10] <slangasek> squirrelpimp: can you file a bug on lvm2 about this, and drop the bug number here?
[09:10] <squirrelpimp> sure
[09:10] <squirrelpimp> suspend to disk doesn't work
[09:11] <\sh> slangasek: 0.1.4
[09:12] <slangasek> \sh: and that's the version you had when you booted, too?
[09:12] <\sh> slangasek: yes
[09:13] <slangasek> ok
[09:13]  * slangasek doesn't have that version here yet; 0.1.3 looks like it DTRT, but I'll keep looking
[09:13] <\sh> slangasek: thx :)
[09:17] <squirrelpimp> bug number is 430542
[09:22] <squirrelpimp> slangasek: should i worry about the "could not read '...z60_hdparm.rules" from udev?
[09:23] <slangasek> squirrelpimp: probably indicates a dangling symlink for some reason, and probably not a big deal
[09:23] <slangasek> warrants a bug report on whatever left the symlink behind
[09:25] <squirrelpimp> dpkg can't find any package the symlink belongs to
[09:25] <TheMuso> If someone would kindly let linux-rt's binary packages through binary new, then I can upload the meta, and disks can be built once all this other stuff is sorted.
[09:27] <slangasek> TheMuso: grabbing; go ahead with your meta upload
[09:27] <TheMuso> slangasek: Thanks.
[09:31] <tjaalton> pitti: the vmmouse fix was in git, but never uploaded. Ok to upload now or wait after a6?
[09:32] <pitti> tjaalton: better wait, I think
[09:32] <tjaalton> pitti: sure thing
[09:33] <soren> Is Karmic still knackered? Will I spend the rest of the day regretting it if I "apt-get dist-upgrade"?
[09:33]  * ogra wonders if there is any documentation what to do with the new upstart stuff in all the scripts that use chroots to build stuff and call invoke-rc.d and friends
[09:33] <ogra> i.e. all our virtual things, my ltsp builders and my armel build scripts
[09:33] <ogra> soren, did you get any instructions for the transition ?
[09:34] <soren> ogra: Nope.
[09:37] <slangasek> soren: karmic is settling; I don't know whether this means you'll regret it
[09:38]  * soren has a reputation of being a bit of a masochist, so probably not.
[09:38] <pitti> hey, from time to time we just _need_ to be taught how booting really works
[09:38] <pitti> how better to find out than having to fix a completely screwed system :)
[09:39] <soren> Exactly!
[09:40] <ttx> no pain, no gain.
[09:40] <ttx> (I used to run Gentoo)
[09:41] <al-maisan_> so how does one fix the "Mount point '/dev/(pts|shm)' does not exist. Skipping mount" problem?
[09:42] <cjwatson> slangasek: ah, good, I was just about to poke at util-linux after reading mail ...
[09:44] <soren> ttx: Heheh :)
[09:44] <slangasek> cjwatson: yah, sorry it took me so many mails to notice the problem :)
[09:45] <cjwatson> yeah, I ignored most of them until timestamps were such that I could no longer put them down to the known bustedness
[09:53] <dholbach> al-maisan_: did a dist-upgrade and reboot help with that?
[09:53] <dholbach> al-maisan_: I booted with init=/bin/bash and ran   sudo dhclient &   to get me on the net, then dist-upgraded
[09:54] <al-maisan_> dholbach: thanks, will try dist-upgrade, I have done a "sudo apt-get upgrade" so far..
[09:58] <al-maisan_> dholbach: cool, the machine boots to the linux console login now :)
[09:59] <dholbach> al-maisan_: all the best with completely fixing it!
[10:00] <al-maisan_> :)
[10:04]  * soren crosses fingers and goes for a reboot
[10:08] <al-maisan_> hmm .. now when attempting "restart gdm" I get: "Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory"
[10:10] <cjwatson> I'm told that's a problem with having done a partial upgrade ...
[10:12] <al-maisan_> ah
[10:12] <cjwatson> any out of date packages?
[10:12] <\sh> cjwatson: no it's not
[10:12] <cjwatson> \sh: well, slangasek said it was and I normally believe him - do you have evidence to the contrary?
[10:12] <cjwatson> (or details)
[10:13] <\sh> cjwatson: as discussed with slangasek I checked that everything is in place...no updates are missing...and it doesn't work as expected
[10:13] <dholbach> \sh: after a complete upgrade I had two working machines again
[10:13] <slangasek> well, I wouldn't have expected that particular error from a partial upgrade
[10:13] <slangasek> I would've expected upstart to refuse to start gdm at all?
[10:13] <cjwatson> ok, then I don't know; however of course it is possible that not everyone has the same cause for the same symptom
[10:14] <\sh> dholbach: I dist-upgraded this morning and it didn't work..I just saw that slangasek uploaded new hal and new gdm
[10:15] <slangasek> \sh: all those new uploads do is enforce a versioned dependency
[10:15] <slangasek> they won't work any different than a system that was already up-to-date
[10:15] <sebner> \sh: I was able to boot (after a fsck/mountall issue -reboot) but with old mountall/upstart from yesterday evening after the builds were working again
[10:16] <\sh> I realized that problem when I "dpkg-reconfigure kdm" and selected kdm as default xdm ... after that, no mouse, no keyboard (both usb) were working...(btw...dpkg-reconfigure gdm doesn't work anymore)
[10:17] <\sh> after manually "start hal ; start dbus ; start network-manager ; start gdm) it was working again
[10:17]  * al-maisan_ sees a "init: dbus pre-start process (nnnn) terminated with status 1" message scrolling by while booting the machine in question..
[10:18] <sebner> slangasek: should it boot already faster btw?
[10:20] <al-maisan_> \sh: that manual start command sequence did the trick, thanks!
[10:20] <slangasek> sebner: that's not my department :)
[10:20] <dholbach> james_w is reviewing patches and packages in #ubuntu-reviews
[10:21] <al-maisan_> oops, not quite, gdm comes up, but the touchpad and the keyboard are dead..
[10:21] <sebner> slangasek: kk, we should be happy if it boots in general ^^
[10:21] <pitti> al-maisan_: that would be missing hal then
[10:22] <pitti> al-maisan_: at startup, X reads the input devices from hal, so hal must be running before X starts
[10:22] <al-maisan_> pitti: OK.
[10:22] <pitti> I haven't checked how the upstartification ensures this dependency (or whether it does at all)
[10:22] <al-maisan_> pitti: I did "start hal" manually so it should have been running.
[10:23] <pitti> al-maisan_: and afterwards started gdm?
[10:23] <pitti> it should have worked then indeed
[10:23] <al-maisan_> pitti: yes.
[10:23] <slangasek> pitti: gdm "start on [...] started hal"
[10:23] <pitti> al-maisan_: can you check "lshal" for info.capabilities "input.keys" and "input.mouse"?
[10:24] <sebner> pitti: I'm wondering why we are fiddling with hal. So not soo deprecated yet?
[10:25] <slangasek> TheMuso: I'm not tracking linux-rt further at the moment; when you want me to roll an ISO, shout
[10:25] <StevenK> sebner: Not quite yet
[10:25] <\sh> slangasek: hal needs started dbus but dbus wasn't started and dbus wasn't started
[10:26] <StevenK> sebner: https://wiki.ubuntu.com/Halsectomy
[10:26] <sebner> heh, k
[10:26] <slangasek> \sh: not sure what you're responding to; I was simply addressing pitti's dependency question
[10:27] <sebner> StevenK: ah, only GDM remaining, the rest are just applications :)
[10:27] <cjwatson> \sh: if dbus isn't getting started, presumably that's the thing to debug?
[10:27] <\sh> slangasek: s/and dbus wasn't started/and eventually we see something strange happening with dbus?/
[10:27] <pitti> sebner: most apps switched over, but not X yet
[10:27] <ogra> pitti, btw do we keep hal in universe once you are done ? so scripts and tools using it donw need to be ported
[10:27] <\sh> cjwatson: that's what I wanted to say ;)
[10:27] <ogra> *don't
[10:27] <pitti> ogra: oh, of course, as long as there are still rdepends
[10:28] <sebner> pitti: we can keep breaking the archive with switching to wayland if you are feeling bored :D
[10:28] <pitti> ogra: but I hope we can throw it out of the default install in LL at least for Ubuntu (when X gets ported)
[10:28] <pitti> ogra: and I heard that they are porting solid as well, so perhaps Kubuntu can drop it soon, too
[10:28] <ogra> thats fine, i'm just to lazy to port usb-imagewriter :P
[10:28] <pitti> sebner: heh
[10:29] <lesshaste> hi.. I have a firefox problem where it freezes when uploading files... The strace at http://pastebin.com/f118d9b2e seems to actually imply it's an X server problem as firefox is waiting for something from the server which never arrives
[10:29] <lesshaste> any tips on how to report this usefully?
[10:29] <StevenK> sebner: And X.org input detection. Which is somewhat important
[10:30] <StevenK> But only if you care about mouse movement and typing. And who needs those?
[10:30] <lesshaste> the important part starts at line 1770
[10:30] <ogra> StevenK, speech input FTW ?
[10:30] <StevenK> ogra: Absolutely.
[10:31] <StevenK> ogra: Then IRC gets filled with "um", "er" and "ar" a lot
[10:31] <sebner> StevenK: cards ftw! or you accept my suggestion moving to wayland *hrhr*
[10:31] <ogra> StevenK, and my neighbors will be annoyed :)
[10:35] <al-maisan_> pitti: I do see various lshal info.capabilities entries that lists input.keyboard, input.keys and input.mouse
[10:35]  * al-maisan_ tries starting gdm again
[10:36] <pitti> al-maisan_: ok; can you check /var/log/Xorg.0.log for input device errors?
[10:36] <pitti> $ grep hal /var/log/Xorg.0.log
[10:36] <pitti> I get ~ 10 lines, like
[10:36] <pitti> (II) config/hal: Adding input device AT Translated Set 2 keyboard
[10:36] <pitti> (II) config/hal: Adding input device Logitech USB-PS/2 Optical Mouse
[10:36] <Laney> soren: did you come back?
[10:37] <al-maisan_> pitti: it works now .. for whatever reason .. so after booting to the console I did: start dbus; start hal; start gdm
[10:42] <TheMuso> slangasek: Just role them when things are ready to be roled, i.e when preparation of disks for everything starts. I just wanted to get that kernel in.
[10:42] <pitti> al-maisan_: I guess "started hal" is not enough; hal needs a second or two to detect everything
[10:42] <pitti> al-maisan_: I guess "start hal; start gdm" fails, but "start hal; sleep 2; start gdm" works?
[10:44] <soren> Laney: Yes. What's up?
[10:44] <Laney> soren: Just checking - I dist-upgraded and didn't come back...
[10:44] <YokoZar> pitti: is it possible hal could get held up for a bit and break when 2 seconds aren't enough?
[10:45] <soren> Laney: but.. you're... here..?
[10:45] <Laney> laptop
[10:45] <pitti> YokoZar: I think the correct solution would be for hal to emit an upstart signal when it's done detecting
[10:45] <pitti> Keybuk: ^
[10:45] <YokoZar> pitti: Yeah that was my thought as well
[10:45] <pitti> and then the rest (like gdm) can depend on that/
[10:45] <StevenK> start on hal-ready (or something), right?
[10:45] <pitti> Keybuk: is there an example how C code would send an upstart signal that gdm etc. could depend on?
[10:46] <YokoZar> And if hal fails catastrophically and never releases the signal bootup probably should be blocked...
[10:46] <pitti> I guess it's just a d-bus call
[10:51] <slangasek> TheMuso: my point is I'm /already/ rolling other images, while the linux-rt kernel is (AFAIK) not ready in the archive yet
[10:52] <slangasek> hmm. wasn't really /looking/ to reboot just then, but didn't go too badly all things considered
[10:52] <slangasek> but dbus is definitely a problem here as well
[10:55] <ion> keybuk: What do you mean by not caring about what udev thinks? What would we do differently?
[10:56] <al-maisan_> pitti: sorry, was in a phone conversation, yes, there was a pause between "start hal" and "start gdm" since I was doing the lshal checks and queries.
[10:56] <ion> ogra: Dear aunt, let's set so double the killer delete select all.
[10:57] <al-maisan_> pitti re. the /var/log/Xorg.0.log input device errors: I get these as well.
[10:57] <pitti> al-maisan_: errors?
[10:58] <pitti> tjaalton: oh, in fact current live systems do have a working "vmmouse" like behaviour; so perhaps -vmmouse is indeed obsolete?
[10:59] <pitti> tjaalton: oops, ignore me; that was my workaround with "-usb -usbdevice tablet"
[11:00] <tjaalton> pitti: evdev works for the most part, but it doesn't feel "integrated" like with vmmouse, AIUI
[11:00] <al-maisan_> pitti: http://pastebin.com/m16b6a3de
[11:00] <pitti> tjaalton: yes, it works with clicking/releasing the lock
[11:02] <slangasek> does upstart log things anywhere/
[11:02] <cdE|Woozy> sometimes kms is failing on intel with the latest updates. it seems that drm is loading before agpgart-intel was loaded: http://pastebin.ubuntu.com/271986/
[11:02] <slangasek> tjaalton: what's the best way to force modes for a VGA device that's not passing EDID?
[11:03] <pitti> al-maisan_: hm, if it doesn't work with that, it's out of my knowledge, I'm afraid
[11:07] <al-maisan_> pitti: sorry for not being clear enough .. everything works fine after issuing the manual start command sequence from the console. Thank you very much for helping me out!
[11:07] <pitti> al-maisan_: ok, you're welcome
[11:10] <slangasek> al-maisan, \sh: bug #430611
[11:13] <al-maisan> slangasek: thanks!
[11:14] <cjwatson> definitely a messy startup, but it does at least work for me ...
[11:15] <\sh> slangasek: bingo :)
[11:20] <cjwatson> people having dbus start problems: do you by any chance have /var on a separate filesystem?
[11:20] <cjwatson> just a hunch, could be wrong
[11:21] <\sh> cjwatson: nope
[11:21] <slangasek> cjwatson: yes
[11:21] <cjwatson> drat
[11:21] <slangasek> oh, wait
[11:21] <slangasek> no
[11:21] <\sh> slangasek: do you have also some strange udev messages in /var/log/syslog like udevd[3227]: NAME="%k" is superfluous and breaks kernel supplied names, please remove it from /lib/udev/rules.d/40-ppc.rules:3
[11:21] <cjwatson> I was wondering about the pre-start script
[11:21] <slangasek> I do have cryptsetup
[11:21] <cjwatson> \sh: everybody has those, but they're fairly harmless
[11:21] <cjwatson> for the moment anyway
[11:22] <\sh> cjwatson: ok...I never saw them before...so I'm curious :)
[11:22] <cjwatson> it's a new warning in the new upstream release of udev that hasn't been handled in all the rules yet
[11:22] <cjwatson> mentioned in the changelog, even ...
[11:23] <slangasek> speaking of warnings, upstart-job and I are going to be having words
[11:23] <cjwatson> the whine if you use invoke-rc.d?
[11:24] <slangasek> yes
[11:24] <cjwatson> \sh: what does 'dbus-uuidgen --ensure; echo $?' say, run as root?
[11:24] <ior3k> do these dbus problems happen only on boot time? Or everytime?
[11:24] <slangasek> and the improper emulation of init script "start" - it can obviously do its own darn status check to make the invocation a no-op
[11:24] <slangasek> ior3k: what other time is there?
[11:24] <\sh> cjwatson: 0
[11:25] <cjwatson> oh well
[11:25] <slangasek> ior3k: it's a problem with dbus not starting - boot time is about it :)
[11:25] <ior3k> slangasek: I mean, dbus may not start on boot, but start manually afterwards
[11:25] <al-maisan> cjwatson: I do have /var on a separate partition
[11:25] <slangasek> ior3k: no, it is possible to start it by hand
[11:26] <\sh> cjwatson: I have to revert my answer to "/var on a separate partition" the correct answer is "yes" and actually it wasn't mounted
[11:26] <ior3k> slangasek: is it possible to rig the dbus init script with strace?
[11:26] <ior3k> slangasek: would that help debugging?
[11:27] <slangasek> ior3k: I don't know if it would; since upstart does service supervising, running it under strace changes the parameters
[11:28] <slangasek> (not my first choice for debugging something in early boot, but someone can try it if no other fixes present themselves...)
[11:28] <cjwatson> I wonder if mountall needs to emit a special event to say that /var/run has been mounted
[11:29] <cjwatson> or if it would be ok to have dbus 'start on local-filesystems' rather than virtual-filesystems
[11:30] <slangasek> where are those signals defined?
[11:30] <cjwatson> as in documentation, or as in code?
[11:30] <slangasek> documentation
[11:30] <cjwatson> they're emitted by C code in mountall ...
[11:30] <cjwatson> slangasek: *hollow laugh*
[11:30] <squirrelpimp> the mute-button on the thinkpad stopped to work after the last round of updates
[11:31] <squirrelpimp> there are lots of bugreport related to the mute button, but it worked as expected before the updates so i'm note sure against which packge to file the bug
[11:31] <slangasek> I wonder whether this is connected to my inability to rebuild mountall due to testsuite failures
[11:31] <slangasek> oh, wait
[11:31] <slangasek> I need to suppress dh_auto_test :P
[11:32] <squirrelpimp> never mind, i found a workaround
[11:32] <cjwatson> slangasek: that's always reassuring
[11:36] <tjaalton> slangasek: https://wiki.ubuntu.com/X/Config/Resolution has some optional ways to force the resolution
[11:36] <cjwatson> /var/run *should* be considered virtual, though
[11:38] <cjwatson> oh, /var/lib/dbus/machine-id
[11:39] <cjwatson> slangasek: try 'start on local-filesystems' in the dbus job?
[11:56] <slangasek> cjwatson: in my case that's on the rootfs, though; and dbus-uuidgen appears to only open it for reading
[11:57] <slangasek> cjwatson: OTOH, I do have */usr* on a separate partition
[11:58] <slangasek> so yeah, I'll test
[11:59] <slangasek> (testing with local-filesystems; if that fixes it, is that the right signal to use?  What if /usr is on NFS?)
[12:00] <cjwatson> it's not obvious is it
[12:02] <cjwatson> really, we ought to make dbus work when only virtual filesystems are available
[12:02] <cjwatson> especially with upstart depending on it
[12:02] <cjwatson> or quasi-depending anyway
[12:11] <slangasek> cjwatson: hah - well, that makes a difference, at least...
[12:11] <slangasek> cjwatson: I did another test boot w/o changing first, and I get "dbus died w/ 127, respawn"
[12:11] <slangasek> cjwatson: then I changed it to local-filesystems... and I get no attempt to start dbus at all
[12:12] <slangasek> because mountall never emits the signal, AFAICS
[12:12] <cjwatson> wuh
[12:12] <cjwatson>         if ((! local_triggered) && (num_local_mounted == num_local)) {
[12:13] <cjwatson>                 nih_info ("local finished");
[12:13] <cjwatson>                 emit_event ("local-filesystems");
[12:14] <slangasek> does it track noauto filesystems sanely?
[12:15] <slangasek> also: bwuh, what decided to rewrite my fstab yesterday and put UUIDs in place of my already-unique lvm names
[12:15] <cjwatson> it's supposed to, see cleanup
[12:15] <pitti> meh, /etc/init/gdm.conf doesn't check for "text" any more
[12:15] <cjwatson> I wonder about remount handling though
[12:16] <cjwatson> maybe arrange for mountall to run with --debug?
[12:17] <slangasek> where does it debug to?
[12:18] <slangasek> pitti: "text"?
[12:18] <cjwatson> syslog, if daemonised
[12:20] <slangasek> al-maisan: would you be able to help with testing this further?
[12:20] <slangasek> 4am here, brain not worky
[12:20] <al-maisan> slangasek: yes, sure.
[12:21]  * al-maisan fetches the other laptop from the living room
[12:22] <slangasek> I can probably do one more test here, but black BIOS screen is making me sleepy
[12:24] <al-maisan> slangasek: what package do I need to upgrade in order to perform the test?
[12:24] <davmor2> slangasek: sleep they'll be a re-spin
[12:24] <cjwatson> al-maisan: up-to-date everything, edit /etc/init/mountall.conf to add --debug to mountall's command-line parameters, reboot, look in syslog
[12:25] <al-maisan> cjwatson: thanks
[12:30] <cjwatson> Keybuk: so, for converting the ubiquity init script to upstart - how do I arrange for gdm to *not* start until ubiquity has completed?
[12:38] <cjwatson> Keybuk: also, how do I say "start once service foo has started, but if service foo is not present on the system then don't worry about it"?
[12:42]  * cjwatson wonders how the current set of upstart jobs handle the case where a package is removed but not purged
[12:43] <slangasek> cjwatson: aha - ldd /bin/dbus-daemon | grep /usr
[12:43] <al-maisan> cjwatson: here's the syslog excerpt: http://pastebin.com/m72c830db
[12:44] <cjwatson> slangasek: ah - ok, I can deal with that
[12:45] <slangasek> and the reason for not emitting the signal here is that I have a filesystem referenced as /dev/VG/LV syntax instead of /dev/mapper/VG-LV, which isn't getting handled
[12:45] <cjwatson> hmm, nothing from mountall in that syslog
[12:45] <cjwatson> (phone)
[12:45] <slangasek> I expect the signal will be emitted for people not having that particular problem
[12:47] <slangasek> ok, sleeping now
[12:47] <slangasek> 'night
[12:47] <al-maisan> slangasek: good night.
[12:48] <al-maisan> cjwatson: I did add '--debug' after 'exec mountall' in /etc/init/mountall.conf
[12:48] <al-maisan> I think there was some extra output but it scrolled by too fast on the console .. sorry
[12:50] <al-maisan> Shift-PageUp does not work
[13:13] <cjwatson> Keybuk,lamont: udev successfully built on powerpc now
[13:13] <Keybuk> oh, neat
[13:16] <lamont> \o/
[13:21] <ogra> Keybuk, is there any documentation how to transition stuff that uses chroots and VMs and invokes initscripts or calls invoke-rc.d to the new model ?
[13:21] <ogra> (i have various tools and scripts that will need chnages i guess ... i.e. ltsp, rootstock etc)
[13:22] <kagou> hello
[13:22] <ogra> and i guess our vitual builder tools might need to see some changes too
[13:22] <Keybuk> upstart doesn't work with chroots
[13:23] <ogra> but in vm's i guess
[13:23] <Keybuk> this is one main reason I haven't changed anything that you _can_ run in a chroot
[13:24] <ogra> i.e. in rootstock i fire up a VM after a first stage bootstrap to call the second stage and install whaever the user selected... in this vm i only fire up the bare minimum of initscripts to just make the vm work enough for the task ...
[13:25] <ogra> is there a way to have something like a "minimal profile" upstart could use in that case
[13:34] <ogra> stgraber, ^^^ the above will massively affect ltsp
[13:36] <doko> hmm, boot is somewhat broken: init: sreadahead main process () terminated with status 1, and system hangs
[13:37] <ogra> doko, you didnt upgrade today, did you ?
[13:37] <directhex> doko, /topic
[13:37] <doko> ogra: I did
[13:37] <ogra> ouch
[13:39] <pitti> doko: does it really hang forever? mine just powers down display, and gdm eventually appears after a second
[13:39] <doko> pitti: now hangs for 5min
[13:39] <pitti> ok, so that's not that then
[13:39] <pitti> erm, s/after a second/after a minute/, of course
[13:40] <lamont> cjwatson/Keybuk: does karmic need/want the change for debian bug 546834?  is it even an issue for karmic+1?
[13:40] <doko> messages before that are: "Begin: Running /scripts/init-bottom ..." and "Done."
[13:40] <Keybuk> lamont: shouldn't think so, we don't use insserv
[13:41] <lamont> yay
[13:41] <Keybuk> doko: try with --debug
[13:42] <doko> Keybuk: as kernel option?
[13:47] <dpm> dut
[13:48] <Keybuk> doko: yes
[13:49] <lamont> Keybuk: and I pulled your branch and pushed my tree.  how much / which of -1ubuntu2 do I need to pull over to debian?
[13:50] <Keybuk> lamont: which was -1ubuntu2 ?
[13:50] <Keybuk> I wouldn't pull any of the upstart stuff for now
[13:50] <Keybuk> you may want the versionsort() patch though
[13:50] <lamont> ok.  there was also a "newer glibc" prototype change
[13:50] <lamont> ah.
[13:50] <lamont> yeah that
[13:50] <sebner> Keybuk: can the boot considered faster now after all the bunch of updates?
[13:50] <Keybuk> but then that didn't even look like it was used at all
[13:50] <lamont> and does that work with older glibc too?  (as in sid?)
[13:50] <Keybuk> sebner: it seems to depend
[13:51] <Keybuk> sebner: for me, X comes up 7s faster
[13:51] <Keybuk> but for other people, X doesn't come up at all ;)
[13:51] <Keybuk> and on some HDD-based machines, it's exactly the same speed
[13:51] <Keybuk> *but*, and here's the important thing, if this model does work
[13:51] <Keybuk> it puts us in a better place for karmic+1
[13:51] <Keybuk> because this was the "hard change"
[13:52] <sebner> Keybuk: kk, here it seems to be same speed
[13:52] <Keybuk> sebner: do you have before/after bootcharts ?
[13:54] <sebner> Keybuk: sure but the bootchart from this morning might not be useful since I didn't get all of the updates. I installed some others after the builds worked again (mountall manually from LP), this even booted up ^^
[13:55] <Keybuk> I mean of your boot before any of the updates
[13:56] <doko> Keybuk: anything special to look for?
[13:56] <sebner> Keybuk: sure, sec
[13:56] <Keybuk> doko: can you take a picture and send it me ? :)
[13:56] <Keybuk> doko: otherwise the last virtual 4/5 line is useful
[13:56] <doko> Keybuk: ok
[13:58] <ion> keybuk: What do you mean by not caring about what udev thinks? What would we do differently?
[13:58] <sebner> Keybuk: the updates started yesterday right?
[13:58] <Keybuk> ion: mountall checks that ID_FS_USAGE=filesystem
[13:59] <Keybuk> ion: so if there's multiple meta-data in the block device, it ignores it
[13:59] <Keybuk> ion: for "simple" block devices, that's not really necessary
[14:00] <stgraber> ogra: yeah, I'll need to do some real testing quite soon
[14:00] <mterry> In MainInclusionReportTemplate, there's the sentence "Who is the package bug contact in Ubuntu? (Needs one if its a nontrivial package which does not fully maintain itself through Debian)".  Can we scratch the parenthetical?  Seems like we always want a bug contact
[14:00] <stgraber> ogra: as soon as my laptop starts working again ;)
[14:00] <cjwatson> mterry: the parenthesis is there for a reason, and should be left in
[14:00] <ogra> stgraber, i guess we have to drop all the rc.d script mangling
[14:01] <sebner> Keybuk: http://img147.imageshack.us/i/ubuntukarmic200909151.png/  , the day before this log it booted with 39 sec's though. A clean jaunty install boots in 18 secs though. Using karmic since the beginning
[14:01] <mterry> cjwatson, that's what I was asking for.  I just couldn't think of a situation where we'd want bug reports being filed that never get looked at
[14:01] <ogra> stgraber, and i dont know what ltsp-client-setup and ltsp-client-core initscripts have to look like in the new worldorder, but i guess Keybuk can help with them
[14:01] <Keybuk> sebner: err is this chart the "before" or "after" ?
[14:01] <ion> keybuk: Wouldn’t that mean writing additional special-case code? Now we have a single code path that works for everything. Isn’t that better?
[14:01] <cjwatson> mterry: we'd always *like* a bug contact, but it's not mandatory for main inclusion if the package is trivial and maintained well in Debian
[14:01] <Keybuk> ogra: just leave them as they are?
[14:01] <sebner> Keybuk: should be before
[14:01] <Keybuk> ion: no, just a change to the "if" statement in the udev watcher
[14:01] <ogra> Keybuk, if they work :)
[14:01] <Keybuk> sebner: ok, that looks like a before
[14:02] <sebner> heh
[14:02]  * ion looks at the code
[14:02] <sebner> Keybuk: do you also want the "half-upgraded" bootchart from today?
[14:02] <mterry> cjwatson, k..
[14:03] <Keybuk> sebner: if you like
[14:03] <ion> So, if the device name is [hs]d[a-z][1-9], skip the get_property_value stuff?
[14:03] <cjwatson> Keybuk: oh, speaking of which, shouldn't you subscribe to bug mail for mountall? :)
[14:03] <Keybuk> ion: just skip the usage check
[14:03] <Keybuk> cjwatson: yes
[14:03] <cjwatson> mterry: basically, it's a bug if nobody's subscribed, but not all bugs are critical
[14:04] <sebner> Keybuk: http://img11.imageshack.us/i/ubuntukarmic200909161.png/
[14:04] <Keybuk> sebner: ok, and the full upgrade chart?
[14:04] <mterry> cjwatson, yar.  I've just been influenced by jorge's exhortations to fill those gaps  :)
[14:05] <sebner> Keybuk: haven't rebootet yet
[14:05] <Keybuk> sebner: coward
[14:05] <sebner> Keybuk: :P
[14:05] <ion> keybuk: I might be missing something, but the usage check doesn’t look very expensive.
[14:05] <ion> Just a couple of strcmps
[14:05] <Keybuk> ion: it's not the expense
[14:06] <Keybuk> ion: it's the problem when someone has "/dev/sda1 /boot ext3 defaults 0 2"
[14:06] <Keybuk> but blkid can't tell what filesystem is in /boot
[14:06] <Keybuk> "multiple results returned" kinda thing
[14:06] <Keybuk> mountall won't mount it
[14:06] <Keybuk> even though it doesn't *really* need to check ID_FS_USAGE, because /dev/sda1 doesn't have "change" events
[14:06] <ion> Ah, ok
[14:06] <sebner> Keybuk: I'll reboot and if it breaks I'll hunt you :P
[14:06] <Keybuk> (we check that because mdX and dmX *do* change, and need to be repeatedly checked until they contain a valid filesystem)
[14:07] <Keybuk> sebner: take a ticket, join the queue ;)
[14:07] <ion> I see
[14:07] <sebner> Keybuk: does that mean that it'll surely break? :P
[14:07] <ion> How about when UUID or LABEL is used and they mean sda1?
[14:07] <Keybuk> sebner: WFM :)
[14:08] <pitti> Keybuk: is it normal/expected that at shutdown I see a series of "rc init SIGSTOP", "sreadahead SIGSTOP", "rc init SIGCONT", "sreadahead SIGCONT"?
[14:08] <Keybuk> ion: then obviously for those we check usage ;)
[14:08] <Keybuk> pitti: yeah
[14:08] <pitti> ok
[14:08] <Keybuk> pitti: sendsigs has been doing that weird shit for a while
[14:12] <sebner> Keybuk: no uplash, loads of udev warnings, but takes longer but it booted up :P
[14:12] <Laney> is the archive stable yet?
[14:13]  * Laney is wondering what the best way to recover is
[14:14] <sebner> Laney: rockstable :D
[14:14] <Laney> in terms of uploads/publishing
[14:15] <sebner> Laney: the builds are back to normal too afaik
[14:15] <sebner> Keybuk: http://img406.imageshack.us/i/ubuntukarmic200909162.png/
[14:15] <Laney> mainly I want to get my system back up ¬_¬
[14:15] <Laney> chroot + dist-upgrade?
[14:15] <Keybuk> sebner: wait a minute for sreadhead to go away (status sreadahead)
[14:16] <Keybuk> should say stop/waiting
[14:16] <Keybuk> then reboot again
[14:16] <sebner> Laney: yeah
[14:17] <sebner> Keybuk: rebooting
[14:17] <ogra> Keybuk, fyi, armel imx51 (babbage) still boots fine :)
[14:18] <ogra> i see a udev message on boot though, but i think that was mentioned here before
[14:18] <ogra> ("symlink" in a udev rule)
[14:18] <Keybuk> right
[14:18] <Keybuk> we're testing udev GIT HEAD
[14:18] <Keybuk> kay and I will do a release next week when we're in Portland
[14:19] <ogra> well, as long as it works i dont care
[14:19] <ogra> i'm just sad i cant hide the messages behind a splash atm :P
[14:20] <cjwatson> Keybuk: what's the best way to ask users to get debug information out of mountall? edit /etc/init/mountall.conf and add --debug?
[14:20] <Keybuk> cjwatson: yes
[14:21] <sebner> Keybuk: http://img193.imageshack.us/i/ubuntukarmic200909163.png/
[14:22] <Keybuk> sebner: odd, you have a dead sreadahead as well
[14:23] <sebner> Keybuk: that means?
[14:24] <Keybuk> don't know yet
[14:27] <sebner> Keybuk: as my system boots this doesn't mean it's purely bad. :P
[14:27] <doko-netbook> Keybuk, http://people.canonical.com/~doko/tmp/IMG_0892.JPG
[14:27] <ion> 403
[14:29] <cjwatson> Keybuk: any reason mountall doesn't just do nih_log_set_logger more or less up top if it's going to daemonise? it'd make debugging rather easier ...
[14:30] <Keybuk> cjwatson: wouldn't make any difference, surely?
[14:30] <cjwatson> it'd arrange for all the stuff from new_mount, cleanup, etc. to go to syslog
[14:30] <cjwatson> which is before daemonisation
[14:30] <ion> I wonder if rsyslog could be easily patched so that it could be started before a writable anything, and it would buffer stuff until it can dump them to syslog et al?
[14:31] <ion> Similarly to logsave from e2fsprogs
[14:31] <kagou> with 20090916 daily-live amd64, I install system, but at reboot -> screnn go black and system freeze :( To wich package I report the bug ? Or should I wait for tommorrow iso ?
[14:32] <kagou> bug came clearly from new boot system
[14:32] <Keybuk> cjwatson: except syslog isn't running ;)
[14:32] <cjwatson> Keybuk: oh, heh
[14:32] <Keybuk> cjwatson: which is why you normally send all that to stderr before you daemonise ;)
[14:33] <cjwatson> fair enough
[14:33] <Keybuk> ion: that's the plan for Upstart itself
[14:34] <Keybuk> just buffer stdout/stderr of processes
[14:34] <ion> Perhaps a command to dump the rsyslog buffer to stdout, so you could less(1) the so-far logged stuff even before it has been able to save them.
[14:34] <Keybuk> then, if they fail, toss the log somewhere useful
[14:34] <Keybuk> kinda like cron does
[14:34] <ogra> Keybuk, oh ... http://www.mirror.co.uk/news/technology/2009/08/28/sharp-netwalker-the-future-of-netbooks-115875-21631914/ ... "Sharp reckon that the Ubuntu OS should be able to boot in under 3 seconds"
[14:34] <ion> Alright
[14:34] <Keybuk> apache failed, *and here's what it said*
[14:34] <ogra> Keybuk, and you still test with a dell mini, tsk
[14:34] <Keybuk> ogra: only if you use a different display engine than X
[14:35] <ogra> i think its X on framebuffer
[14:35] <ogra> like the babbage
[14:35] <Keybuk> yeah, never going to be 3s then ;)
[14:35]  * Keybuk will dance on X's grave when we get a proper display engine
[14:36] <ogra> but their marketing said so, it *must* be true :P
[14:37] <cjwatson> and the Mirror, no less a well-regarded publication filled with superb journalistic standards
[14:37] <sebner> Keybuk: wayland!
[14:37] <ogra> heh
[14:37] <Keybuk> sebner: we played with wayland a while back
[14:37] <Keybuk> doko: still 403
[14:37] <sebner> Keybuk: really, when? too earler stage I suppose?
[14:37] <Keybuk> sebner: you can get Dell Mini to boot in 3s with that
[14:37] <sebner> O_o
[14:38] <sebner> want have!
[14:38] <Keybuk> I can make an Ubuntu Appliance boot in 1s
[14:38] <Keybuk> it's just not very interesting
[14:38] <ion> But you can ping localhost!
[14:38] <Keybuk> (a device with a hardwired kernel, and a framebuffer, that launches a single framebuffer application)
[14:38] <Keybuk> but that's all you need for a tomtom or something
[14:39] <ogra> which you dont boot anyway
[14:39] <ogra> only once or if power runs out
[14:39] <ogra> the rest of the time you only suspend
[14:40] <ScottK> TomTom takes longer than that to start.  Maybe they need lessons.
[14:40] <ogra> start or resume ?
[14:40] <sebner> ScottK: ahh! pssst or Keybuk gets bought by TomTom!
[14:41] <doko> Keybuk: fixed
[14:41] <ScottK> ogra: Start.
[14:41] <ogra> my gps takes about three minutes to boot (its wince based though) but is instant on/off for suspend/resume
[14:41] <ScottK> suspend/resume is ~2 or 3 seconds.
[14:42] <Keybuk> ogra: of course you boot them
[14:42] <loic-m> mvo_: how does one gets an app translated description + screenshot in so they get shown in software-store?
[14:42] <ogra> once
[14:42] <Keybuk> why would you suspend a satnav?
[14:43] <mvo_> loic-m: screenshot> not at all at this point
[14:43] <ScottK> Keybuk: I assume the on/off button does suspend/resume.  It certainly isn't shutdown/start.
[14:43] <Keybuk> doko: that's quite odd
[14:43] <loic-m> mvo_: you mean this point in Karmic dev cycle, or they're not handled by s-s?
[14:43] <ogra> Keybuk, mine survives a week if its suspended ... and in car it's attached to the cigarette lighter and recharges ... why would i shut it down ?
[14:43] <mvo_> loic-m: translation> via ddtp and the app-install-data template
[14:44] <ScottK> doko: Is there any reason not to make celementtree go away now?
[14:44] <mvo_> loic-m: screenshots can not be localized in the karmic cycle
[14:44] <Keybuk> doko: that's very odd
[14:44] <doko> ScottK: go ahead!
[14:44] <ScottK> OK.  I can work on that.
[14:44] <Keybuk> doko: it looks like udev isn't running
[14:45] <Keybuk> doko: could you add an /etc/init/shell.conf with something like "start on startup" "console owner" "exec /bin/bash" and boot with that
[14:45] <Keybuk> that'll give you a shell to do some debugging with
[14:45] <loic-m> mvo_: sorry, for the screenshot I wasn't thinking about localised one, but about including one for app where it's missing
[14:45] <mvo_> loic-m: oh, sorry. I misunderstood. that can be done via screenshots.debian.net
[14:46] <mvo_> loic-m: before the final release we need to move that to scrrenshots.ubuntu.com though
[14:46] <mvo_> (but that may be just a re-direct)
[14:46] <loic-m> mvo_: and if the app isn't in Debian?
[14:48] <mvo_> loic-m: that is not possible right now, I hope to get this resolved in time
[14:49] <mvo_> loic-m: but currently we rely on the debian service here, also christop haas expressed willingness to help us
[14:50] <loic-m> mvo_: for ddtp, that means translating through launchpad, doesn't it? No way to just include it in the package? And does it work for packages in universe?
[14:50] <mvo_> loic-m: for ddtp there is no way to include it in the package itself. it does work for universe, if it does not, let me know, then there is a bug in the code somewhere. but it does for the cases I looked at
[14:52] <loic-m> mvo_: Ok. It's just that going through launchpad means you need to hope the locale team ever validates it, which can never happen, and is a shame when you're also upstream translator
[14:52] <doko> Keybuk: is this config file picked up automatically?
[14:52] <mvo_> loic-m: oh, hm :( that is bad. there is a way by going via ddtp.debian.net
[14:53] <mvo_> loic-m: but that requires review as well, not sure how quickly tha thappens
[14:53] <ogra> doko, upstart reads the stuff in /etc/init
[14:53] <doko> ahh, it is
[14:53] <mvo_> loic-m: is there anything in LP that we can do to make it smoother?
[14:54] <doko> Keybuk: yes, hal is not running
[14:54] <Keybuk> doko: yes
[14:54] <Keybuk> doko: hal should not be running yet
[14:54] <loic-m> mvo_: not sure what you can do. Best would be a way to get this from upstream package, or untill it's possible to grab the email of upstream translator and let him translate ;)
[14:54] <Keybuk> doko: could you join #ubuntu-boot, it's too noisy in here
[14:57] <mvo_> loic-m: I proposed a new design for this to translations.launchpad.net so that the package descriptio nwould be put alongside the regular translation as a additional pot file. this way the same permission would apply as for the upstream translation. but unfrotunately it did not get implemented (yet?)
[15:02] <loic-m> mvo_: didn't know that. Can't find the link, do you have it by any chance?
[15:07] <mvo_> loic-m: https://blueprints.launchpad.net/rosetta/+spec/native-package-descriptions-support
[15:09] <loic-m> mvo_: thanks a lot, I'll follow it. Best would be a freedesktop thing so upstreams just include a general description in the list of files gettext/whatever proccesses.
[15:10] <cjwatson> WTF, +filebug redirects to help.ubuntu.com?
[15:10] <cjwatson> damnit, there are some cases where ubuntu-bug is no use at all
[15:10] <cjwatson> stupid stupid stupid
[15:11] <james_w> +filebug?no-redirect
[15:11] <cjwatson> thanks
[15:11]  * cjwatson smart-bookmarks since obviously the UI has decided that helpfulness is for other people
[15:12] <pitti> cjwatson: hm, where? I still used +filebug this noon on edge
[15:13] <cjwatson> on edge just now
[15:13] <cjwatson> https://edge.launchpad.net/ubuntu/+source/mountall/+filebug
[15:22] <Laney> there was a mail about it to u-d-d but I thought it was just for "Ubuntu"
[15:23] <ogra> lol
[15:23] <ogra> Keybuk missed to remove usplash on usplash_down
[15:25] <AnAnt> I don't understand Keybuk's dh_installinit changes (that was mentioned in last foundations report)
[15:27] <nixternal> any idea on what I have to do in order to get my machines with encrypted drives up and running?
[15:44] <al-maisan> nixternal: that's fairly vague question :)
[15:44] <nixternal> not if you are running karmic it isn't
[15:46] <al-maisan> nixternal: OK, so.
[15:58]  * ogra humps Keybuk's leg
[15:58] <ogra> Keybuk, i have never seen a babbage board boot that fast !
[15:58] <ogra> Keybuk, though dbus crashed on first boot
[16:00] <robbiew> lol
[16:00] <ogra> it works wonderful on second
[16:02] <robbiew> ogra: does bootchart work on babbage boards?
[16:02] <robbiew> would be cool to see it
[16:03] <kirkland> Keybuk: the avahi-daemon upstart job isn't starting the daemon on the alpha6 server
[16:03] <ogra> its running since 10min
[16:03] <ogra> generating the image is very slow
[16:03] <robbiew> ah, right
[16:03] <kirkland> Keybuk: this is causing the UEC node installs to not detect the cloud-controller on the network
[16:03] <kirkland> Keybuk: how do i go about debugging this?
[16:03] <kirkland> Keybuk: or is it a known issue?
[16:10] <kirkland> Keybuk: actually, i can't get avahi-daemon to start at all, even manually
[16:10] <kirkland> Keybuk: the upstart job throws a PID back at me
[16:10] <kirkland> Keybuk: but it's gone by the time i look at ps
[16:10] <kirkland> Keybuk: and there's no daemon running
[16:12] <ogra> robbiew, Keybuk http://people.canonical.com/~ogra/babbage2-karmic-20090916-2.png (down from 90sec)
[16:13] <Keybuk> ogra: you have the strange exe
[16:13] <Keybuk> ogra: if you reboot it again, do you get down to 38s?
[16:13] <ogra> no, i got from 54 to 45 already
[16:13] <ogra> and as i said, very first boot after install crashed dbus
[16:14] <ogra> and i dont have the right keymap atm
[16:22] <ogra> Keybuk, GEEZ ! http://people.canonical.com/~ogra/babbage2-karmic-20090916-3.png
[16:22] <ogra> you are right, it gets faster with every boot
[16:25] <Keybuk> ogra: you *still* have that strange exe though ;)
[16:25]  * Keybuk has no idea what that is
[16:25] <Keybuk> don't suppose you have the .tgz from that latest bootchart
[16:26] <ogra> i have all three :)
[16:26] <Keybuk> could you mail me the latest one
[16:26] <ogra> sure
[16:28] <ogra> Keybuk, on its way
[16:28] <kirkland> Keybuk: hmm, i see a new avahi upload since the last iso spin; i'm upgrading to that now
[16:29] <cagonto> online boxing game http://www.kobox.org/kobox-fande-Nourine.html
[16:29] <Keybuk> that looks like a link to my INBOX
[16:29] <kirkland> Keybuk: hmm, that seems to have fixed that problem
[16:34] <cjwatson> \sh: can you upgrade to current libexpat1 and dbus and see if that fixes things for you?
[16:35] <kirkland> cjwatson: i'm installing a UEC node...  it's trying to fetch the node-preseed file by ipv6 address;  is that expected?
[16:35] <cjwatson> al-maisan: ^-
[16:35] <cjwatson> kirkland: I don't know
[16:35] <kirkland> cjwatson: okay, thanks.
[16:35] <cjwatson> kirkland: in my last test the cloud controller was only listening on IPv6; I adapted some things to cope, but didn't investigate why
[16:36] <kirkland> cjwatson: hmm, my -cc is definitely listening on ipv4
[16:36] <mterry> Keybuk, so I lied, rsyslog should handle HUPs, but I don't think the current /etc/init.d/rsyslog handles reloads.  It handles restarts...
[16:37] <kees> Keybuk: apparmor needs to start much sooner (it's starting after avahi, for example)
[16:37] <al-maisan> cjwatson: will do.
[16:38] <Keybuk> kees: we need to work out apparmor
[16:39] <kees> Keybuk: same for urandom, looks like it's started after network services that might be using the seed
[16:40] <Keybuk> shall we look at apparmor next week?
[16:40] <Keybuk> we can work it out in person then
[16:40] <kees> Keybuk: yes please.  :)
[16:40] <Keybuk> I think I have something in mind that's quite elegant, but want to make sure it works for you
[16:42] <pitti> ogasawara: bug 193970 is back (seems this breaks again with each and every release); given its size, should I rather open a new bug or reopen this one?
[16:42] <al-maisan> cjwatson: yep, my machine boots perfectly now!
[16:44] <ogasawara> pitti: lets open a new one to minimize the noise
[16:44] <pitti> ogasawara: ok
[16:45] <pitti> ogasawara: what should I do to put it back on the radar? is "regression-potential" enough?
[16:45] <pitti> ogasawara: I guess the old patch still applies, but keeps getting dropped or so..
[16:45] <kees> Keybuk: whatcha thinkin'?
[16:45] <ogasawara> pitti: yup tag it "regression-potential" and also let me know the bug # and I'll get it on our list
[16:45] <Keybuk> kees: I'm assuming that you have two groups of apparmor profiles
[16:45] <Keybuk> profiles for particular services
[16:46] <Keybuk> and generic profiles
[16:46] <kees> kind of
[16:46] <Keybuk> for the generic, we need something that loads them like the init scripts
[16:46] <Keybuk> but for service profiles, we could so something clever
[16:46] <Keybuk>   start on starting
[16:46] <Keybuk>   exec [ -f /etc/apparmor.d/init/$JOB ] && load_ze_profile
[16:46] <Keybuk> that way, if you dropped anything in that directory that had the same name as a service in /etc/init
[16:46] <Keybuk> it would be automatically loaded *before* that service
[16:47] <Keybuk> if you added an /etc/apparmor.d/init/sreadahead, then it's automatically used, etc.
[16:47] <Keybuk> maybe it's not how things work
[16:47] <Keybuk> but it's a nice idea if it is
[16:47] <kees> instead of an "init" subdirectory, why not just look for the daemon name?
[16:47] <Keybuk> that would work too
[16:47] <superm1> pitti, re bug 193970, are you using the dell-laptop kernel module?
[16:48] <Keybuk> though all you have with "starting" is the $JOB name (filename under /etc/init without the dir or .conf)
[16:48] <pitti> superm1: apparenlty
[16:48] <kees> i.e. sreadahead is /sbin/sreadahead, so  exec [ -f /etc/apparmor.d/sbin.sreadahead ] && load_ze_profile
[16:48] <kees> Keybuk: hrm
[16:49] <kees> Keybuk: I see your point, and an init script could contain all kinds of things to confine
[16:49] <superm1> pitti, mjg59 needs to write a patch that inserts an input filter to intercept a keypress of XF86WLAN in dell-laptop kernel module to be able to update dell-laptop's rfkill status
[16:49]  * kees ponders
[16:49] <superm1> (he hasn't yet)
[16:49] <pitti> superm1: hm, how did that work before?
[16:50] <superm1> pitti, dell-laptop was introduced in karmicish kernels
[16:50] <superm1> it's not worked perfectly since introduced because of this deficiency
[16:50] <Keybuk> kees: right
[16:50] <superm1> any other problems with <karmic were different
[16:51] <ScottK> Lovely.
[16:51] <cjwatson> al-maisan: excellent
[16:52] <kees> pitti: any thoughts on bug 422392 ?  This will be needed for security update handling too.
[16:54] <pitti> superm1: ah, thanks; I added that info to the bug report
[16:54] <pitti> ogasawara: it's bug 430809 now, but seems it's not just reapplying the old patch then :-(
[16:55] <pitti> kees: looking
[16:55] <superm1> pitti, mjg59 said two or three days ago when i pinged him that it's "On his list", but he said that two weeks ago when i pinged him too :(
[16:55] <pitti> kees: I agree; incidentally, I already did that some days ago in dk-power :)
[16:56] <nixternal> Keybuk: need any testing help with the latest changes and encrypted drives? they seem to be the only issue I am facing now with the new upstart stuff
[16:57] <Keybuk> nixternal: cryptsetup needs to be ported to use udev rather than an init script
[16:57] <nixternal> groovy, so you are all good then
[16:58] <kees> pitti: oh good!
[16:58] <pitti> kees: if that's really the cause for bug 403192, you deserve a big big hug :)
[16:59] <kees> pitti: well, it's absolutely the cause of it continuing to crash even after it was fixed.  :)
[16:59] <pitti> kees: I keep forgetting that some people never reboot ;)
[16:59] <kees> (where "absolutely" is defined by "totally went away after I restarted dk-disks)
[16:59] <kees> pitti: heh
[17:06] <kees> speaking of never rebooting, I'm now going to reboot with my shiny new keybuk-ified boot process...
[17:07] <ccheney> ogra: ping
[17:08] <doko> Keybuk: start udev does start, then I get hundreds of messages "UNEXPECTED INCONSISTENCY, Superblock last mount time is in the future". after that I can't enter anything, did the fsck, started udev, and gdm did come up
[17:10] <ccheney> ogra: i wonder if the new version of boost could possibly be causing the problem with arm on karmic
[17:10] <ccheney> ogra: boost in jaunty is 1.35 but is 1.38 in karmic, perhaps using 1.35 might help with a karmic build?
[17:12] <ccheney> ogra: unfortunately 1.35 is not in the archive for karmic but is still in jaunty so maybe could be tested by pulling it from there, if you are doing a manual build
[17:13] <kees> hmpf, my resolv.conf was empty.
[17:13] <ScottK> ccheney: We switched to 1.38 right after UDS, so I doubt it's causing anything new.
[17:14] <mathiaz> cr3: hey - planning another upload of checkbox before alpha6?
[17:15] <ccheney> ScottK: i don't know how long OOo has been busted on arm though
[17:15] <kees> Keybuk: so, usplash didn't work, and xsplash didn't work.  how do I fix/debug ?
[17:16]  * ScottK nods.
[17:16] <ccheney> ScottK: its not used all that much so unless the mobile team does regular testing it might still be that
[17:16] <ccheney> ScottK: and afaik the only dist that uses/tests arm much is us
[17:16] <ccheney> ScottK: debian has an arm port but i don't know if anyone actually uses OOo on it
[17:17] <\sh> kees: I read your blog article about removal of sun-java6 ;) one question: does openjdk have already the security manager of sun-java{5,6} (used e.g by tomcat{5,6})?
[17:17] <kees> \sh: dunno -- I think so.
[17:17] <ScottK> ccheney: Also we got some new patches ~recently.
[17:17] <kees> \sh: I don't know how to test it, but I imagine it would stand out if it was missing
[17:17] <\sh> kees: afaik it doesn't because of some strange licensing issues of sun...I could be wrong, but that's why most people use sun-java6 and tomcat6 app server
[17:18] <ion> Removal of sun-java6, huh? A certain major (...ly sucking) Finnish bank seems to require sun-java6 for their web bank interface, openjdk doesn’t seem to work there.
[17:18] <ccheney> ScottK: new patches to boost?
[17:18] <kees> ion: no worries, I suspect sun-java6 will (unfortunately) be staying
[17:19] <cjwatson> Keybuk: would you mind if I turned usplash on for live CDs?
[17:19] <\sh> kees: easy testing: vi /etc/default/tomcat6 -> TOMCAT6_SECURITY=yes, if openjdk has this feature, tomcat6 will start, if not it will break horribly and won't start up properly;)
[17:19] <cjwatson> Keybuk: or do you actively prefer it off at the moment?
[17:19] <ScottK> ccheney: It's a month ago, but a lot more recent than when we switched to it (in May): https://launchpad.net/ubuntu/karmic/+source/boost1.38/1.38.0-6ubuntu3
[17:19] <ccheney> ScottK: ok
[17:21] <ccheney> ScottK: thanks for the pointers, hopefully that will be what caused the problem
[17:26] <kees> \sh: yes, tomcat6 loads with TOMCAT6_SECURITY=yes and openjdk-6
[17:26] <slangasek> cjwatson: fwiw, I tried to turn usplash back on for cryptsetup, and it didn't take; I was going to investigate in a little bit
[17:29] <cjwatson> slangasek: ok, I'll do other more productive things then
[17:29] <jdstrand> kees: iirc, and I am no expert on this, but I thought all the security manager stuff was resolved when they released openjdk. ie, that and a few other things were blockers on it being open and functional
[17:30] <jdstrand> certainly by the time we started using it...
[17:30] <kees> jdstrand: yeah, that's what I thought too, so \sh's test just confirms that.
[17:33] <sivang> hi all
[17:33] <sivang> I want to get a dell notebook, it uses intel gma 950 - will it work with future version of ubuntu other then the one preloaded by dell ?
[17:33] <sivang> is it an open source driver ?
[17:39] <sivang> sorry for the noise, question been answered in #ubuntu
[17:50] <Keybuk> cjwatson: I think it can go on for live cds
[17:50] <Keybuk> cjwatson: assuming you've tested mountall and it doesn't hang on them ;)
[17:51] <nixternal> note to those with encrypted drives: once you get to the shell using the shell.conf you can do '/etc/init.d/cryptdisks start' to get where you need to go :)
[17:52] <nixternal> if that hasn't been mentioned yet of course
[17:57] <nixternal> Keybuk: could I add 'exec /etc/init.d/cryptdisks start' or such to my shell.conf file to automatically continue on instead of having to do it manually?
[17:59] <Keybuk> nixternal: I'm thinking that a short-term solution would be to simply start "cryptdisks" on stopped udevtrigger
[17:59] <Keybuk> it wouldn't fix bugs where you had encrypted disks that took longer than a udevsettle to appear
[17:59] <Keybuk> or encrypted lookback files on NFS
[17:59] <Keybuk> but they never worked before anyway
[17:59] <Keybuk> (whereas unencrypted versions of the above, which didn't work before, now *do* work)
[18:00]  * nixternal needs to read up on upstart
[18:00] <nixternal> I have to say, good work dude under this pressure :)  almost there, and a bit faster too
[18:01] <Keybuk> the "bit" seems to vary wildly
[18:01] <Keybuk> it's 7s faster on the reference hardware
[18:02] <nixternal> hehe, true
[18:02] <Keybuk> something ridiculous like 45s faster on ogra's ARM board
[18:02] <nixternal> it is quite a bit faster, noticeably on my netbook, but I never ran bootchart on it previously
[18:02] <Keybuk> but exactly the same speed on my Dell laptop
[18:03] <ScottK> nixternal: Luckily you've got the reference system.
[18:04]  * ScottK recently hit reboot (also on the 10v) and looked over to see how it was going and was suprised to the the login dialogue staring at me)
[18:04] <nixternal> ya, same here
[18:04] <nixternal> I keep rebooting just to see it go fast :)
[18:05] <robbiew> :)
[18:06] <nixternal> robbiew: hey, I heard my buddy Yosi's kid and yours go to the same school down there in Austin
[18:06] <nixternal> guess your license plate caught his attention :)
[18:07] <jdstrand> Keybuk: hi. I feel like I am missing somthing very obvious. is there a wiki page on the proper way to convert from sysv initscript to upstart?
[18:07] <ScottK> it would be handy if an archive admin with shell access could look at 364630 and sync libchamplain and pyclutter.  They are tied up in a bit of a transitional mess in Universe.
[18:07] <Keybuk> jdstrand: no, no wiki page
[18:07] <ScottK> jdstrand: You have to crawl into Keybuk's head to find out.
[18:07] <cjwatson> jdstrand: 'man 5 init' might help
[18:07] <nixternal> hehe...
[18:08] <Keybuk> also man 7 {start,stop}{ing,ed}
[18:08] <jdstrand> cjwatson, Keybuk: cool, thanks :)
[18:08] <robbiew> nixternal: ;)
[18:10] <Keybuk> jdstrand: files in packaging are named debian/<package>.upstart
[18:10] <Keybuk> and installed by dh_installinit
[18:10] <jdstrand> excellent, thanks
[18:15] <cjwatson> ScottK: will do when I can get mass-sync.py to stop hating me
[18:16] <ScottK> cjwatson: Thanks.
[18:34] <kees> pitti: in one you used killall, in the other you used pidof + kill.  any reason?
[18:35] <pitti> kees: for some reason yet unknown to me, killall /usr/lib/devicekit-disks/devkit-disks-daemon fails for me half of the time
[18:35] <jdstrand> Keybuk: is 'started on net-device-up lo' a valid way to start something after the loopback device is brought up?
[18:35] <kees> oh, ew
[18:35] <pitti> kees: killall devkit-disks-daemon works, but that's too imprecise for my taste
[18:35] <pitti> kees: I'll change dk-p to use the same
[18:35] <kees> pitti: yeah
[18:36] <Keybuk> jdstrand: it should work
[18:36] <jdstrand> Keybuk: really, I just want to start something before networking is started. I looked at networking.conf and network-interfaces.conf and it wasn't immediately apparent how I would want to do it...
[18:37] <jdstrand> Keybuk: if that'll work, I'll give it a go then
[18:40] <ccheney> is linux smart enough to not schedule on a ht virtual core if there are idle real cores?
[18:40] <Keybuk> what do you want to start before networking?
[18:40] <jdstrand> Keybuk: the firewall
[18:40] <Keybuk> why not just:
[18:41]  * ccheney is trying to decide whether to buy a i5 750 or i7 860, hopefully will help build OOo much faster
[18:41] <Keybuk>   start on starting network-interface or starting networking ?
[18:41] <Keybuk> but put the stuff to bring the firewall up in pre-start and down in post-stop
[18:41] <Keybuk> so that "firewall" is up when the rules are loaded
[18:41] <Keybuk> otherwise it'll get run every time an interface comes up
[18:42] <jdstrand> Keybuk: I was thinking about that, but thought network-interface might make it more than I want it to. and wasn't sure that networking was enough
[18:42] <Keybuk> depends
[18:42] <Keybuk> network-interface is each ordinary interface
[18:43] <Keybuk> networking is there because I'm a coward
[18:43] <Keybuk> I don't think we *need* networking anymore
[18:43] <Keybuk> ifup -a should be a no-op
[18:43] <Keybuk> as either the interface was brought up by udev
[18:43] <Keybuk> or the underlying device doesn't exist, so can't be brought up anyway
[18:45] <jdstrand> Keybuk: actually, it wouldn't be horribly bad if the start ran slightly more often than desired for corner cases, the 'start' I would use is smart enough to not do anything if the firewall is already started
[18:45] <jdstrand> I'll try 'start on starting network-interface or starting networking' then
[18:45] <Keybuk> it would be bad
[18:45] <Keybuk> it's expensive
[18:46] <davmor2> ccheney: foolish mortal it doesn't speed anything up honest ;)
[18:46] <Keybuk> having lo, eth0 and eth1 is not a corner-case, it's the common case :p
[18:46] <jdstrand> Keybuk: that was why I initially thought I wanted to do this after 'lo' came up only
[18:47] <jdstrand> Keybuk: is IFACE available to me?
[18:48] <ccheney> davmor2: heh
[18:48] <cjwatson> ScottK: done - there's a messy bug in mass-sync.py, I just hacked around it for the moment since I'm out of time
[18:49] <ScottK> cjwatson: Thank you.
[18:53] <soren> Keybuk: We don't need the networking job? Do we have new ways to deal with bridges, bonded interfaces, and other "virtual" interfaces?
[18:55] <cjwatson> kirkland: is Etienne's comment in bug 430820 about setting eth0 to manual correct?
[18:55] <cjwatson> it feels surprising to me
[18:56] <Keybuk> soren: they still have entries in /sys/class/net
[18:56] <kirkland> cjwatson: i didn't have to do that
[18:56] <soren> Keybuk: I do believe the logic we used to have is horrible. bonded interfaces should be configured when the last of the slave interfaces is configured. Bridges could be created immediately and the related interfaces could get added when they turn up..
[18:56] <kirkland> cjwatson: my routing table looks okay
[18:56] <soren> Keybuk: Yes, when they get configured?
[18:56] <kirkland> cjwatson: and seems to work, moreover
[18:56] <Keybuk> soren: right, I think you're following me though
[18:56] <kirkland> cjwatson: well, work meaning my nc get's a dhcp address
[18:56] <Keybuk> we should do them on the tail of other interfaces, not in one big drop
[18:56] <soren> Keybuk: Pray tell :)
[18:57] <soren> Keybuk: Oh, yes, indeed.
[18:57] <Keybuk> if you bond eth0 and eth1, then you should do that when you have eth0 and eth1
[18:57] <cjwatson> kirkland: I've asked Etienne to file a separate bug for that, then
[18:57] <soren> Keybuk: I'm just not sure why you think we're there?
[18:57] <soren> Keybuk: Precisely.
[18:57] <kirkland> soren: cjwatson: i have a fix for eucalyptus-cc init script
[18:57] <kirkland> cjwatson: did you do the netstat check for the cloud being up?
[18:57] <cjwatson> I wrote it, yes
[18:57] <Keybuk> soren: I think we have everything we need to do that
[18:57] <cjwatson> it's a hack of epic proportions
[18:57] <Keybuk> I'm just not going to change that too :p
[18:57] <kirkland> cjwatson: http://paste.ubuntu.com/272265/
[18:58] <kirkland> cjwatson: can you take a quick look at the init script portion of that patch
[18:58] <soren> Keybuk: We have the tools, but not the actual scripts... Right? Or do you have something up your sleeve that I don't know about? :)
[18:58] <kirkland> cjwatson: i don't think your counter was working
[18:58] <Keybuk> soren: right, exactly
[18:58] <soren> Keybuk: Ok.
[18:58] <soren> Keybuk: I would loooove to get that fixed for Karmic+1.
[18:58] <soren> Keybuk: It's been bugging me for ages.
[18:59] <kirkland> cjwatson: also, eucalyptus upstream asked for some logic to make sure that a cloud-controller is actually expected on this system
[18:59] <cjwatson> kirkland: oh, that's just because I didn't check it
[18:59] <kirkland> cjwatson: hence the -x cehck
[18:59] <soren> Keybuk: I just didn't realise you'd be doing the whole networking thing from upstart, but it makes perfect sense.
[18:59] <cjwatson> kirkland: instead of the if, how about '&& [ "$i" != 0 ]'? :-)
[18:59] <cjwatson> kirkland: upstream weren't reading very closely, then ;-)
[19:00] <cjwatson>         if [ ! -e /usr/share/eucalyptus/eucalyptus-cloud-@EUCA_VERSION@.jar ]; then
[19:00] <cjwatson>                 return # no cloud here
[19:00] <cjwatson> kirkland: further up in the same function
[19:00] <cjwatson>         fi
[19:00] <soren> Keybuk: That will also make iscsi a much happier place. Ooh, I can't wait. :)
[19:00] <kirkland> cjwatson: ah, i missed that too
[19:00] <cjwatson> kirkland: I think: http://paste.ubuntu.com/272279/
[19:01] <kirkland> cjwatson: that looks good by me
[19:01] <kirkland> cjwatson: let me test it here
[19:02] <cjwatson> committed, as I think that has to be an improvement
[19:02] <cjwatson> and I have to run :)
[19:02] <cjwatson> should we try to get a new version of eucalyptus into alpha 6?
[19:02] <cjwatson> if so it'll need to be very very soon
[19:03] <kirkland> cjwatson: i think so
[19:04] <kirkland> soren: are you planning to roll a new eucalyptus for alpha6?
[19:04] <kirkland> soren: if so, see cjwatson's comment about "very soon" ^
[19:04] <soren> kirkland: I /could/.
[19:06] <Laney> Anyone want to help debug my unbootable system? http://orangesquash.org.uk/~laney/noboot.jpg :)
[19:07] <Laney> did dist-upgrade already
[19:08] <kirkland> cjwatson: actually, the network bridging isn't quite right yet ...  i'm debugging
[19:09] <cjwatson> kirkland: ok, if you could fix it when you figure it out then I'd appreciate it - I have to run now
[19:09] <ion> laney: First of all, did you boot without the quiet parameter?
[19:09] <kirkland> cjwatson: sure thing
[19:09] <Laney> ion: sure did
[19:09] <kirkland> cjwatson: i think we're just missing an auto br0
[19:10] <Keybuk> Laney: looks like you're using tux on ice or something?
[19:10] <Laney> I have no idea what that is
[19:10] <Laney> my root partition is on mdadm
[19:10] <ion> laney: ls -l /dev/disk/by-uuid, see what /dev entry the UUID printed on the ‘mounting ... failed’ line points to, run mount /dev/THAT /root. Any output other than ‘...failed: Device or resource busy’? Run dmesg. Anything interesting?
[19:10] <Keybuk> ion: it's probably busy because the kernel things it's resuming maybe ?
[19:10] <Keybuk> oh, no, different UUID
[19:10] <Keybuk> ignore me
[19:10] <cjwatson> kirkland: makes sense
[19:11] <cjwatson> kirkland: that was in the documentation I was working from, so just a slip on my part
[19:11] <kirkland> cjwatson: okay, i can fix it
[19:11] <kirkland> cjwatson: goes in that udeb postinst?
[19:11] <kirkland> cjwatson: if not, just give me a pointer
[19:11] <Laney> So it seems to be trying to boot from /dev/sda1 instead of /dev/md0p1
[19:12] <soren> kirkland: http://bazaar.launchpad.net/~ubuntu-core-dev/eucalyptus/ubuntu/revision/552 you can just create them like that? Really?
[19:12] <Laney> I see "Starting manual resume from disk" in dmesg, too
[19:12] <Laney> ion: ^
[19:12] <Keybuk> Laney: can you run "blkid" from there
[19:12] <cjwatson> kirkland: not the postinst, debian/eucalyptus-udeb.finish-install, setup_bridge_device
[19:12] <Laney> it did bring up the array just fine
[19:12] <Keybuk> and get a photo of the output
[19:12] <Laney> Keybuk: oh, sure
[19:12] <soren> kirkland: Well... You should probably fix up the permissions, but I mean... They will work as block devices?
[19:12] <Laney> md0p1 and sda1 have the same UUID
[19:12] <kirkland> soren: dude, you asked me to add changelog entries, no?\
[19:13] <Laney> and then there's sda5 and md0p5 which are also the same (swap)
[19:13] <kirkland> soren: oh!  you mean create loop devices :-)
[19:13] <soren> I... did..?
[19:13] <Keybuk> Laney: yeah
[19:13] <cjwatson> soren: no reason they shouldn't - and yes, should be mknod -m660
[19:13] <Laney> one second
[19:13] <Keybuk> now if you look in /dev/disk/by-uuid where do they point?
[19:13] <soren> and chgrp disk.
[19:13] <kirkland> soren: i thought you were griping at me about creating an unreleased eucalyptus changelog :-)
[19:13] <cjwatson> yes
[19:13] <soren> kirkland: Nono, dude, I do that all the time :)
[19:14] <kirkland> soren: yeah, kernel guys said our kernel is configured with loop=0, which means that 8 will be created by default, more can be created in userspace
[19:14] <cjwatson> kirkland: oh, I think you need to do $(($LOOP_SUG - 1) not $((LOOP_SUG - 1) - there have been shell bugs about the latter
[19:14] <kirkland> soren: otherwise, if it's >=0, then the limit is fixed, can only be overridden with kernel boot options
[19:14] <cjwatson> dash at least used to fail to handle the latter as specified by POSIX
[19:14] <soren> cjwatson: Well... the loop driver in the kernel allocates a bunch of structures for the 8 loop devices it starts out with. I didn't notice any code to automatically allocate more, but I didn't look that closely.
[19:14] <Laney> Keybuk: http://orangesquash.org.uk/~laney/noboot2.jpg ... looks right?
[19:14] <kirkland> cjwatson: thanks, i just saw your $(($i-1)) and had to go test your way to believe you :-)
[19:14] <cjwatson> soren: I'm fairly sure from past memories that you can just create them
[19:14] <kirkland> cjwatson: and then second-guessed my way
[19:15] <soren> Oh...
[19:15] <cjwatson> kirkland: yeah, that habit has a reasson behind it :)
[19:15] <cjwatson> -s
[19:15] <kirkland> soren: i created them here, worked like a champ
[19:15] <soren> kirkland: Right, I may have only looked at the !=0 code path.
[19:15] <Keybuk> Laney: in that it's exactly wrong, yes
[19:15] <kirkland> soren: though cjwatson is right about the perms
[19:15] <Laney> hah
[19:15] <kirkland> cjwatson: i'll fix those two things now
[19:15] <cjwatson> well, soren pointed them out first
[19:15] <jdstrand> Keybuk: can you peek at http://paste.ubuntu.com/272290/ and let me know if I am going down the right path? this is my first upstart script
[19:15] <soren> kirkland: And ownership.
[19:15] <Laney> bug or user error?
[19:16] <soren> kirkland: (group should be disk)
[19:16] <Keybuk> jdstrand: don't think you want "6" in the stop on
[19:16] <kirkland> soren: btw, should we go ahead and define CLOUD_PORT=8773 in eucalyptus.conf?
[19:16] <soren> kirkland: I really have no opinion on that subject.
[19:16] <kirkland> soren: as that's used in a couple of places now in the init scripts, though perhaps not yet universally supported
[19:16] <jdstrand> Keybuk: no. that was intentional. it should not be brought down on restart
[19:16] <cjwatson> coo, didn't know that upstart scripts were automatically set -e. nice.
[19:17] <Keybuk> jdstrand: but brought down on halt and entering single user mode?
[19:17] <soren> kirkland: If that fixes something for you, sure.
[19:17] <kirkland> soren: k
[19:17] <cjwatson> Keybuk: BTW the documentation isn't entirely clear on whether -e is used for {pre,post}-{start,stop} script as well as plain script
[19:17] <jdstrand> Keybuk: well, single-user yes, halt no. I should add 0
[19:17] <Keybuk> cjwatson: oh, it is ;)
[19:17] <Keybuk> jdstrand: ok
[19:17] <Keybuk> jdstrand: you're also missing "end script" after each of the script blocks
[19:18] <Keybuk> jdstrand: and style says the /lib/ufw/... line should be preceeded by exec
[19:18] <Keybuk> jdstrand: also, what's with the [ "$IFACE" = "lo" ] bit?
[19:18] <Keybuk> jdstrand: if you only want to do this on loopback, just do "start on net-device-up IFACE=lo"
[19:18] <cjwatson> Keybuk: I can read it either way, I think :)
[19:18] <Keybuk> jdstrand: and that should be "start on" not "started on"
[19:18] <Keybuk> jdstrand: oh, and style: description "Uncomplicated firewall"
[19:18] <jdstrand> Keybuk: was not aware of net-device-up IFACE=lo syntax. will adjust
[19:19] <jdstrand> Keybuk: ufw-init is a shell script, does that matter wrt style and exec?
[19:19] <ion> keybuk: Interesting. I ran blkid on a jaunty system. I have ext2 on md127 on sd{a,b}1. I also have lvm on md126 on sd{a,b}3. blkid printed the identical UUID="foo" TYPE="ext2" for each of sda1, sdb1 and md127. It printed UUID="bar", TYPE="mdraid" for sd{a,b}3 and UUID="baz", TYPE="lvm2pv" for m126.
[19:19] <Keybuk> jdstrand: it means that the pid stays the same
[19:19] <Keybuk> jdstrand: saves you a fork()
[19:19] <Keybuk> (and ptrace overhead)
[19:20] <jdstrand> Keybuk: ok, will change and test. thanks for the feedback!
[19:20] <Keybuk> jdstrand: though the comment looks good
[19:20] <Keybuk> jdstrand: nothing to review in that
[19:21] <Keybuk> (having just realised he said something about every single other line)
[19:21] <jdstrand> heheh
[19:22] <ion> keybuk: Is it just good luck that /dev/disk/by-uuid/33a915c6-874d-4d17-8de5-02afb786480e points to /dev/md127 here and not /dev/sda1 or /dev/sdb1? :-)
[19:22] <Keybuk> cjwatson: everything is -e because not using -e kills kittens
[19:22] <jdstrand> actually, I think the 'pre-start script' lines and the whitespace was ok...
[19:22]  * Laney bounces
[19:22] <Keybuk> jdstrand: yes, good whitespace!
[19:22] <jdstrand> \o/
[19:23]  * jdstrand strives for good whitespace over everything else
[19:23] <soren> ion: md*127*?!? Seriously? Are md0-md126 all in use?
[19:23] <kirkland> soren: okay, mknod fixes pushed
[19:23] <kirkland> soren: using $LOOP_SUG as cjwatson suggested, chowning root:disk, and perm'd 660
[19:24] <kirkland> soren: whoops, push failed, divergence
[19:24] <soren> Where'd you push it?
[19:24] <soren> ah.
[19:24] <soren> Yeah, that's me :)
[19:24] <kirkland> soren: uno momento
[19:24] <soren> Sure.
[19:24] <ion> soren: When creating the array, i experimented with some mdadm parameter for array name, hoping it would create device names like md-foo. Instead, it gave them numbers beginning from 127 and going down. I didn’t feel like recreating the arrays just to get the numbers lower. :-P
[19:25] <cjwatson> Keybuk: oh, I quite agree
[19:25] <Laney> so who's bug is this? and can I get out of it?
[19:25] <Keybuk> Laney: unsure
[19:25] <Keybuk> it's either a blkid bug
[19:25] <Keybuk> or a udev bug
[19:26] <Laney> happy to help debug
[19:26] <soren> Keybuk: Did you follow the conversation above about automatically created loop devices?
[19:26] <Keybuk> soren: nope
[19:26] <soren> Keybuk: Ok.
[19:27] <soren> Keybuk: Short version: The kernel creates 8 of them on boot, but you can just mknod more of them, and the driver handles allocating the kernel structs and all that jazz.. Is there a way to make udev set the right permissions for them?
[19:28] <kirkland> soren: okay, let me fix the network bridging issue ...
[19:28] <soren> Keybuk: Right now we're mknod'ing them, followed by mknod and chmod, which obviously will not follow changes made in the udev rules.
[19:29] <soren> Er... followed by chgrp and chmod. Not mknod again, obviously.
[19:29] <Keybuk> soren: yeah, loop is broken
[19:29] <soren> Keybuk: Heheh :)
[19:29] <Keybuk> soren: it should be some kind of /dev/pts-a-like
[19:30] <Keybuk> or /dev/loopctl
[19:30] <Keybuk> so you ask for a new one, a kobject appears, and then udev can create the node
[19:30] <soren> Yeah.
[19:30] <nixternal> don't call it /dev/nixternal, as it may disappear from time-to-time :p
[19:30] <Keybuk> now devtmpfs has gone mainstream, people may actually care
[19:30] <kirkland> soren: okay, pushed /etc/network/interfaces fix too
[19:31]  * hunger had a really strange problem, making it impossible to boot jaunty today.
[19:31]  * Keybuk tries to isolate the electrical/plastic burning smell in his office
[19:31] <ion> keybuk: blkid output with some structure added for clarity: http://pastebin.ca/1568672
[19:32] <hunger> Somehow I ended up with a partition that the system considers to be LUKS encrypted even though it is not. Yesterday that was no problem, after installing the updates boot broke this morning due to this.
[19:33] <hunger> So if somebody else is seeing boot problems after yesterdays round of updates, it might be worth your while to check your partitions for LUKS encryption:-)
[19:33] <soren> kirkland: How do you update the changelog?
[19:34] <kirkland> soren: dch -e
[19:34] <pochu> pitti: hey, I've reported Debian #546967, in case you are interested
[19:34] <soren> kirkland: Ah, that explains.
[19:34] <kirkland> soren: as opposed to ...?
[19:35] <kirkland> soren: you're looking at the timestamp/signature that gets updated?
[19:35] <Keybuk> ion: can you join #udev and debug with kzak/kay
[19:35] <soren> kirkland: If you just use "dch 'whatever you want in the changelog'", dch will handle breaking lines and all that stuff.
[19:35] <kirkland> soren: ah
[19:35] <soren> kirkland: Yes, the timestamp thing caught my attention :)
[19:35] <soren> kirkland: dch called like I just said will not touch the timestamp.
[19:35] <kirkland> soren: okay, i'll use that when touching your packages :-)
[19:35] <soren> kirkland: Ta :)
[19:36] <soren> So, are we all happy with this revision?
[19:36] <kirkland> soren: did you clear the mknod hack with Keybuk ?
[19:36] <kirkland> soren: what was the outcome of that?
[19:36] <soren> kirkland: I think the conclusion was that loop is broken.
[19:36] <slangasek> mknod?? <gibber, gibber>
[19:37] <kirkland> soren: okay, then i'm fine with it, several bugs fixed, better than before :-)
[19:37] <kirkland> soren: i pushed rev 557
[19:37] <Keybuk> kirkland, soren: what was the hack
[19:37] <kirkland> soren: for the record
[19:37] <soren> slangasek: It turns out to be a well documented feature of the loop driver :)
[19:37]  * Keybuk has put out the fire
[19:37] <e-jat_> anyone know how to solve this bug 428365
[19:37] <soren> Keybuk: We were hoping you'd provide the hack.
[19:37] <ion> keybuk: What was it? :-)
[19:38] <Keybuk> ion: the US four-gang
[19:38] <Keybuk> I think it's given up
[19:38] <Keybuk> it had little flames and everything
[19:38] <soren> slangasek: If you need more loop devices, you just mknod them, and the driver does some magic. We need more loop devices, so we mknod them.
[19:38] <soren> Keybuk: That's /usually/ a sign of giving up.
[19:38] <ion> keybuk: Parse error
[19:40] <slangasek> soren: I'm putting my fingers in my ears and wandering back over to the alpha 6 zone
[19:40] <Keybuk> uh
[19:40] <Keybuk> fire started again
[19:40] <Keybuk> brb
[19:40] <soren> slangasek: See you there..
[19:41] <Keybuk> and put out again
[19:41]  * Keybuk has unplugged the gang this time
[19:41] <Keybuk> (and put it outside, away from the expensive computers and expensive humans)
[19:41] <nixternal> haha, you are working so hard you are starting fires..that is just scary :)
[19:42] <kirkland> soren: actually, i missed a bug number in the changelog
[19:42] <kirkland> soren: if you want to add 430820
[19:42] <soren> kirkland: Naughty, naughty.
[19:42] <soren> kirkland: Can you do it yourself?
[19:42] <kirkland> soren: doing...
[19:42] <Keybuk> nixternal: you know you're having a bad day, when ...
[19:43] <mathiaz> kirkland: could you also add bug 425926?
[19:43] <nixternal> hehe
[19:43] <Keybuk> unfortunately I now have a Michael McIntyre sketch going through my head
[19:43] <mathiaz> kirkland: to my changelog entry
[19:43] <kirkland> soren: pushed 558
[19:43] <Keybuk> Whoah-oh, my sex^Wnetbook is on fire!
[19:43] <kirkland> mathiaz: sure
[19:43] <mathiaz> kirkland: I've discovered the bug after I had pushed/merged my branch
[19:44] <soren> kirkland: ta.
[19:44] <kirkland>   [ Mathias Gug ]
[19:44] <kirkland>   * Recommend python-image-store-proxy for eucalyptus-cloud. The Image Store
[19:44] <kirkland>     feature won't work without it, LP: #425926
[19:44] <nixternal> the netbook, the netbook, the netbook is on fire, we don't need no water let the lil bastard burn!
[19:47] <kirkland> mathiaz: soren: done, pushed
[19:48] <soren> kirkland: I'll do a test build and upload if it looks decent.
[19:48] <kirkland> soren: thanks, let me know if you want some more testing too
[19:49] <nurmi> hi all; I was hoping that we might have a quick discussion regarding the Eucalyptus init scripts
[19:49] <soren> cjwatson: Did you leave?
[19:49] <kirkland> nurmi: sure, shoot
[19:49] <kirkland> mathiaz: connectivity issues?
[19:49] <slangasek> soren: he did
[19:50] <soren> Darn it.
[19:50] <mathiaz> kirkland: well - my X server crashed - but I was using byobu to run irssi
[19:50] <nurmi> kirkland: i've been trying out the latest package, and found one issue regarding the ordering of installation/init script starting
[19:50] <nurmi> bug here: 430841
[19:50] <soren> bug 430841
[19:51] <mathiaz> kirkland: however I'm using a the notitication command to send highlights to my desktop, which uses dbus
[19:51] <slytherin> what all information is needed when filing a bug against pulseaudio?
[19:51] <mathiaz> kirkland: and the dbus session went away when X crashed and I restarted my gnome session - reconnecting to the existing screen session failed to pick up the dbus session
[19:52] <Treenaks> slytherin, doesn't "ubuntu-bug pulseaudio" supply everything now?
[19:52] <nurmi> soren: ah, cool :).  I put in a few possible solutions that in the report, but wanted to chat about whether you have other ideas/concerns
[19:52] <kirkland> mathiaz: byobu/irssi should have kept you connected, no?
[19:52] <mathiaz> kirkland: probably the same issue as the ssh-agent socket when you login/logout in  machine and reconnect to an existing machine
[19:52] <slytherin> Treenaks: I haven't tried
[19:52] <mathiaz> kirkland: yes - it kept me connected - but it was using the old dbus session
[19:52]  * Treenaks wonders why his scroll lock led has started blinking 
[19:53] <kirkland> mathiaz: hrm, sounds similar to the ssh-agent issue
[19:53] <mathiaz> kirkland: so highlights would not get sent to my desktop - instead I have an error message printed in my irssi window
[19:53] <mathiaz> kirkland: which is very annoying
[19:55] <soren> Hmm...
[19:55] <soren> nurmi: I wonder if upstart would be helpful here at all.
[19:56] <soren> nurmi: Or just make matters even more complicated.
[19:56] <nurmi> soren: i'm not familiar with upstart, what is the basic idea?
[19:56] <kirkland> nurmi: event-based service startup
[19:57] <nurmi> nurmi: oh, right, spaced on the name.
[19:57]  * nurmi talks to himself
[19:57] <nurmi> soren: can the event be 'file is in place'?
[19:58] <soren> I'm not sure, to be honest. This is all very, very new to me as well.
[19:58] <soren> nurmi: Keybuk knows.
[19:59] <ion> nurmi: File notification based events are in TODO, but not with very high priority.
[19:59] <nurmi> ion: i see, what type of events are currently supported?
[20:00] <kirkland> nurmi: soren: Keybuk has spoken to me before about inotify-driven upstart; i don't think we have that in karmic, though
[20:00]  * kirkland could be wrong, however
[20:01] <Keybuk> no, not yet
[20:01] <Keybuk> it's on the TODO
[20:01] <ion> Just a handful of events sent by Upstart itself (‘startup’, ‘control-alt-delete’ etc.), the starting/started/stopping/stopped events for jobs and anything emitted by system scripts. And perhaps something else i forget.
[20:01] <soren> nurmi: This is only a problem at package install time, though, right?
[20:01] <nurmi> soren: correct
[20:02] <nurmi> ion: i see, thanks; i'm also reading about upstart now, very cool :)
[20:02] <nurmi> soren: what do you think about the idea of installing the service files as '.disabled' by default?
[20:02] <ttx> soren: any progress on alpha6 image generation ?
[20:03] <nurmi> soren: this would ensure that when init scripts 'start' the first time, the service will be loaded
[20:03] <soren> nurmi: Where are these service files located?
[20:03] <soren> ttx: The UEC images?
[20:03] <ttx> soren: yes
[20:03] <soren> ttx: http://uec-images.ubuntu.com/karmic/20090916
[20:03] <soren> ttx: With MD5SUMS, manifests and everything.
[20:04] <nurmi> soren: /usr/share/eucalyptus/
[20:04] <ttx> soren: they don't show up on the test tracker
[20:04] <soren> nurmi: Ungh... Modifying anything in there is not kosher.
[20:04] <soren> ttx: Ah.
[20:04] <soren> smoser: Can you take care of that?
[20:05] <nurmi> soren: there may be another option, although I havn't tested it much
[20:05] <soren> nurmi: Pray tell :)
[20:05] <nurmi> soren: each of the eucalyptus-cloud/walrus/sc init scripts ultimately ends up calling '/usr/sbin/eucalyptus-cloud'
[20:06] <nurmi> soren: that program is the bootloader for any webservice that exists in /usr/share/eucalyptus
[20:06] <smoser> can i take care of what ?
[20:06] <soren> smoser: Make the UEC images turn up in the test tracker.
[20:06] <nurmi> soren: the command itself takes disable arguments, for example: --disable-cloud, --disable-walrus, --disable-sc
[20:06] <smoser> um.. i can try. do we think its reasonable to believe that these could turn into alpha-6 ?
[20:06] <soren> smoser: We will only know by testing them :)
[20:07] <nurmi> soren: so that, even if the service file exists, one can 'disable' it using these options
[20:07] <ttx> smoser: unless we test them, we'll never know
[20:07] <smoser> thats not true
[20:07] <soren> brb
[20:07] <smoser> we can no that they will not be alpha-6 if we know of major issues in the packages they contain
[20:07] <smoser> thats what i was asking, if there were any known issues as of an hour ago or so in the archive that would prevent it
[20:08] <ttx> smoser: even in that case, it's good to know if there weren't any other issue, which the tests would unearth
[20:08] <slangasek> smoser: none in the general case
[20:08] <ttx> smoser: respins should be triggered by test failures on the tracker anyway
[20:08] <smoser> how do i add these things ?
[20:08] <smoser> to the tracker ?
[20:09] <ttx> so it's always good to do it :)
[20:09] <ttx> smoser: if I knew, I wouldn't ask.
[20:09] <smoser> slangasek, ?
[20:09] <slangasek> smoser: you tell me or stgraber what you have available for testing that you want on the tracker
[20:10] <smoser> slangasek, http://uec-images.ubuntu.com/karmic/20090916/
[20:10] <ttx> smoser: was this image bundled/uploaded to EC2 ?
[20:10] <smoser> and, slangasek i'm in the process of what ttx is asking
[20:10] <slangasek> ack
[20:10] <slangasek> whoo manifests
[20:10] <ttx> and MD5SUMS :)
[20:10] <slangasek> are you hand-generating this md5sums file?
[20:11] <smoser> so i'll bother you with the ami's later today
[20:11] <smoser> slangasek, md5 is part of the tools now
[20:11] <slangasek> ttx, smoser: there are scripts to do md5sums generation and sign them; we should use those (but blocked on an RT to let our users share files)
[20:11] <slytherin> Treenaks: ubuntu-bug helped a lot. :-)
[20:11] <slangasek> smoser: please don't reinvent the wheel here, we should reuse the cdimage toolkit we already have
[20:12] <smoser> but i like inventing wheels
[20:12] <slangasek> (yes, md5sum is a very small wheel - but sign-cdimage is less of one)
[20:12] <ttx> smoser: square ones ?
[20:12] <smoser> no, but seriously,  i didn't know. i agree, i'll use whatever is available
[20:12] <slangasek> smoser: hmm, let me bounce you the relevant emails then; I thought you'd been cc:ed
[20:12] <smoser> slangasek, point me at it and we'll do that for beta
[20:13] <slangasek> smoser: /home/vmbuilder/cdimage

[20:13] <slangasek> email to follow :)
[20:13] <slangasek> smoser: you were cc:ed on the mail; Message-ID: <20090916005543.GB8869@dario.dodds.net>
[20:13] <smoser> ok. i'll dig.
[20:14] <Laney> Keybuk: please let me know if you isolate a fix... wouldn't mind a bootable system again
[20:14] <slangasek> if you need me to resend, let me know
[20:14] <Keybuk> Laney: I wouldn't expect me to isolate your fix until at least next week
[20:14] <Keybuk> it's unrelated to the init transition
[20:14] <Laney> ok
[20:14] <Keybuk> you could temporarily work around it by booting with root=/dev/md0p1
[20:15]  * Laney nods
[20:18] <soren> nurmi: Why not just have one init script?
[20:20] <kirkland> cjwatson: actually, etienneg is correct, in practice about the "manual" thing
[20:20] <jjardon> hello, I have a problem with devhelp: $ devhelp
[20:20] <jjardon> devhelp: error while loading shared libraries: /usr/lib/libgstbase-0.10.so.0: file too short
[20:21] <jjardon> is this bug already filled?
[20:21] <wasabi_> Weird question. Has something odd changed in Karmic that might effect speed and reliability of network connections?
[20:22] <jjardon> (karmic here)
[20:22] <wasabi_> Specifically, I can now only scp files at around 4k a sec, and all CIFS file transfers fail. Oddly enough, they fail when done by a Windows VM running on karmic.
[20:22] <wasabi_> It's like TCP is just falling over in some way.
[20:23] <slytherin> jjardon: not reproducible here
[20:23] <wasabi_> Wireshark shows lots of TCP out of order stuff, and lost segments.
[20:23] <wasabi_> This is between my machine, and any other machine on the same LAN. =/
[20:25]  * soren cries about not being able to rip cd's.. :(
[20:26]  * soren reboots
[20:29] <cr3> in a package, how can I create manpage aliases so that foo-gtk, foo-cli, foo-qt, etc. open the foo manpage?
[20:31] <soren> Do we know when xsplash is supposed to start looking right? I.e. not like a horizontal bar that jitters up and down a bit, but something that looks like it
[20:31] <slytherin> cr3: symply install symlinks
[20:31] <soren> s spinning horizontally.
[20:31] <nurmi> soren: we can have one init script, but i'm not clear on how one would be able to control the services independently
[20:31] <soren> nurmi: Well, it doesn
[20:31] <soren> t do that now anyway.
[20:32] <soren> At least not when stopping things.
[20:32] <nurmi> soren: ?  currently, you can stop/start any of the three services using the init scripts
[20:32] <cr3> slytherin: I thought I could simply tell dh_installman to update the mandb with aliases
[20:33] <nurmi> soren: granted, it does restart the process, but when the process comes back after, say, a 'walrus stop', then the walrus service is no longer running
[20:34] <soren> Hmm..
[20:34] <soren> Oh, right, I see what you mean.
[20:35] <nurmi> soren: i was thinking that we could maintain a small state file in /var/run/eucalyptus (next to the pid files) that records which services are disabled (i.e. a 'stop' has been called)
[20:36] <soren> When would I want to stop them individually?
[20:36] <soren> Or start them individually?
[20:36] <nurmi> soren: then, the init script can read that file and decide which services should not be running, and use the '--disable-<service>' flags to 'eucalyptus-cloud'
[20:42] <soren> nurmi: Are you still there? :)
[20:43] <nurmi> soren: we are going under the assumption that, for each unique 'package' or 'service', there is a way to control it independently
[20:43] <soren> nurmi: Yes. And why is that?
[20:43] <nurmi> soren: honestly, other than perception, the only reason I can think to start/stop them independently is if something goes wrong
[20:44] <soren> nurmi: That sounds reasonable.
[20:44] <nurmi> soren: or, if you decide that you want to bring down one sc/cluster for maintain while keeping the other services up
[20:50] <soren> nurmi: I'm just not sure having that option available in this way is important enough to warrant the other issues we're seeing.
[20:53] <nurmi> soren: i see, the alternative you're suggesting is one init script for all three packages?
[20:55] <ulaas> hi! how do i add my windows boot to grub2?
[20:56] <soren> nurmi: Yes. I haven't thought about this a whole lot, but doing it that way sure would have saved me a few surprises :)
[20:57] <nurmi> soren: i think as long as one can still install the services indepently (i.e., install walrus/sc/cloud alone on their own machines), then a single init script would be fine
[20:58] <soren> nurmi: And then perhaps a separate mechanism to disable a particular service.
[20:59] <soren> nurmi: Perhaps an explicit "/etc/init.d/eucalyptus-java-stuff disable sc" or something.
[21:00] <nurmi> soren: nod; do you forsee confusion around having an init script that is not named the same way as the package/service itself?
[21:01] <nurmi> soren: i.e., if one installs 'eucalyptus-walrus', and the init script is called 'eucalyptus-java-stuff', is that an issue?
[21:01] <soren> nurmi: A little bit. It depends on the new name, I suppose.
[21:01] <soren> nurmi: Hm...
[21:01] <soren> nurmi: It's a shame cjwatson isn't here. He seemed to have thought about this a bit.
[21:03] <stgraber> Keybuk: hey, I'm currently working on fixing ltsp following the upstart changes. When booting, I don't have dbus and hal running, but they work fine after I manually start them, what should be done to have them start automatically ?
[21:03] <stgraber> ogra: ^ that's the only issue I saw with yesterday changes (so far)
[21:03] <nurmi> soren: we can defer for now and re-fire the conversation when cjwatson is around, if you like; i'm happy to chat anytime :)
[21:04] <soren> nurmi: Even during European business hours? :)
[21:04] <nurmi> soren: if thats what it takes!
[21:04] <Keybuk> stgraber: why don't they start automatically?
[21:04] <nurmi> soren: init scripts make great 4am conversation :)
[21:05] <soren> nurmi: Well, right before our call tomorrow would probably be a good time, actually.
[21:05] <nurmi> soren: is 'right after' off the table? I have a meeting the hour before tomorrow
[21:06] <nurmi> soren: ah, thats getting late in EU
[21:06] <soren> Probably not. I can't really make appointments on cjwatson's behalf, though :)
[21:06] <nurmi> soren: lets see how it goes tomorrow, i'll try to be around as far before and after the call as I can
[21:06] <soren> Cool.
[21:12] <c_korn> can someone give a comment about bug 428657 ? only a small bug.
[21:13] <stgraber> Keybuk: dbus used to started by S12dbus, now it's not there anymore and I'm just wondering what should be done so it gets started at boot time :)
[21:13] <stgraber> (I haven't had a chance to look at how upstart works in much details yet)
[21:14] <Keybuk> stgraber: check /etc/init/dbus.conf
[21:16] <stgraber> Keybuk: hmm, what exactly is that "local-filesystems" ? our filesystem is mounted from the initrd in LTSP so that may be the issue ...
[21:16] <Keybuk> stgraber: filesystems that are not remote
[21:16] <ulaas> any ideas abou grub2 windows boot?
[21:17] <stgraber> Keybuk: how can I manually check that condition ?
[21:17] <Keybuk> stgraber: mountall --debug will tell you
[21:20] <Laney> hmm
[21:21] <Laney> /etc/udev/rules.d/z60_hdparm.rules is a dangling symlink and a message about that file (z60) is the last thing that is printed before my boot (appears to?) hang
[21:23] <nixternal> Keybuk: sorry to bug ya, but do you have any doco somewhere re: upstart? I am messing around with a kdm setup now
[21:23] <Keybuk> what would you like to know?
[21:23] <nixternal> cherry picking from /etc/init/ is how I have started piecing a file together
[21:23] <Keybuk> man 8 init is a reasonable place to start
[21:23] <Keybuk> that'll lead you to man 5 init, man 7 {start,stop}{ed,ing} etc.
[21:24] <Keybuk> I'll happily review anything you come up with ;)
[21:24] <Keybuk> if you're doing kdm, it'd be neat if you could include the extra events I added to gdm as well
[21:24] <nixternal> cool...i will probably pass something in front of you over the next couple of days...i will let you rest and catch up with everything else first :)
[21:24] <Keybuk> immediately after xsplash is started I do:
[21:24] <nixternal> don't need any more fires going on there from overworking :)
[21:24] <Keybuk>   initctl -q emit login-session-start DISPLAY_MANAGER=gdm
[21:25] <Keybuk> and after login/auto-login
[21:25] <Keybuk>   initctl -q emit desktop-session-start DISPLAY_MANAGER=gdm
[21:25] <nixternal> hrmm, I will look at that...i didn't see it in the gdm.upstart file in the package
[21:25] <Keybuk> it's in /etc/gdm/Init/Default and /etc/gdm/PreSession/Default
[21:25] <nixternal> groovy, thanks for that!
[21:27] <stgraber> Keybuk: running mountall basically skips everything as already mounted and doesn't trigger dbus
[21:27] <Keybuk> yes yes
[21:28] <Keybuk> it's the log I want ;)
[21:28] <Keybuk> --debug outputs lots of opinions about what mountall thinks
[21:28] <stgraber> http://pastebin.com/f200368f
[21:32] <Laney> boot hangs even with init=/bin/sh
[21:34] <cjwatson> soren: back now
[21:34] <soren> cjwatson: Ooh!
[21:34] <soren> nurmi: ^
[21:35] <seb128> hum
[21:36] <seb128> kees, do you have any details about all the changes you are doing on crash bugs?
[21:36] <seb128> kees, you just sent quite some emails in my bugsbox which I don't really know what to do about ;-)
[21:38] <Keybuk> stgraber: nothing looks wrong here
[21:39] <Keybuk> stgraber: what was your problem, again?
[21:40] <jdstrand> Keybuk: fyi, what was needed was 'start on net-device-added INTERFACE=lo'. 'started' doesn't work
[21:40] <Keybuk> jdstrand: yeah I said that ;)
[21:40] <stgraber> Keybuk: dbus doesn't start on LTSP, so hal doesn't start and I end up with a X without mouse+keyboard
[21:41] <Keybuk> right, but does mountall finish?
[21:41] <cjwatson> soren: back now
[21:41] <cjwatson> cr3: <hat maintainer="man-db">the correct way to get aliases into the manual page database is using symlinks</hat>
[21:42] <stgraber> Keybuk: ah, mountall should return at some point ?
[21:42] <Keybuk> stgraber: it usually does
[21:42] <kees> seb128: hi! sure, in karmic I added some segv analysis fields to apport reports, so I'm now going back through old bugs adding them, since they can help narrow down the cause of crashes.
[21:42] <Keybuk> if mountall is sitting there, and nothing starts, then that's a bigger problem than "no dbus"
[21:42] <cr3> cjwatson: thanks, I created a foo-gtk.links under my debian directory after looking at a few other sample packges
[21:43] <jdstrand> Keybuk: I'm having trouble having upstart reflect the true status of ufw. eg, if it is disabled, it still shows that it is 'running'. I'd like to tell upstart it isn't running
[21:43] <seb128> kees, I fail to see anything useful in what you added so far to those bugs, do you have any example of what we can do with those lines?
[21:43] <Keybuk> jdstrand: if it's disabled, exit 1
[21:43] <jdstrand> Keybuk: right, but it exits with error then
[21:43] <Keybuk> alternatively
[21:43] <Keybuk> if it's disabled
[21:43] <Keybuk>   stop
[21:43] <Keybuk>   exit 0
[21:43] <jdstrand> I don't think it is an error condition to have ufw disabled
[21:43] <kees> seb128: yeah, I can search for "SegvReason: exec" and look for crashes that resulted from misdirected execution flows, which is almost always a security bug.
[21:44] <Keybuk> but I would say exiting with an error is correct
[21:44] <Keybuk> start ufw
[21:44] <Keybuk> *should* exit with an error
[21:44] <Keybuk> because what the sysadmin asked for did not happen
[21:44] <kees> seb128: also, it gives a sense for if it was a NULL deref, or a more complex issue.
[21:44] <kees> seb128: which should allow for easier triage.
[21:44] <seb128> kees, do you have a wikipage or something explaining what errors should be considered as real issues?
[21:44] <cr3> cjwatson: I then thought to myself that perhaps setup.py should handle manpages, ie the upstream project, rather than just the debian packaging. however, it seems that handling manpages is a distro thing rather than an upstream thing
[21:44] <Keybuk> this is Upstart, not sysvinit ;)
[21:44] <seb128> kees, or security issues
[21:44] <kees> seb128: no, it's not really real vs unreal, it's just a helpful heuristic to add when triaging crashes.
[21:44] <seb128> kees, ie "not located in a known VMA region (needed readable region)!" doesn't speak to me
[21:45] <seb128> kees, any wtf for those? ;-)
[21:45] <stgraber> Keybuk: strace shows it stuck on a select
[21:45] <seb128> or dictionnary or something
[21:45] <Keybuk> stgraber: so mountall *isn't* finishing?
[21:45] <kees> seb128: I can write up a wiki page with some details
[21:45] <stgraber> Keybuk: no
[21:45] <seb128> kees, that would be nice, thanks
[21:45] <Keybuk> stgraber: you could've mentioned that bit *first* :p
[21:45] <kees> seb128: where would you think such a page would be most discoverable?
[21:45] <seb128> kees, just being curious but what "vma" is?
[21:45] <jdstrand> Keybuk: maybe I am having a hard time leaving sysv, but if we are in a boot situation, the admin didn't say 'start', the boot process did. should I care that it exits 1 in that case?
[21:45] <kees> Virtual Memory Address.
[21:45] <Keybuk> jdstrand: no, you need not care
[21:45] <stgraber> Keybuk: well, I didn't know that thing was supposed to return ;)
[21:46] <Keybuk> (Upstart won't care either) :p
[21:46] <jdstrand> Keybuk: I wasn't sure if the errors were captured somewhere which might cause later confusion
[21:46] <kees> seb128: it's a virtual memory address, which can be compared against the allocated VMAs for a process (the ProcMaps.txt file)
[21:46] <cjwatson> cr3: it's usually/often an upstream thing, but that doesn't necessarily mean that setup.py is smart enough to deal with them
[21:46]  * Keybuk is of the very strong opinion that "start service" in Upstart should never exit 0 if service is not running
[21:46] <Keybuk> even if the service is somehow disabled
[21:46] <cjwatson> cr3: setup.py not being the be-all and end-all of upstreams :)
[21:47] <jdstrand> Keybuk: if no one will see the error on boot, then I agree that do 'start ufw' should error out if it is disabled
[21:47] <Keybuk> jdstrand: I think you're worrying about too many things
[21:47] <seb128> kees, where? hum, the wiki documentation about apport or how to deal with crash bugs maybe?
[21:47] <Keybuk> jdstrand: for example, Upstart will have its own first-class way of disabling jobs later
[21:47] <cjwatson> cr3: there is, technically, support for just putting extra comma-space-separated names before the \- in the NAME section of the manual page - but if you use that without providing symlinks, I'll hunt you down :)
[21:48] <Keybuk> jdstrand: that will disable them from auto-starting, while still allowing sysadmin to do "start job" if they want and actually start it
[21:48] <cr3> cjwatson: thanks for the explanation, I've been using setup.py so much more than autotools lately that I started to believe it was the end-all indeed :)
[21:48] <jdstrand> Keybuk: quite probably. I tend to fret and be paranoid when I am looking at something for the first time :)
[21:48] <seb128> kees, just adding some lines about what informations there could be useful to bug triagers to spot security issues or useful trick you can use from that to track a bug in an easier way would be nice
[21:48] <seb128> kees, thanks!
[21:48] <Keybuk> jdstrand: I think it's abnormal for an Upstart job to have an /etc/default for example
[21:48] <Keybuk> jdstrand: not in the least because those things can go in the upstart conf itself
[21:48] <Keybuk> once we have an Upstart policy, it may even be a bug to have one
[21:49] <stgraber> Keybuk: would the content of /proc/mounts help you have an idea of what's wrong ?
[21:49] <Keybuk> stgraber: no, but /proc/self/mountinfo might
[21:49] <kees> seb128: okay, cool.  I will add it here: https://wiki.ubuntu.com/Apport
[21:49] <jdstrand> Keybuk: I was thinking about the /etc/default example too, since my issue here is essentially the same
[21:50] <seb128> kees, thanks!
[21:50] <jdstrand> Keybuk: but, for now, you have eased my mind and my upstart file much easier
[21:50] <stgraber> Keybuk: http://pastebin.com/m3cc2caa0
[21:50] <jdstrand> Keybuk: thanks for the hand holding
[21:50] <Keybuk> jdstrand: that's ok ;)  I'm still making this up as I go along
[21:50] <Keybuk> but Upstart does work in ways that are "surprising" to people used to sysvinit
[21:50] <Keybuk> because Upstart works in ways that *I* think are right :p
[21:51] <cjwatson> /etc/default> well, that was true of init scripts as well - the reason /etc/default was split out was because it relieved sysadmins of the necessity to understand the init script while merging
[21:51] <jdstrand> haha
[21:51] <Keybuk> cjwatson: right - and upstart jobs are supposed to be very simple to read and change - so the rationale goes away
[21:51] <cjwatson> that *may* be less of an issue with upstart jobs, because they're simpler, but OTOH they're perhaps less familiar, so I don't know that it's a given
[21:51] <jdstrand> Keybuk: sure-- fwiw, I see the power, I just don't have a firm feel for it yet
[21:51] <cjwatson> sysadmins are almost certainly more used to writing shell scripts than upstart jobs
[21:52] <cjwatson> I'm not entirely sure I disagree with you, I just haven't yet decided if I agree :)
[21:52] <Keybuk> cjwatson: plus I'm going on a bit of a "only include configuration options if we test them" crusade
[21:52] <Keybuk> for example
[21:52] <Keybuk> RAMRUN=yes
[21:53] <Keybuk> that is an inappropriately named config option in /etc/default/rcS
[21:53] <Keybuk> it should be named
[21:53] <Keybuk> DO_I_WANT_THIS_TO_BOOT=yes
[21:53] <Keybuk> because all you're going to get by setting that to "no" is a non-working system
[21:53] <cjwatson> I think /etc/default/rcS is perhaps somewhat exceptional :)
[21:53] <Keybuk> and thus, it's ignored now
[21:53] <Keybuk> cjwatson: I think the same holds true for most things in /etc/default
[21:53] <cjwatson> /etc/default/console-setup
[21:54] <cjwatson> comes to mind :)
[21:54] <Keybuk> cjwatson: should probably be something more like /etc/console-setup
[21:54] <Keybuk> it's not the "defaults" for an init script, after all
[21:54] <cjwatson> true
[21:54] <Keybuk> it's a first class config file
[21:54] <cjwatson> I've often had to change syslog options, and appreciated the default file for that when it was introduced
[21:54] <Keybuk> stgraber: I wonder whether mountall is expecting that it has to mount /rofs fw ;)
[21:54] <Keybuk> err, rw
[21:55] <Keybuk> cjwatson: it shouldn't be hard to edit the upstart job though
[21:55] <Keybuk> with the bonus that you get far better merge context if the options change
[21:55] <cjwatson> yeah, it's not editing it that's hard, it's that it's tedious to merge, and interrupts upgrades more often
[21:55] <Keybuk> you'd have to merge the default file if they changed too
[21:55] <cjwatson> the init script, and probably even the upstart job, change significantly more often than the default file, IME
[21:55] <cjwatson> obviously I don't have relevant E of upstart jobs as time goes on yet
[21:56] <Keybuk> and then there's the cost of all the default files
[21:56] <Keybuk> opening them for every job that uses them, and reading them
[21:56] <Keybuk> and if you edit the default file, should Upstart notice that, and take some action?
[21:56] <Keybuk> (as it does with the actual conf file)
[21:56] <Keybuk> and there's the simple fact that I think that things should be configured in one place, not spread out across the filesystem :p
[21:56] <cjwatson> I'm not saying they're universally good - I'm just not convinced that they're universally bad
[21:56] <cjwatson> anyway, late dinner :)
[21:57] <Keybuk> stgraber: the mountall --debug output you had was somewhat annoyingly corrupted
[21:57] <Keybuk> stgraber: could you try without the 2>&1 and see what you get
[21:58] <stgraber> Keybuk: http://pastebin.com/m7b3d6ebe
[21:58] <ion> It wouldn’t be tedious to merge at all, if dpkg handled conffile updates sanely. :-P
[21:58] <Keybuk> #
[21:58] <Keybuk> #
[21:58] <Keybuk> spawn: mount /rofs [1568]
[21:58] <Keybuk> #
[21:58] <Keybuk> mountall: mount /rofs [1568] terminated with status 1
[21:58] <Keybuk> hah
[21:59] <ion> Most of the merges would happen automatically and very few would require manual help.
[21:59] <Keybuk> #
[21:59] <Keybuk> #
[21:59] <Keybuk> spawn: mount -f -a -t squashfs /dev/nbd0 /rofs
[21:59] <Keybuk> #
[21:59] <Keybuk> mount: according to mtab, /dev/nbd0 is already mounted on /rofs
[21:59] <Keybuk> that's weird
[21:59] <Keybuk> oh, no
[21:59] <Keybuk> that's ok
[21:59] <Keybuk> stgraber: don't suppose you have a shell right now?
[22:00] <Keybuk> actually, don't worry
[22:00] <Keybuk> it's pretty clear what's going on ;)
[22:00] <Keybuk> #
[22:00] <Keybuk> mounted: virtual 14/14 swap 0/0 remote 0/0 local 0/1
[22:00] <Keybuk> #
[22:00] <Keybuk> mounted: fhs 12/12
[22:00] <Keybuk> that's quite funny
[22:01] <Keybuk> it thinks / is a virtual filesystem (like proc)
[22:01] <Keybuk> not a local filesystem
[22:01] <Keybuk> and is not going to declare local filesystems done until it can mount /rofs rw
[22:01] <Keybuk> (which won't ever happen)
[22:06] <stgraber> Keybuk: don't you have a similar issue with the livecd ?
[22:06] <Keybuk> stgraber: that's what I'm wondering, don't know why that works
[22:06] <stgraber> Keybuk: the way LTSP and the LiveCD mounts / should be very similar
[22:07] <Keybuk> stgraber: can you also do blkid -p /dev/nbd0 for me
[22:07] <stgraber> :~# blkid /dev/nbd0
[22:07] <stgraber> /dev/nbd0: TYPE="squashfs"
[22:07] <Keybuk> oh, well, that's descriptive ;)
[22:07] <Keybuk> udevinfo -q all -n nbd0 | grep ID_FS
[22:08] <stgraber> root@
[22:08] <stgraber> :~# udevadm info -q all -n nbd0 | grep ID_FS
[22:08] <stgraber> root@
[22:08] <stgraber> :~#
[22:09] <stgraber> so basically, nothing ;)
[22:09] <stgraber> http://pastebin.com/m695fde7d
[22:09] <Keybuk> ok that makes sense
[22:10] <Keybuk> at least it's SUBSYSTEM=block ;)
[22:10] <Keybuk> ok
[22:10] <Keybuk> I already have a fix for this
[22:10] <Keybuk> I just need to invert it
[22:14] <stgraber> Keybuk: cool
[22:16] <xcdfgkjhgcv> ikonia: WTF was that for?
[22:17] <ikonia> xcdfgkjhgcv: that is not for discussion in here
[22:54] <soren> nurmi: Not around?
[23:27] <TheMuso> Hrm, by the topic, can I assume things are still not sorted?
[23:28] <Laney> my third try at upgrading just resulted in a third different failure ;)
[23:36] <slangasek> TheMuso: things are 99% sorted, with the major exceptions being liveCDs and people using cryptsetup on disks other than /
[23:39] <Laney> Have people experienced "no gdm"?
[23:40] <TheMuso> ah ok
[23:40] <slangasek> Laney: commonly so
[23:40] <Laney> that bodes well for there being a fix ;)
[23:40] <slangasek> Laney: what version of dbus do you have installed?
[23:41] <cjwatson> and libexpat1
[23:41]  * Laney returns to said machine
[23:41] <slangasek> cjwatson: should only matter in practice if /usr is on NFS :)
[23:41] <slangasek> (otherwise the dbus change is necessary and sufficient)
[23:42] <Laney> slangasek: 1.2.16-0ubuntu4
[23:42] <cjwatson> true
[23:45] <slangasek> Laney: ok, then you have the version that fixed the first bug, and have found another bug revealed by that fix
[23:46] <Laney> ):
[23:46] <Laney> :) even
[23:46] <slangasek> Laney: edit /etc/init/mountall.conf; add 'bash' before the mountall command; run mountall --debug 2>&1 > /dev/mountall.log from the shell; submit that log in a bug against the mountall package
[23:47] <slangasek> Laney: (and subscribe me, so I can try to help triage while Keybuk is snorkeling in bugs)
[23:47] <Laney> sure
[23:47] <Laney> slangasek: "bash" before script or in the script block?
[23:48] <slangasek> Laney: in the script block
[23:48] <Laney> alright
[23:49] <Laney> do you really mean /dev/mountall.log?
[23:49] <cjwatson> yes, /dev is writable
[23:49] <cjwatson> when running mountall, most other places aren't
[23:49] <Laney> ok
[23:49] <Laney> will have to fish it out of there, no networking either
[23:51] <slangasek> Laney: you can get gdm up by hand by running 'start dbus && start hal && start network-manager && start gdm'
[23:51] <slangasek> Laney: but we'd like the mountall log first, to know why it's not working automatically :)
[23:51] <Laney> mountall is still grinding away
[23:51] <Laney> should it take a while?
[23:53] <slangasek> Laney: oh, I would expect it to hang indefinitely; background it and grab the log
[23:53] <slangasek> Laney: btw, do you use LVM?
[23:53] <Laney> aha
[23:53] <Laney> slangasek: no, got an mdadm partition though
[23:54] <slangasek> kees: I think bug #431042 needs another pair of eyeballs; there've been 4 of these reports now, all of them recent and all of them involving something holding the debconf db open when trying to configure libpam-modules
[23:54] <Laney> slangasek: (which didn't get mounted)
[23:54] <kees> slangasek: reading...
[23:54] <slangasek> Laney: ok - please add that to the bug, that's the exact insight we need :)
[23:54] <Laney> This exposing bugs lark is fun
[23:55] <cjwatson> slangasek: 431042> mm, I saw that briefly and thought "isn't debconf just the messenger?"
[23:55] <cjwatson> or at least some other dup of it
[23:55] <slangasek> cjwatson: yes, I thought that for the first three instances that were filed against pam
[23:56] <slangasek> there's some sort of deeper issue here, but I don't know what
[23:57] <TheMuso> Is booting onto an LV a problem as well? If so, I'll hold off upgrading today as well. :)
[23:59] <bodhi_zazen> still working on fixing upstart from yesterday ?