[01:03] <cwillu> what fires graphics-device-added?
[01:27] <bryce> dunno
[04:02] <superm1> bryce, the new failsafe X stuff still isn't working in proposed
[04:03] <superm1> trying to run sudo /etc/gdm/failsafeXServer gets me: http://pastebin.com/f41d318f3
[04:05] <superm1> probably because dexconf doesn't do anything?
[04:06] <bryce> could be
[04:07] <bryce> that error prints if    /etc/gdm/failsafeDexconf $driver $xorg_conf_failsafe   fails
[04:07] <bryce>   /etc/gdm/failsafeDexconf vesa /etc/X11/xorg.conf.failsafe
[04:08] <bryce> what happens when you run that?
[04:08] <superm1> returns error code 10
[04:08] <superm1> no file created
[04:09] <bryce> 10
[04:09] <bryce> huh
[04:09] <bryce> well maybe instead of generating an xorg.conf we should just provide a default one to slap in
[04:10] <superm1> here's why http://pastebin.com/f28e82dc7
[04:10] <superm1> i think just providing one is indeed the best solution
[04:10] <superm1> and then during lucid we can have casper just grab that failsafe one when safe graphics mode is activated
[04:11] <bryce> RET=10 xserver-xorg/config/device/driver doesn't exist
[04:11] <bryce> yeah debconf just isn't seeded with the stuff we need anymore
[04:13] <superm1> here's a bug to track this: https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/477149
[04:13] <ubottu> Launchpad bug 477149 in xorg "Failsafe X support added in proposed upload still doesn't work" [Undecided,New]
[04:17] <bryce> superm1, btw, I started page https://wiki.ubuntu.com/X/Bugs/Nvidia to keep track of the nvidia.ko failures.  Also see bug 453365
[04:17] <ubottu> Launchpad bug 453365 in gdm "dkms should start before gdm if needed for video driver" [Low,New] https://launchpad.net/bugs/453365
[04:17] <superm1> bryce, well actually nvidia.ko really shouldn't work here.... this is virtualbox :)
[04:17] <superm1> i intentionally used it to try to test the bulletproof-x kicking in
[04:20] <superm1> but that is another problem as anders is raising
[04:20] <superm1> i think the only way to solve it is to introduce an upstart job for DKMS to ensure gdm doesn't try to start up until the DKMS upstart job is done
[04:21] <bryce> can you review my proposed release note text on bug #474917 about the issue?
[04:21] <ubottu> Launchpad bug 474917 in nvidia-graphics-drivers-180 "nvidia drivers 185.xx compile into kernel 2.6.28 instead of 2.6.31 on update from jaunty to karmic" [Critical,Triaged] https://launchpad.net/bugs/474917
[04:22] <bryce> superm1, yeah you may be right.  I'm not certain if we could get an upstart job for that rolled out as an sru.  Probably worth trying though
[04:23] <superm1> well you got one rolled out for the failsafe-x stuff (albeit not working :P)
[04:23] <bryce> btw, on that bug they believe it is not a race condition but rather that dkms is targeting 2.6.28 and not 2.6.31, and not getting triggered at all on the boot
[04:23] <superm1> well that compilation to 2.6.28 is caused by the way the postinst for nvidia-185-kernel-source operates
[04:24] <superm1> but it should have gotten built against 2.6.31 later during the kernel.postisnt.d
[04:26] <superm1> i think it's best to at least attempt to serialize the DKMS build process to happen before GDM, it's not just a race condition, it's two things that shouldn't be running in parallel
[04:26] <superm1> longer term, slangasek's proposal for having a DKMS dpkg trigger might be a good idea too
[04:29] <bryce> could be, I didn't quite grasp the full workings of the concept there
[04:29] <superm1> the basic idea is that every package that would normally run DKMS in it's post install just registers a trigger to defer the DKMS run
[04:29] <superm1> once dpkg finishes everything else, it's last thing to do is process those triggers
[04:30] <bryce> ahh
[04:30] <superm1> it's the same stuff that causes the initrd to only be rebuilt once when you install 15 things that normally like to live in the initrd
[04:30] <bryce> yeah that makes sense
[04:31] <superm1> definitely if you don't already have some spec for UDS to talk about this kind of stuff, can you make one?  there's tons of these little things that can probably help a lot with the breakage that can be done for lucid
[04:36] <bryce> yeah not a bad idea
[04:39] <superm1> by then hopefully should have a good idea of where most of the breakage is too to make for good discussion points
[04:57] <bryce> just wish it didn't mean I have to write a spec afterwards ;-)
[05:01] <superm1> well i'll help with the DKMS and any casper bits
[05:01] <superm1> http://pastebin.com/f229bfe21
[05:02] <superm1> just tested that, and it looks like it properly serializes DKMS before GDM
[05:10] <superm1> i'll try to test that on real hardware early next week.  i've got a few other bits to fix for DKMS too that i'll try to squeeze into the same SRU upload
[05:26] <bryce> ok cool
[05:26] <bryce> I've got company this weekend, and will be on vaca wed-fri but will have mon/tue
=== kees__ is now known as kees