[00:08] dtchen: Thanks but that's not right, I don't think. Could you please push --overwrite my branch, not merge it? [00:09] Otherwise, the UDD importer is going to go a bit crazy if it has to do another import === robbiew is now known as robbiew-afk [00:13] james_w: I don't suppose you're around and would care to clarify this one? [00:14] cjwatson/slangasek: so the new lp-buildd will spit out the errors inline, and then (if any) recap them all and print out the whole "oh hai, you're borked" at the end of the build and cause it to fail [00:16] maxb: I'm having difficulty interpreting. Do you want me to replace the existing one with yours? [00:17] That's correct [00:18] slangasek: this is an advanced heads-up that we may require a freeze exception for Puppet [00:18] cjwatson / slangasek : as in http://paste.ubuntu.com/341525/ [00:18] maxb: I apologize for misinterpreting then; I presumed "push" and "merge" [the latter in your URI] referred to a merging op. [00:19] line 489, for exmaple [00:21] Any backporters around who could look at bug #315264? [00:21] Launchpad bug 315264 in hardy-backports "Please backport config-package-dev 4.9 from Jaunty to Hardy/Intrepid" [Wishlist,Confirmed] https://launchpad.net/bugs/315264 [00:23] dtchen: No problem - I merged the package both in the bzr and packaging sense, so all that was left to do was to push the extra history into the official branch - If that makes any more sense? [00:24] (sorry for disappearing mid-conversation, there seems's to be a weird routing glitch affecting me here) [00:25] maxb: should be fixed up now [00:26] looks good. Now, if we can just get the importer over whatever else it's coughing on regarding Subversion :-) [00:26] lamont: I'm not a buildd admin, it sounds like this is a buildd admin tool? [00:26] Caesar: is more detail available? [00:46] slangasek: I'd like to clean up a bunch of lintian errors against Eucalyptus -- we have upstart scripts, so we're getting http://paste.ubuntu.com/341548/ [00:50] kirkland: Don't upstart scripts end up in /etc/init/${SERVICE}.conf usually, rather than /etc/init.d/${SERVICE} ? [00:50] lamont: Still here? [00:51] lamont: I'm looking at uploading a new livecd-rootfs, do you still need to merge BuildLiveCD changes manually? === yofel_ is now known as yofel [00:55] kirkland: bug in lintian === Pici` is now known as Pici [00:55] kirkland: lintian needs to know not to run these checks when the script is a link to /lib/init/upstart-job === spiv_ is now known as spiv [00:57] persia: there's a compat shim [00:58] Ah. Thanks. === jra is now known as Guest68790 === Guest68790 is now known as Justin === jussio1 is now known as Guest88592 === yofel_ is now known as yofel === Adri2000 is now known as Guest25225 === Hobbsee is now known as Guest78837 === yofel is now known as Guest7105 === Pici is now known as Guest66795 === ]reed[ is now known as [reed] === rmcbride_ is now known as rmcbride === nhandler is now known as Guest15490 === ]reed[ is now known as [reed] === ]reed[ is now known as [reed] === dous_ is now known as dous === Guest15490 is now known as nhandler [03:06] slangasek, you know if 'start on mount MOUNTPOINT=/' (upstart) per https://wiki.ubuntu.com/ServerLucidCloudBoothooks is supposed to work yet? === dottedma1 is now known as dottedmag [03:13] anyone else know ? it doesn't seem to be working for me, but didn't know if it was user error === wgrant_ is now known as wgrant === nixternal_ is now known as nixternal === cj_ is now known as cj === robbiew is now known as robbiew_ [04:05] smoser: haven't heard of such a 'mount' event, no, sorry [04:05] Scott typed what was there in the session, it appears it does work now, but i dont see where in 'mountall' it is emitted. [04:06] and when i get it / is ro, i'd like to have it rw === nhandler is now known as evilnhandler === JayFo is now known as JFo [04:45] [jdong@hideout:aa-tools/sudont]$ sudont tase me bro (12-14 23:45) [04:45] *sigh*, grow up already... [04:46] that's what happens when I get bored :-/ === dous_ is now known as dous [05:13] anyone awake? [05:15] No [05:15] the default crypto installer does not take kindly to EXt4 [05:15] "cryptsetup: unknown fstype. Bad password or option?" [05:17] password is correct, i can mount it from this CD. [05:30] ScottK, any idea? it got reported as a launchpad bug. [05:30] Nope. Sorry === ubuntu-crypto is now known as crypt-0 === crypt-0 is now known as crypt-0- [05:33] nickserv pass is somewhere on one of the drives i am replacing [05:33] Well i wanted to give EXT4 a try. [05:34] StevenK: BuildLiveCD updates --> RT [05:34] Any pointers on where to look for obvious errors? [05:34] Also, is the automated crypto installer documented anywhere? [05:35] Im looking for a "how it works" not a "howto" === asac_ is now known as asac === Guest25225 is now known as Adri2000 === RoAk is now known as RoAkSoax === Adri2000 is now known as Guest438 === Guest438 is now known as Adri2000 === Adri2000 is now known as Guest14290 === Guest14290 is now known as Adri2000 === Adri2000 is now known as Adri2000` [05:58] jono, are you still updating akgraner's wiki? I don't want to step on your updates. [05:59] nm, she told me you were finished :) [06:00] JFo, done! [06:00] thanks! [06:01] thank you sir [06:02] "cryptsetup: unknown fstype. Bad password or option?" anyone have any ideas, or pointers? [06:02] Im starting to think it does not like EXT4. [06:02] that's odd, since I created crypt lvm containing ext4 just fine [06:03] you might want to see bug 428435, however [06:03] Launchpad bug 428435 in util-linux "luks encrypted partition not detected" [High,Fix released] https://launchpad.net/bugs/428435 === yofel_ is now known as yofel [06:04] thanks dtchen [06:08] dtchen, i can mount it ok on this LiveCD, and on my other installation. [06:08] Just not at boot time. [06:21] wgrant: bzr+ssh://bazaar.launchpad.net/~lamont/launchpad/proposed-lpbuildd-version-53/ revision 9914 is the latest in love [06:35] dtchen, you around? === lifeless_ is now known as lifeless === Guest88592 is now known as jussi01 [07:14] Good morning [07:24] pitti: Hey! [07:27] ¿noʎ ǝɹɐ ʍoɥ 'ǝʌǝʇs buıuɹoɯ poob [07:27] pitti: Haha. Well, thanks. [07:40] good morning [07:41] slangasek: yeah, upstream may not be able to get 0.25.2 out in the timeframe necessary === ArneGoet1e is now known as ArneGoetje === saispo_ is now known as saispo [09:23] superm1: did you discuss these gdm job changes with Keybuk at all before making them? My understanding is that and+or in a job start condition is broken with current upstart [09:24] Caesar: 0.25.2> we currently have 0.24.8 in lucid - is there an 0.25.1 we should be pulling in between now and the freeze? [09:29] slangasek: no, he didn't [09:29] from a glance, gdm would now be broken for anyone not using dkms [09:30] Keybuk: confirmed here :-P [09:35] I'm going to revert his changes [09:35] Keybuk: speaking of which, yesterday gdm started too early apparently, I only got a wildly distorted error message after X started (too distorted to read it, though) [09:36] I'm not sure the dkms part is actually what's causing my failure ,though [09:36] booting with "text" and starting manually works [09:36] pitti: I've no idea why gdm would start "too early" [09:36] well, it started with 2.29.1-0ubuntu4, not sure [09:36] re [09:37] either due to that, or because I installed plymouth [09:37] pitti, version of what? [09:37] I'll watch it over the next days [09:37] pitti: more likely the latter [09:37] seb128__: gdm [09:37] what started with it? [09:37] seb128__: X starts totally distorted and with only an error dialog (unreadable); I have to boot with 'text' and start manually [09:38] speaking of gdm [09:38] bug #496796 [09:38] seems I have to do more experiments then :) [09:38] Launchpad bug 496796 in gdm "fsck on boot triggers failsafe x 100% of the time" [Undecided,New] https://launchpad.net/bugs/496796 [09:38] who is responsive for that? [09:38] oh, perhaps it also was that, can't say [09:38] I get that in cases that don't involve fsck [09:38] pitti, the failsafe uses vesa too [09:38] which doesn't work with kms... [09:39] #ubuntu-x was discussing using fb yesterday [09:40] what is it that should use fb? [09:41] tseliot, read the bug I just pointed [09:41] or bug #496773 [09:41] Launchpad bug 496773 in xorg "Failsafe X should pick fbdev instead of vesa if KMS is in use" [Wishlist,Triaged] https://launchpad.net/bugs/496773 [09:41] thanks, I'll have a look at it [09:42] thank you [09:42] are we currently guaranteed to have an fb in all cases? [09:42] nope [09:42] this is the problem with X [09:42] right, so that's another regression in the gdm job... [09:43] it either needs a DRM/DRI device, a framebuffer, or just start it anyway [09:43] no it isn't [09:43] ah, right, it's not [09:43] not how I had it written anyway [09:43] Keybuk, oh, so Bug #495874 isnt arm specific anymore ? [09:43] Launchpad bug 495874 in gdm "gdm dies on babbage2.5 board with recent boot speedup changes" [High,Incomplete] https://launchpad.net/bugs/495874 [09:44] ogra: unknown, insufficient information [09:44] pitti, ^^^ you see the same ? [09:44] ogra: you haven't provided the strace I asked for [09:44] Keybuk, i'm on vacation as i said before .. mobile team is informed though [09:45] ogra: can't say for sure [09:45] ogra: then go on vacation ;) [09:45] pitti, bug #496796 should be assigned to our team or not? I'm not sure [09:45] Launchpad bug 496796 in gdm "fsck on boot triggers failsafe x 100% of the time" [Undecided,New] https://launchpad.net/bugs/496796 [09:45] pitti, it should be of bugs to watch in some way... [09:46] pitti, it should be on the list of bugs to watch in some way... [09:46] Keybuk, 300-600 mails a day, i'm at least checking mails every second day to not have them pile up :) [09:46] ogra: that's not a vacation then :p [09:46] seb128__: right, putting on the release radar [09:47] pitti, danke [09:47] will probably need Keybuk's input, but I assigned it to desktop for nwo [09:47] Keybuk, coming back nad sitting in front of a six digit inbox counter is no fun either :) [09:48] ogra: that's what the delete key is for [09:48] heh [09:53] Keybuk: what do you think about the suggestion in bug #496796 ? Isn't an fb enough? [09:53] Launchpad bug 496796 in gdm "fsck on boot triggers failsafe x 100% of the time" [Undecided,New] https://launchpad.net/bugs/496796 [09:53] tseliot: which suggestion? [09:54] Keybuk: changing /etc/init/gdm.conf so it checks "and stopped udevtrigger" instead of "or stopped udevtrigger [09:54] that would be wrong [09:57] Keybuk: this is why I asked. But what happens if we get "stopped udevtrigger" without a drm-device-added or graphics-device-added? [09:57] then gdm will start [09:59] Keybuk: of course ;) but what happens in the system? Does it mean that we initialise gdm without a graphics device? [09:59] possibly [09:59] though since X modprobes the module it wants anyway, it's unlikely to be the issue [10:00] Keybuk, any opinion on bug #496859? [10:00] also I see the same issue from time to time [10:00] Launchpad bug 496859 in gdm "*dm upstart job should depend on acpid because X tries to connect to acpid socket very soon after starting." [Undecided,New] https://launchpad.net/bugs/496859 [10:00] and on my system, the i915 driver is loaded in the initramfs [10:00] Just out of curiosity, is image building disabled? I don't see anything for the last couple days at http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/lucid/ [10:00] Keybuk: does Lucid have the mountall hooks for plymouth already? [10:00] seb128__: X doesn't need to connect to the acpid socket, and makes no difference if it fails [10:00] tseliot: no [10:00] Keybuk, could you write that on the bug? thanks ;-) [10:01] seb128__: done, marked Won't Fix [10:01] Keybuk, thanks [10:01] Keybuk: aah, that explains why the user can't see visual feedback of the fsck check [10:03] tseliot: no it doesn't [10:03] why does "the user" even have Plymouth installed? [10:03] it's not seeded and nothing depends on it [10:03] Keybuk: because he wanted to try it, I guess [10:04] "fsck's happen without any visual feedback when plymouth is installed" [10:04] but yes, that's not the main problem [10:04] the only reply to that is "Well, Don't Do That Then" [10:04] :-D [10:06] slangasek: could I get a new live fs build once my updated gdm package is built? [10:07] persia: doesn't appear to be [10:07] persia: and I'm seeing builds at the URL you quote ... [10:08] Hum. I appear to have overgeneralised from ports_daily-live. Sorry. [10:09] daily-live builds only happen if the corresponding livefs build succeeds, so you can check livefs-build-logs [10:10] cjwatson: I guess I need to wait for the LP rollout until I can install the netbook-live^ task? [10:10] StevenK: I'd expect so === seb128__ is now known as seb128 === seb128 is now known as seb128_ === seb128_ is now known as seb128 === freeflyi1g is now known as freeflying === Madkiss_ is now known as Madkiss [10:33] tseliot: oh, and on the gdm-not-starting thing [10:33] in my testing so far, when gdm doesn't start, it's not that gdm-binary fails [10:33] it's that Upstart fails to even start the job [10:33] which is far more interesting [10:34] oh [10:36] Keybuk: what do you mean by "fails to start the job"? Are you saying that it doesn't depend on the conditions that we test for "start on"? [10:36] I don't know yet [10:36] I know that if I pre-start exec touch /tmp/foo - that file never appears ;) [10:36] to debug, I need to get a boot where gdm fails to start [10:36] then crash upstart [10:37] to look at the job data and figure out why it didn't start it [10:37] does it help if you trigger an fsck check? [10:37] no [10:38] maybe get rid of the failsafex script and try to crash x? [10:39] that should be easy [10:41] tseliot: not sure how crashing X would help ;) [10:42] Keybuk: gdm wouldn't start, I guess [10:42] I think you're missing my point [10:43] Keybuk: yes, probably ;) [10:44] in my tests, when you get those "no X" boots, gdm-binary was never started [10:44] I actually think that mountall stops sending the events to Upstart entirely [10:44] and I'm not sure why ;) [10:47] Keybuk: oh, now I think I see your point [10:48] crashing upstart lets me run gdb over a core file, and look to see whether the filesystem event ever happened [10:48] (I think it isn't) [10:50] slangasek: yet again, it occurs to me to ask *why* dkms has to build the kernel modules on boot [10:50] and why it can't do it in postinst [10:54] Keybuk: it does [10:54] pitti: no it doesn't ;) [10:54] it's there for the case that you change the default kernel on boot [10:54] or install a custom one manually [10:54] it's the last line of defence [10:55] Keybuk: dkms uses /etc/kernel/postinst.d [10:55] so we add 2s to boot time in case someone installs a kernel while the machine is *POWERED OFF* ? [10:55] I agree that we shouldn't add 2 seconds for it :) [10:55] update-initramfs doesn't even defend that much [10:56] the problem is that it's not a defence [10:56] if you don't run the boot-time script, you don't get the module [10:56] even in the case where you didn't do anything stupid === jelmer_ is now known as jelmer === Guest78837 is now known as Hobbsee === MacSlow is now known as MacSlow|lunch === Lutin_ is now known as Lutin [12:01] the human brain is remarkably bad at answering the question "is that light flashing/pulsating?" [12:02] I often seem to go cross-eyed staring at the Minis to tell whether they're sleeping or installing images [12:13] Keybuk: it's quite simple really. if you look at it for 3 minutes and you have a seizure, it was flashing. Otherwise, it's pulsating. [12:15] jiboumans: I meant the difference between solidly-on and pulsating === MacSlow|lunch is now known as MacSlow === dmart_ is now known as dmart === dmart_ is now known as dmart === dmart is now known as Guest66760 === Guest66760 is now known as dmart === dmart_ is now known as dmart [13:53] Keybuk, ping. i had a question about https://wiki.ubuntu.com/ServerLucidCloudBoothooks === jelmer_ is now known as jelmer [14:22] smoser: hi === Chex_ is now known as ChEx === ChEx is now known as Chex [14:23] hi. I'll pastebin the mail i have started? or would you prefer just for me to send it? [14:23] either is fine :) [14:24] Keybuk, http://paste.ubuntu.com/341909/ [14:25] smoser: ah, the job is wrong [14:26] well of course :) [14:26] it should be "mounted" not "mount", and you'll need the mountall I haven't actually uploaded yet [14:26] :) [14:27] that would explain it. i went looking for 'mounted' events, and found osme in the moutnall code, but wasn't getting them in upstart [14:27] it shouldn't block the boot though [14:27] it will block the filesystem event, but that is deliberate [14:27] hmm... I can fairly easily reproduce if you're interested in seeing logs [14:28] kees: you are a numpty [14:28] smoser: yes please === hile__ is now known as hile [14:29] verbose good enough? or do you want debug? [14:29] verbose should be fine [14:30] http://paste.ubuntu.com/341923/ [14:31] If I boot with 'init=/bin/bash' and then remove the 'test.conf' and reboot, it will boot again [14:34] in the pastebin above, after 592 seconds, i get: [14:34] [ 592.351775] Power down. [14:37] smoser: looks like the same bug I just independently fixed [14:37] eth0 can never come up [14:37] because kees is a numpty ;) [14:37] fair enough. so, what should I do to get this working? I need a mountall with 'mounted' event, and newer upstart ? [14:38] newer mountall and newer ifupdown [14:40] ok. then, just to be clear, at that point '(mounted MOUNTPOINT=/ and net-device-up IFACE=eth0)' should get me what i want [14:41] Keybuk: I haven't seen matthiaz around in a long while. Is he on vacation/changed nick? [14:42] Keybuk: I wanted to talk to him about getting some testing of SSSD 0.99.1 in Ubuntu before we release the final 1.0 version at the end of the week. [14:42] sgallagh, i believe he's returning from vacation tomorrow. [14:43] smoser: yes, it should [14:43] smoser: the problem is that net-device-up eth0 never happens [14:43] because the network interface is never brought up === mbarnett` is now known as mbarnett [14:43] because it's waiting for network-interface-security to be started === pitti is now known as fake_rickspencer === fake_rickspencer is now known as pitti [15:02] kees: ;-) [15:02] mostly just teasing [15:02] but the ifupdown changes you did ... err ... broke it [15:05] Keybuk: really? in which cases? :( [15:06] kees: having anything other than lo in /etc/network/interfaces [15:06] no other interface would come up [15:06] bad times [15:06] dogs and cats living together [15:06] etc. [15:08] jiboumans, Congrats being the New Server Manager.... [15:08] Keybuk: that is extremely strange; I have a stack of interfaces in /etc/network/interfaces and they all come up. I tested that and the n-m cases. :( [15:09] jiboumans, and if you have 2 secs I'd like to speak to you about a possible interview for ubuntu user online [15:10] jiboumans, here is where you can check out the others I have done on the platform team :-) http://www.ubuntu-user.com/Online/Blogs/Amber-Graner-You-in-Ubuntu [15:12] kees: you were lucky enough that the networking job brought them up [15:12] rather than the network-interface job [15:12] if you look at your patch, here's why it won't work [15:12] start on foo and bar [15:12] instance $FOO [15:12] ... [15:12] foo happens [15:12] bar happens [15:12] ifup lo gets run [15:13] now foo happens again [15:13] ... [15:13] nothing happens [15:13] it's waiting for bar again [15:13] in your changes case, it would only work if network-interface-security was restarted for every single instance [15:13] which it isn't [15:13] (in fact, you went out of your way to make it a state so it couldn't possibly be ) [15:23] jdstrand: bug 496923 is all your's now; please let me know if I can help with something else, but I'm afraid I can't do the uploads, etc. [15:23] Launchpad bug 496923 in postgresql-8.4 "Security/bug fix release: 8.4.2, 8.3.9, 8.1.19" [High,In progress] https://launchpad.net/bugs/496923 [15:23] pitti: sure thing! thanks for all your work on this :) === dendrobates is now known as dendro-afk === barry` is now known as barry_ === deryck is now known as deryck[lunch] === barry_ is now known as barry [16:03] Keybuk: so... this is a bug in upstart then? I thought service states were always available. [16:03] Keybuk: i.e. I can always depend on "started Blah" since it's either running or not [16:04] that's why I made network-interface-security a service instead of a task. I was specifically trying to avoid the situation you described since I knew of the "and" bug. [16:04] kees: no, it's an event [16:04] Keybuk: what's the right way to achieve what I set out to do? [16:04] events are transient [16:04] once they've happened, all memory of them is gone [16:04] there isn't a way to achieve precisely what you wanted to do [16:04] fun. [16:04] the way I rewrote it is better [16:05] ok, I'd like to see/understand that. is it uploaded? [16:05] hello guys [16:06] it is [16:06] your network-interface-security job gets started as a result of the network-interface and networking jobs getting started [16:06] it'll hold it up (because upstart does that) [16:06] then the interface comes up [16:06] but most importantly, the next time an interface comes up, your job is already running, so isn't re-run [16:07] * kees goes to read [16:08] kees: though you had the right intentions [16:08] you just hit upstart bugs [16:08] "Revert Kees's change; this flat out doesn't work. [16:08] *snicker* [16:09] it _did_ work, just not very well. :P [16:09] your diff is strange, lots of reverts. [16:10] ah, _darcs [16:11] Keybuk: oh, this is great, actually. it lets me hook to n-m's job without touching n-m at all [16:11] Keybuk: so, a job with start on starting Blah will finish before Blah starts? [16:12] A service will be started before Blah starts, and a task will finish before Blah starts IIRC. [16:12] hrm. [16:13] sounds like I want to move it back to a task, then. [16:13] I just want to avoid it being spawned multiple times. [16:14] * ion looks at network-interface-security.conf... pre-start script will finish before network-interface starts. [16:15] Hello. Can somebody help me about configuring ubuntu in a toshiba laptop? [16:15] ion: ah, ok === dendro-afk is now known as dendrobates === elky is now known as Guest10403 === tseliot1 is now known as tseliot === dendrobates is now known as dendro-afk [16:37] The following packages will be REMOVED: hal{u} [16:37] Yay [16:41] *squish* *zap* *die!* [16:44] cjwatson: indicator-application was recently NEWed, and is now depended on by rhythmbox (through libappindicator0); however, ./edit_acl.py -s indicator-application query gives no uploaders at all; conceptually it should be in the desktop set [16:44] cjwatson: will that sort out itself, or does that need to be handled manually? If so, how? [16:46] pitti: it'll sort itself out (with my assistance) [16:46] unfortunately it isn't yet generalised so that other admins can do it, which is a problem :( [16:46] ok, thank you [16:46] kenvandine: ^ FYI [16:47] I'll poke it now [16:47] thx cjwatson [16:48] keybuk: The dkms update still left /etc/init/dkms_autoinstaller.conf to my machines. [16:48] Keybuk, it is a supposed to be a last line of defense. the modules are normally built in the postinst of either the headers or the kernel === jelmer_ is now known as jelmer [16:48] superm1: it's wrong [16:49] (and it takes 4s of boot time to do nothing) [16:49] but mostly it's wrong [16:49] 4s is a huge exaggeration [16:49] people boot old kernels because things went wrong with newly installed kernels or modules [16:49] the *last* thing they want is new modules being built [16:49] superm1: no, 4s was the time dkms took in today's charts on my mini [16:49] that's why I suddenly took interest :p [16:49] * Chipzz_ agrees with Keybuk [16:50] ion: oh, yeah, think-o [16:50] an alternative approach would be using a symlink farm that gets updated at boot time [16:50] was the 4s from the dkms_autoinstaller task, or the dkms status invokation in gdm's task? [16:50] superm1: both combined [16:51] make it a friendly-recovery task instead, or whatever that turns into? [16:51] well i'm baffled how this is suddenly 4s. when it lived as an init script before, shouldn't it have been just the same? [16:51] cjwatson: we basically just dropped that [16:51] superm1: no idea [16:51] time regardless, it's wrong to do that [16:52] what if someone installs a custom kernel? [16:52] then the postinst of the kernel will run dkms [16:52] superm1: couldn't the last line of defence be a symlink/symlink farm? [16:52] which will run the build [16:52] and build the modules for that kernel [16:52] i mean from src, not make-kpg [16:52] on a related note, aren't these drivers also stored in a ramdisk or such? [16:53] if they install a custom kernel from source without running any of the kernel hooks, they won't have a whole world of things [16:53] superm1: Then she deserves what she gets. :-P [16:53] Chipzz_, this is for any dkms built module, that might not be part of the ram disk [16:53] like an initramfs [16:53] (which ALSO seems braindead) [16:53] or modules.dep [16:53] so they're going to have lots of "failed to boot" before they even *reach* dkms [16:53] (bearing in mind that the kernel's own "make install" runs distro hooks) [16:54] slangasek: we're doing some more work on 0.25.1 in Debian [16:54] so the only failure you're thinking of is someone building a kernel on one machine, and then copying, by hand, vmlinuz onto another and trying to boot with it [16:54] that just isn't going to work [16:54] for a whole metric shitload of reasons [16:55] there has to be some situation that is coming up here, otherwise there wouldnt have been the situation occurring where gdm was "flashing" for a while while the module was getting booted in karmic [16:55] *built [16:55] no idea on that one [16:55] but if there's a bug there, we'll fix it [16:56] it may be already fixed by the code I ported from update-initramfs into dkms to build the module for the right kernel [16:56] it was the gdm task dying over and over because X couldnt start because closed source blob Y wasnt ready [16:56] if you updated the kernel and module in one pass, it wouldn't have worked before [16:56] the blob Y should have been built before the system was rebooted [16:56] agreed, but it wasnt, so thankfully there Was this last line of defense [16:57] in which case, I'd say your "last line of defence" was hiding a genuine bug [16:58] probably === ogasawara_ is now known as ogasawara [17:01] superm1: I don't mean to particularly pick on you today :p [17:01] today was supposed to be a good day, with the new kernel going in, and lots of things speeding up [17:02] and having the gdm breakage, dkms breakage, ifupdown breakage, etc. all in one go has not made me cheerful :p === yofel_ is now known as yofel [17:03] i'd still really like to at least keep that dkms task if it can be changed to not be causing such a large slow down [17:03] I would not [17:03] I think the task is absolutely unequivocably wrong [17:03] because it defeats the entire point of keeping old kernels around [17:04] you don't *want* new modules, changes to depmod, modules.order, etc. when you boot an old kernel [17:04] you want what worked last time [17:04] that's the only reason you keep them around at all [17:04] yeah i suppose that makes sense [17:05] if old kernels didn't have a "the new stuff didn't boot" value, we would have tried harder to get rid of them ages ago :D [17:05] did you update the /etc/kernel/postinst.d calls when you uploaded these last few revisions? [17:05] superm1: shouldn't need to - they were correct [17:05] kernel postinst should build modules for itself (passing the newly installed kernel version) [17:05] Keybuk, it was doing that by "start dkms_autoinstaller" if i'm not mistaken [17:06] it looked like it invoked it directly? [17:06] oh, blah [17:06] no, I did change it, but then didn't upload [17:06] http://linux.dell.com/git/?p=dkms.git;a=blob;f=kernel_postinst.d_dkms;h=3c7002b25dd5ebdfea7089557a20bfb38f067466;hb=HEAD [17:08] fixed ;) [17:10] FreeNode is being almost as reliable as my uploads today [17:10] Keybuk, okay how would you feel about a task for fglrx and one for nvidia -provided by those packages that started on "starting gdm"? It would just do a dkms status for that module for that kernel, and if it failed, run a build for that module for that kernel. those were the two problem cases that were mostly interested in, and those are situations where you need the updated module even with older kernels [17:10] haha yeah [17:10] Keybuk: They're experiencing a ddos ;( [17:10] superm1: no, same problem [17:10] you'd rebuild a module that worked and replace it with one that didn;t [17:10] pitti and I talked about this earlier, and we'll instead fix X to fallback to the free driver in that situation [17:11] okay, that's a good enough consolation [17:11]