[00:08] <maxb> dtchen: Thanks but that's not right, I don't think. Could you please push --overwrite my branch, not merge it?
[00:09] <maxb> Otherwise, the UDD importer is going to go a bit crazy if it has to do another import
[00:13] <maxb> james_w: I don't suppose you're around and would care to clarify this one?
[00:14] <lamont> 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] <dtchen> maxb: I'm having difficulty interpreting. Do you want me to replace the existing one with yours?
[00:17] <maxb> That's correct
[00:18] <Caesar> slangasek: this is an advanced heads-up that we may require a freeze exception for Puppet
[00:18] <lamont> cjwatson / slangasek : as in http://paste.ubuntu.com/341525/
[00:18] <dtchen> maxb: I apologize for misinterpreting then; I presumed "push" and "merge" [the latter in your URI] referred to a merging op.
[00:19] <lamont> line 489, for exmaple
[00:21] <ebroder> Any backporters around who could look at bug #315264?
[00:23] <maxb> 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] <maxb> (sorry for disappearing mid-conversation, there seems's to be a weird routing glitch affecting me here)
[00:25] <dtchen> maxb: should be fixed up now
[00:26] <maxb> looks good. Now, if we can just get the importer over whatever else it's coughing on regarding Subversion :-)
[00:26] <slangasek> lamont: I'm not a buildd admin, it sounds like this is a buildd admin tool?
[00:26] <slangasek> Caesar: is more detail available?
[00:46] <kirkland> 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] <persia> kirkland: Don't upstart scripts end up in /etc/init/${SERVICE}.conf usually, rather than /etc/init.d/${SERVICE} ?
[00:50] <StevenK> lamont: Still here?
[00:51] <StevenK> lamont: I'm looking at uploading a new livecd-rootfs, do you still need to merge BuildLiveCD changes manually?
[00:55] <slangasek> kirkland: bug in lintian
[00:55] <slangasek> kirkland: lintian needs to know not to run these checks when the script is a link to /lib/init/upstart-job
[00:57] <cjwatson> persia: there's a compat shim
[00:58] <persia> Ah.  Thanks.
[03:06] <smoser> slangasek, you know if 'start on mount MOUNTPOINT=/' (upstart)  per https://wiki.ubuntu.com/ServerLucidCloudBoothooks is supposed to work yet?
[03:13] <smoser> anyone else know ? it doesn't seem to be working for me, but didn't know if it was user error
[04:05] <slangasek> smoser: haven't heard of such a 'mount' event, no, sorry
[04:05] <smoser> 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] <smoser> and when i get it / is ro, i'd like to have it rw
[04:45] <jdong> [jdong@hideout:aa-tools/sudont]$ sudont tase me bro               (12-14 23:45)
[04:45] <jdong> *sigh*, grow up already...
[04:46] <jdong> that's what happens when I get bored :-/
[05:13] <ubuntu-crypto> anyone awake?
[05:15] <ScottK> No
[05:15] <ubuntu-crypto> the default crypto installer does not take kindly to EXt4
[05:15] <ubuntu-crypto> "cryptsetup: unknown fstype. Bad password or option?"
[05:17] <ubuntu-crypto> password is correct, i can mount it from this CD.
[05:30] <ubuntu-crypto> ScottK, any idea? it got reported as a launchpad bug.
[05:30] <ScottK> Nope.  Sorry
[05:33] <crypt-0-> nickserv pass is somewhere on one of the drives i am replacing
[05:33] <crypt-0-> Well i wanted to give EXT4 a try.
[05:34] <lamont> StevenK: BuildLiveCD updates --> RT
[05:34] <crypt-0-> Any pointers on where to look for obvious errors?
[05:34] <crypt-0-> Also, is the automated crypto installer documented anywhere?
[05:35] <crypt-0-> Im looking for a "how it works" not a "howto"
[05:58] <JFo> jono, are you still updating akgraner's wiki? I don't want to step on your updates.
[05:59] <JFo> nm, she told me you were finished :)
[06:00] <jono> JFo, done!
[06:00] <jono> thanks!
[06:01] <JFo> thank you sir
[06:02] <crypt-0-> "cryptsetup: unknown fstype. Bad password or option?" anyone have any ideas, or pointers?
[06:02] <crypt-0-> Im starting to think it does not like EXT4.
[06:02] <dtchen> that's odd, since I created crypt lvm containing ext4 just fine
[06:03] <dtchen> you might want to see bug 428435, however
[06:04] <crypt-0-> thanks dtchen
[06:08] <crypt-0-> dtchen, i can mount it ok on this LiveCD, and on my other installation.
[06:08] <crypt-0-> Just not at boot time.
[06:21] <lamont> wgrant: bzr+ssh://bazaar.launchpad.net/~lamont/launchpad/proposed-lpbuildd-version-53/  revision 9914 is the latest in love
[06:35] <crypt-0-> dtchen, you around?
[07:14] <pitti> Good morning
[07:24] <StevenK> pitti: Hey!
[07:27] <pitti> ¿noʎ ǝɹɐ ʍoɥ 'ǝʌǝʇs buıuɹoɯ poob
[07:27] <StevenK> pitti: Haha. Well, thanks.
[07:40] <dholbach> good morning
[07:41] <Caesar> slangasek: yeah, upstream may not be able to get 0.25.2 out in the timeframe necessary
[09:23] <slangasek> 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] <slangasek> 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] <Keybuk> slangasek: no, he didn't
[09:29] <Keybuk> from a glance, gdm would now be broken for anyone not using dkms
[09:30] <slangasek> Keybuk: confirmed here :-P
[09:35] <Keybuk> I'm going to revert his changes
[09:35] <pitti> 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] <slangasek> I'm not sure the dkms part is actually what's causing my failure ,though
[09:36] <pitti> booting with "text" and starting manually works
[09:36] <Keybuk> pitti: I've no idea why gdm would start "too early"
[09:36] <pitti> well, it started with 2.29.1-0ubuntu4, not sure
[09:36] <seb128__> re
[09:37] <pitti> either due to that, or because I installed plymouth
[09:37] <seb128__> pitti, version of what?
[09:37] <pitti> I'll watch it over the next days
[09:37] <Keybuk> pitti: more likely the latter
[09:37] <pitti> seb128__: gdm
[09:37] <seb128__> what started with it?
[09:37] <pitti> seb128__: X starts totally distorted and with only an error dialog (unreadable); I have to boot with 'text' and start manually
[09:38] <seb128__> speaking of gdm
[09:38] <seb128__> bug #496796
[09:38] <pitti> seems I have to do more experiments then :)
[09:38] <seb128__> who is responsive for that?
[09:38] <pitti> oh, perhaps it also was that, can't say
[09:38] <slangasek> I get that in cases that don't involve fsck
[09:38] <seb128__> pitti, the failsafe uses vesa too
[09:38] <seb128__> which doesn't work with kms...
[09:39] <seb128__> #ubuntu-x was discussing using fb yesterday
[09:40] <tseliot> what is it that should use fb?
[09:41] <seb128__> tseliot, read the bug I just pointed
[09:41] <seb128__> or bug #496773
[09:41] <tseliot> thanks, I'll have a look at it
[09:42] <seb128__> thank you
[09:42] <slangasek> are we currently guaranteed to have an fb in all cases?
[09:42] <Keybuk> nope
[09:42] <Keybuk> this is the problem with X
[09:42] <slangasek> right, so that's another regression in the gdm job...
[09:43] <Keybuk> it either needs a DRM/DRI device, a framebuffer, or just start it anyway
[09:43] <Keybuk> no it isn't
[09:43] <slangasek> ah, right, it's not
[09:43] <Keybuk> not how I had it written anyway
[09:43] <ogra> Keybuk, oh, so Bug #495874 isnt arm specific anymore ?
[09:44] <Keybuk> ogra: unknown, insufficient information
[09:44] <ogra> pitti, ^^^ you see the same ?
[09:44] <Keybuk> ogra: you haven't provided the strace I asked for
[09:44] <ogra> Keybuk, i'm on vacation as i said before .. mobile team is informed though
[09:45] <pitti> ogra: can't say for sure
[09:45] <Keybuk> ogra: then go on vacation ;)
[09:45] <seb128__> pitti, bug #496796 should be assigned to our team or not? I'm not sure
[09:45] <seb128__> pitti, it should be of bugs to watch in some way...
[09:46] <seb128__> pitti, it should be on the list of bugs to watch in some way...
[09:46] <ogra> Keybuk, 300-600 mails a day, i'm at least checking mails every second day to not have them pile up :)
[09:46] <Keybuk> ogra: that's not a vacation then :p
[09:46] <pitti> seb128__: right, putting on the release radar
[09:47] <seb128__> pitti, danke
[09:47] <pitti> will probably need Keybuk's input, but I assigned it to desktop for nwo
[09:47] <ogra> Keybuk, coming back nad sitting in front of a six digit inbox counter is no fun either :)
[09:48] <Keybuk> ogra: that's what the delete key is for
[09:48] <ogra> heh
[09:53] <tseliot> Keybuk: what do you think about the suggestion in bug #496796 ? Isn't an fb enough?
[09:53] <Keybuk> tseliot: which suggestion?
[09:54] <tseliot> Keybuk: changing /etc/init/gdm.conf so it checks "and stopped udevtrigger" instead of "or stopped udevtrigger
[09:54] <Keybuk> that would be wrong
[09:57] <tseliot> 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] <Keybuk> then gdm will start
[09:59] <tseliot> Keybuk: of course ;) but what happens in the system? Does it mean that we initialise gdm without a graphics device?
[09:59] <Keybuk> possibly
[09:59] <Keybuk> though since X modprobes the module it wants anyway, it's unlikely to be the issue
[10:00] <seb128__> Keybuk, any opinion on bug #496859?
[10:00] <Keybuk> also I see the same issue from time to time
[10:00] <Keybuk> and on my system, the i915 driver is loaded in the initramfs
[10:00] <persia> 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] <tseliot> Keybuk: does Lucid have the mountall hooks for plymouth already?
[10:00] <Keybuk> seb128__: X doesn't need to connect to the acpid socket, and makes no difference if it fails
[10:00] <Keybuk> tseliot: no
[10:00] <seb128__> Keybuk, could you write that on the bug? thanks ;-)
[10:01] <Keybuk> seb128__: done, marked Won't Fix
[10:01] <seb128__> Keybuk, thanks
[10:01] <tseliot> Keybuk: aah, that explains why the user can't see visual feedback of the fsck check
[10:03] <Keybuk> tseliot: no it doesn't
[10:03] <Keybuk> why does "the user" even have Plymouth installed?
[10:03] <Keybuk> it's not seeded and nothing depends on it
[10:03] <tseliot> Keybuk: because he wanted to try it, I guess
[10:04] <tseliot> "fsck's happen without any visual feedback when plymouth is installed"
[10:04] <tseliot> but yes, that's not the main problem
[10:04] <Keybuk> the only reply to that is "Well, Don't Do That Then"
[10:04] <tseliot> :-D
[10:06] <Keybuk> slangasek: could I get a new live fs build once my updated gdm package is built?
[10:07] <cjwatson> persia: doesn't appear to be
[10:07] <cjwatson> persia: and I'm seeing builds at the URL you quote ...
[10:08] <persia> Hum.  I appear to have overgeneralised from ports_daily-live.  Sorry.
[10:09] <cjwatson> daily-live builds only happen if the corresponding livefs build succeeds, so you can check livefs-build-logs
[10:10] <StevenK> cjwatson: I guess I need to wait for the LP rollout until I can install the netbook-live^ task?
[10:10] <cjwatson> StevenK: I'd expect so
[10:33] <Keybuk> tseliot: oh, and on the gdm-not-starting thing
[10:33] <Keybuk> in my testing so far, when gdm doesn't start, it's not that gdm-binary fails
[10:33] <Keybuk> it's that Upstart fails to even start the job
[10:33] <Keybuk> which is far more interesting
[10:34] <tseliot> oh
[10:36] <tseliot> 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] <Keybuk> I don't know yet
[10:36] <Keybuk> I know that if I pre-start exec touch /tmp/foo - that file never appears ;)
[10:36] <Keybuk> to debug, I need to get a boot where gdm fails to start
[10:36] <Keybuk> then crash upstart
[10:37] <Keybuk> to look at the job data and figure out why it didn't start it
[10:37] <tseliot> does it help if you trigger an fsck check?
[10:37] <Keybuk> no
[10:38] <tseliot> maybe get rid of the failsafex script and try to crash x?
[10:39] <tseliot> that should be easy
[10:41] <Keybuk> tseliot: not sure how crashing X would help ;)
[10:42] <tseliot> Keybuk: gdm wouldn't start, I guess
[10:42] <Keybuk> I think you're missing my point
[10:43] <tseliot> Keybuk: yes, probably ;)
[10:44] <Keybuk> in my tests, when you get those "no X" boots, gdm-binary was never started
[10:44] <Keybuk> I actually think that mountall stops sending the events to Upstart entirely
[10:44] <Keybuk> and I'm not sure why ;)
[10:47] <tseliot> Keybuk: oh, now I think I see your point
[10:48] <Keybuk> crashing upstart lets me run gdb over a core file, and look to see whether the filesystem event ever happened
[10:48] <Keybuk> (I think it isn't)
[10:50] <Keybuk> slangasek: yet again, it occurs to me to ask *why* dkms has to build the kernel modules on boot
[10:50] <Keybuk> and why it can't do it in postinst
[10:54] <pitti> Keybuk: it does
[10:54] <Keybuk> pitti: no it doesn't ;)
[10:54] <pitti> it's there for the case that you change the default kernel on boot
[10:54] <pitti> or install a custom one manually
[10:54] <pitti> it's the last line of defence
[10:55] <pitti> Keybuk: dkms uses /etc/kernel/postinst.d
[10:55] <Keybuk> so we add 2s to boot time in case someone installs a kernel while the machine is *POWERED OFF* ?
[10:55] <pitti> I agree that we shouldn't add 2 seconds for it :)
[10:55] <Keybuk> update-initramfs doesn't even defend that much
[10:56] <Keybuk> the problem is that it's not a defence
[10:56] <Keybuk> if you don't run the boot-time script, you don't get the module
[10:56] <Keybuk> even in the case where you didn't do anything stupid
[12:01] <Keybuk> the human brain is remarkably bad at answering the question "is that light flashing/pulsating?"
[12:02] <Keybuk> I often seem to go cross-eyed staring at the Minis to tell whether they're sleeping or installing images
[12:13] <jiboumans> 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] <Keybuk> jiboumans: I meant the difference between solidly-on and pulsating
[13:53] <smoser> Keybuk, ping. i had a question about https://wiki.ubuntu.com/ServerLucidCloudBoothooks
[14:22] <Keybuk> smoser: hi
[14:23] <smoser> hi. I'll pastebin the mail i have started? or would you prefer just for me to send it?
[14:23] <Keybuk> either is fine :)
[14:24] <smoser> Keybuk, http://paste.ubuntu.com/341909/
[14:25] <Keybuk> smoser: ah, the job is wrong
[14:26] <smoser> well of course :)
[14:26] <Keybuk> it should be "mounted" not "mount", and you'll need the mountall I haven't actually uploaded yet
[14:26] <smoser> :)
[14:27] <smoser> 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] <Keybuk> it shouldn't block the boot though
[14:27] <Keybuk> it will block the filesystem event, but that is deliberate
[14:27] <smoser> hmm... I can fairly easily reproduce if you're interested in seeing logs
[14:28] <Keybuk> kees: you are a numpty
[14:28] <Keybuk> smoser: yes please
[14:29] <smoser> verbose good enough? or do you want debug?
[14:29] <Keybuk> verbose should be fine
[14:30] <smoser> http://paste.ubuntu.com/341923/
[14:31] <smoser> If I boot with 'init=/bin/bash' and then remove the 'test.conf' and reboot, it will boot again
[14:34] <smoser> in the pastebin above, after 592 seconds, i get:
[14:34] <smoser> [  592.351775] Power down.
[14:37] <Keybuk> smoser: looks like the same bug I just independently fixed
[14:37] <Keybuk> eth0 can never come up
[14:37] <Keybuk> because kees is a numpty ;)
[14:37] <smoser> fair enough.  so, what should I do to get this working?  I need a mountall with 'mounted' event, and newer upstart ?
[14:38] <Keybuk> newer mountall and newer ifupdown
[14:40] <smoser> 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] <sgallagh> Keybuk: I haven't seen matthiaz around in a long while. Is he on vacation/changed nick?
[14:42] <sgallagh> 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] <smoser> sgallagh, i believe he's returning from vacation tomorrow.
[14:43] <Keybuk> smoser: yes, it should
[14:43] <Keybuk> smoser: the problem is that net-device-up eth0 never happens
[14:43] <Keybuk> because the network interface is never brought up
[14:43] <Keybuk> because it's waiting for network-interface-security to be started
[15:02] <Keybuk> kees: ;-)
[15:02] <Keybuk> mostly just teasing
[15:02] <Keybuk> but the ifupdown changes you did ... err ... broke it
[15:05] <kees> Keybuk: really? in which cases?  :(
[15:06] <Keybuk> kees: having anything other than lo in /etc/network/interfaces
[15:06] <Keybuk> no other interface would come up
[15:06] <Keybuk> bad times
[15:06] <Keybuk> dogs and cats living together
[15:06] <Keybuk> etc.
[15:08] <akgraner> jiboumans, Congrats being the New Server Manager....
[15:08] <kees> 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] <akgraner> jiboumans, and if you have 2 secs I'd like to speak to you about a possible interview for ubuntu user online
[15:10] <akgraner> 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] <Keybuk> kees: you were lucky enough that the networking job brought them up
[15:12] <Keybuk> rather than the network-interface job
[15:12] <Keybuk> if you look at your patch, here's why it won't work
[15:12] <Keybuk> start on foo and bar
[15:12] <Keybuk> instance $FOO
[15:12] <Keybuk> ...
[15:12] <Keybuk> foo happens
[15:12] <Keybuk> bar happens
[15:12] <Keybuk> ifup lo gets run
[15:13] <Keybuk> now foo happens again
[15:13] <Keybuk> ...
[15:13] <Keybuk> nothing happens
[15:13] <Keybuk> it's waiting for bar again
[15:13] <Keybuk> in your changes case, it would only work if network-interface-security was restarted for every single instance
[15:13] <Keybuk> which it isn't
[15:13] <Keybuk> (in fact, you went out of your way to make it a state so it couldn't possibly be <g>)
[15:23] <pitti> 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] <jdstrand> pitti: sure thing! thanks for all your work on this :)
[16:03] <kees> Keybuk: so... this is a bug in upstart then?  I thought service states were always available.
[16:03] <kees> Keybuk: i.e. I can always depend on "started Blah" since it's either running or not
[16:04] <kees> 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] <Keybuk> kees: no, it's an event
[16:04] <kees> Keybuk: what's the right way to achieve what I set out to do?
[16:04] <Keybuk> events are transient
[16:04] <Keybuk> once they've happened, all memory of them is gone
[16:04] <Keybuk> there isn't a way to achieve precisely what you wanted to do
[16:04] <kees> fun.
[16:04] <Keybuk> the way I rewrote it is better
[16:05] <kees> ok, I'd like to see/understand that.  is it uploaded?
[16:05] <HIDID> hello guys
[16:06] <Keybuk> it is
[16:06] <Keybuk> your network-interface-security job gets started as a result of the network-interface and networking jobs getting started
[16:06] <Keybuk> it'll hold it up (because upstart does that)
[16:06] <Keybuk> then the interface comes up
[16:06] <Keybuk> 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] <Keybuk> kees: though you had the right intentions
[16:08] <Keybuk> you just hit upstart bugs
[16:08] <kees> "Revert Kees's change; this flat out doesn't work.
[16:08] <kees> *snicker*
[16:09] <kees> it _did_ work, just not very well.  :P
[16:09] <kees> your diff is strange, lots of reverts.
[16:10] <kees> ah, _darcs
[16:11] <kees> Keybuk: oh, this is great, actually.  it lets me hook to n-m's job without touching n-m at all
[16:11] <kees> Keybuk: so, a job with  start on starting Blah  will finish before Blah starts?
[16:12] <ion> A service will be started before Blah starts, and a task will finish before Blah starts IIRC.
[16:12] <kees> hrm.
[16:13] <kees> sounds like I want to move it back to a task, then.
[16:13] <kees> 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] <arnau> Hello. Can somebody help me about configuring ubuntu in a toshiba laptop?
[16:15] <kees> ion: ah, ok
[16:37] <ion> The following packages will be REMOVED: hal{u}
[16:37] <ion> Yay
[16:41] <pitti> *squish* *zap* *die!*
[16:44] <pitti> 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] <pitti> cjwatson: will that sort out itself, or does that need to be handled manually? If so, how?
[16:46] <cjwatson> pitti: it'll sort itself out (with my assistance)
[16:46] <cjwatson> unfortunately it isn't yet generalised so that other admins can do it, which is a problem :(
[16:46] <pitti> ok, thank you
[16:46] <pitti> kenvandine: ^ FYI
[16:47] <cjwatson> I'll poke it now
[16:47] <kenvandine> thx cjwatson
[16:48] <ion> keybuk: The dkms update still left /etc/init/dkms_autoinstaller.conf to my machines.
[16:48] <superm1> 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
[16:48] <Keybuk> superm1: it's wrong
[16:49] <Keybuk> (and it takes 4s of boot time to do nothing)
[16:49] <Keybuk> but mostly it's wrong
[16:49] <superm1> 4s is a huge exaggeration
[16:49] <Keybuk> people boot old kernels because things went wrong with newly installed kernels or modules
[16:49] <Keybuk> the *last* thing they want is new modules being built
[16:49] <Keybuk> superm1: no, 4s was the time dkms took in today's charts on my mini
[16:49] <Keybuk> that's why I suddenly took interest :p
[16:49]  * Chipzz_ agrees with Keybuk 
[16:50] <Keybuk> ion: oh, yeah, think-o
[16:50] <Chipzz_> an alternative approach would be using a symlink farm that gets updated at boot time
[16:50] <superm1> was the 4s from the dkms_autoinstaller task, or the dkms status invokation in gdm's task?
[16:50] <Keybuk> superm1: both combined
[16:51] <cjwatson> make it a friendly-recovery task instead, or whatever that turns into?
[16:51] <superm1> 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] <Keybuk> cjwatson: we basically just dropped that
[16:51] <Keybuk> superm1: no idea
[16:51] <Keybuk> time regardless, it's wrong to do that
[16:52] <superm1> what if someone installs a custom kernel?
[16:52] <Keybuk> then the postinst of the kernel will run dkms
[16:52] <Chipzz_> superm1: couldn't the last line of defence be a symlink/symlink farm?
[16:52] <Keybuk> which will run the build
[16:52] <Keybuk> and build the modules for that kernel
[16:52] <superm1> i mean from src, not make-kpg
[16:52] <Chipzz_> on a related note, aren't these drivers also stored in a ramdisk or such?
[16:53] <Keybuk> 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] <ion> superm1: Then she deserves what she gets. :-P
[16:53] <superm1> Chipzz_, this is for any dkms built module, that might not be part of the ram disk
[16:53] <Keybuk> like an initramfs
[16:53] <Chipzz_> (which ALSO seems braindead)
[16:53] <Keybuk> or modules.dep
[16:53] <Keybuk> so they're going to have lots of "failed to boot" before they even *reach* dkms
[16:53] <Keybuk> (bearing in mind that the kernel's own "make install" runs distro hooks)
[16:54] <Caesar> slangasek: we're doing some more work on 0.25.1 in Debian
[16:54] <Keybuk> 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] <Keybuk> that just isn't going to work
[16:54] <Keybuk> for a whole metric shitload of reasons
[16:55] <superm1> 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] <superm1> *built
[16:55] <Keybuk> no idea on that one
[16:55] <Keybuk> but if there's a bug there, we'll fix it
[16:56] <Keybuk> 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] <superm1> it was the gdm task dying over and over because X couldnt start because closed source blob Y wasnt ready
[16:56] <Keybuk> if you updated the kernel and module in one pass, it wouldn't have worked before
[16:56] <Keybuk> the blob Y should have been built before the system was rebooted
[16:56] <superm1> agreed, but it wasnt, so thankfully there Was this last line of defense
[16:57] <Keybuk> in which case, I'd say your "last line of defence" was hiding a genuine bug
[16:58] <superm1> probably
[17:01] <Keybuk> superm1: I don't mean to particularly pick on you today :p
[17:01] <Keybuk> today was supposed to be a good day, with the new kernel going in, and lots of things speeding up
[17:02] <Keybuk> and having the gdm breakage, dkms breakage, ifupdown breakage, etc. all in one go has not made me cheerful :p
[17:03] <superm1> 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] <Keybuk> I would not
[17:03] <Keybuk> I think the task is absolutely unequivocably wrong
[17:03] <Keybuk> because it defeats the entire point of keeping old kernels around
[17:04] <Keybuk> you don't *want* new modules, changes to depmod, modules.order, etc. when you boot an old kernel
[17:04] <Keybuk> you want what worked last time
[17:04] <Keybuk> that's the only reason you keep them around at all
[17:04] <superm1> yeah i suppose that makes sense
[17:05] <Keybuk> 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] <superm1> did you update the /etc/kernel/postinst.d calls when you uploaded these last few revisions?
[17:05] <Keybuk> superm1: shouldn't need to - they were correct
[17:05] <Keybuk> kernel postinst should build modules for itself (passing the newly installed kernel version)
[17:05] <superm1> Keybuk, it was doing that by "start dkms_autoinstaller" if i'm not mistaken
[17:06] <Keybuk> it looked like it invoked it directly?
[17:06] <Keybuk> oh, blah
[17:06] <Keybuk> no, I did change it, but then didn't upload
[17:06] <superm1> http://linux.dell.com/git/?p=dkms.git;a=blob;f=kernel_postinst.d_dkms;h=3c7002b25dd5ebdfea7089557a20bfb38f067466;hb=HEAD
[17:08] <Keybuk> fixed ;)
[17:10] <Keybuk> FreeNode is being almost as reliable as my uploads today <g>
[17:10] <superm1> 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] <superm1> haha yeah
[17:10] <Pici> Keybuk: They're experiencing a ddos ;(
[17:10] <Keybuk> superm1: no, same problem
[17:10] <Keybuk> you'd rebuild a module that worked and replace it with one that didn;t
[17:10] <Keybuk> pitti and I talked about this earlier, and we'll instead fix X to fallback to the free driver in that situation
[17:11] <superm1> okay, that's a good enough consolation
[17:11] <Keybuk> (where the nvidia blob driver can't run with the older kernel module)
[17:26] <nixternal> anyone happen to know if the R packages are planned on making their way into main at all?
[17:27] <cjwatson> nixternal: any reason why they should?
[17:27] <Keybuk> I think we should veto that until they learn about namespaces
[17:30] <nixternal> cjwatson: so I can add the support to one of the KDE Educational packages :)
[17:40] <ion> keybuk: The current mountall code in bzr does some forks and execs before daemonizing, which confuses Upstart.
[17:40] <Keybuk> ion: it does? which?
[17:41] <ScottK> cjwatson: r-base is now a build-dep for kdeedu.  We can live without it if needed, but we like to provide the full experience for users.
[17:43] <dholbach> any requests for sessions at  https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep  or sessions you'd like to give there?
[17:44] <ion> keybuk: This is from a running system: http://pastebin.com/f3200af30
[17:44] <ion> keybuk: I’ll do a strace from the initial mountall run, a moment...
[17:48] <ion> keybuk: Huh. stracing initial mountall run shows it daemonizing first. But then, why does Upstart get confused about its pid when run without strace, and why does it fork-and-exec mounts before daemonizing when started from a running system?
[18:01] <ion> keybuk: Ah! What confused Upstart was the cat /proc/cmdline in mountall.conf. As long as mtab can’t be written, mountall won’t really fork-and-exec fake mounts before daemonizing.
[18:02] <Keybuk> ion: yeah, was just thinking that both of those might be the bugs ;)
[18:02] <Keybuk> the mounted() bit of mount_policy() should come out and move to after the fork
[18:02] <Keybuk> and the cmdline stuff should be fixed
[18:04]  * lamont lets pkgmanglebinary out of its timeout
[18:08] <ion> keybuk: Hm. On two systems, network-interface (lo) and networking seem to hang in start/starting which causes rc-sysinit never to be started.
[18:09] <Keybuk> yes, yes
[18:09] <Keybuk> just fixed
[18:09] <ion> Ach
[18:10] <Keybuk> http://people.canonical.com/~scott/tmp/ratchet-lucid-20091215-4.png
[18:10] <Keybuk> whee
[18:13] <kirkland> Keybuk: https://bugs.launchpad.net/bugs/496798
[18:13] <kirkland> Keybuk: any chance that's something you might be able to fix for the rest of us upstartifying our init scripts?
[18:13] <kirkland> ;-)
[18:15] <lamont> pitti: pkgmangler is out-of-jail, btw
[18:15] <Keybuk> kirkland: no, but if someone else wants to fix it, go right ahead
[18:15] <Keybuk> I have more than enough to do without learning Perl again :p
[18:15]  * kirkland tried to pass the buck to Keybuk, but failed :-)
[18:15] <Keybuk> cjwatson likes that kind of thing
[18:16] <Keybuk> slangasek does too <g>
[18:16] <Keybuk> hey, I remember your new boss practically *wrote* Perl ;P
[18:16] <Keybuk> jiboumans: ^ :p
[18:16] <cjwatson> not today, am trying to finish stuff off before going on holiday
[18:16] <kirkland> Keybuk: I figured there was a snowball's chance in hell of you fixing lintian for upstart :-D
[18:16] <kirkland> Keybuk: oh, good point ... jiboumans, wanna fix a bug by writing some perl?  :-)
[18:16] <jiboumans> ... did i just get volunteered for something?
[18:17] <slangasek> you've been invited to participate in the joys of Ubuntu collaboration
[18:17] <kirkland> jiboumans: I filed bug 496798, lintian is erroneously complaining about Eucalyptus' upstart scripts
[18:17] <Keybuk> kirkland: do I look like the kind of developer who runs lintian on his packages? :p
[18:18] <kirkland> jiboumans: lintian *thinks* these upstart scripts are init scripts, and so it applies the init script checks on them
[18:18] <kirkland> jiboumans: which fail miserably
[18:18] <jiboumans> kirkland: if you can write it down in english, i can fix it in perl
[18:18] <kirkland> Keybuk: hah ;-)  Nah, I just saw you were active online, and thought it would be fun to wind you up about this one
[18:19] <kirkland> jiboumans: cool, i'll add some details in the bug report, and assign it to you; it'll be a "fun" bug to fix, that will make some Ubuntu developers happy
[18:19] <Keybuk> kirkland: I know where you live
[18:19] <jiboumans> .. i don't like this 'fun'
[18:19] <Keybuk> Austin doesn't *have* to be saved when Texas is wiped off the map
[18:19] <kirkland> jiboumans: well, marginally happier ... they're already pretty miserable if they're dealing with Keybuk's Upstart :-D
[18:19] <jiboumans> kirkland: logs & linenumbers are our friend :)
[18:20] <kirkland> Keybuk: :-P
[18:22] <cjwatson> pitti: indicator-application permissions updated, although I'm afraid quite a lot of stuff moved into desktop-core as well (which is ubuntu-core-dev only) so you might not thank me for this update. unfortunately I don't have time to investigate it right now
[18:37] <pH_> hey guys
[18:37] <pH_> whats the best way to distribute ruby applications with dependencies on ruby gems and ruby?
[18:41] <pH_> hello?
[18:41] <pH_> whats the best way to distribute ruby applications with dependencies on ruby gems and ruby?
[18:41] <forscher> sorry, no idea
[18:46] <dobey> jpds: ping
[18:57] <spotter> weird Q, why does ubuntu use the ondemand governor always?  shouldn't it use the performance governor when on AC?
[19:02] <Keybuk> spotter: no
[19:03] <Keybuk> you should not be able to significantly tell the difference between the two
[19:03] <Keybuk> since ondemand ramps up the CPU as the load increases
[19:03] <Keybuk> *except*
[19:04] <Keybuk> that with ondemand, your power bill will likely be substantially cheaper
[19:04] <Keybuk> and if you're using a laptop, your chances of reproducing will be higher
[19:04] <Keybuk> (and amount of third degree burning to your legs lower)
[19:04] <ScottK> Bug or feature, depending on whose laptop is is.
[19:17] <spotter> I wouldn't say you can't tell the difference
[19:17] <spotter> there's no way ondemand can provide as good as an experience as performance
[19:17] <spotter> and if on AC, what's the benefit besides teeny tiny bit for environment
[19:28] <dobey> hrmm
[19:33] <spotter> to repeat what I tried to say b4, but may have been noised out I wouldn't say you can't tell the difference there's no way ondemand can provide as good as an experience as performance and if on AC, what's the benefit besides teeny tiny bit for environment
[19:34] <pecisk> hmmmm, interesting, virtualbox-ose-guest-x11 in lucid depends on xserver-xorg-core (>= 2:1.6.2), and there is xserver-xorg-core is up to 2:1.7.3.901, but apt-get claims packagre brokage
[19:34] <pecisk> brokage/breakage/s
[19:44] <pecisk> split?
[20:02] <pecisk> hmmmm, interesting, virtualbox-ose-guest-x11 in lucid depends on xserver-xorg-core (>= 2:1.6.2), and there is xserver-xorg-core is up to 2:1.7.3.901, but apt-get claims packagre breakage
[20:05] <tjaalton> nothing interesting about that. vbox needs to be rebuilt
[20:06] <tjaalton> it's the Provides that break the upgrade/install
[20:13] <pecisk> tjaalton, do I have to report it as bug or it will be fixed anyway?
[20:21] <tjaalton> pecisk: probably is already
[20:23] <pecisk> tjaalton, yeah, found it
[20:40] <qense> Bug 486024 looks somewhat like a duplicate of bug 466575 , but the first says the device is busy, the latter that it can't be found. Anyone here who knows a lot of devicekit and could help?
[20:49] <qense> apologises, I've got to go If you feel like answering my question, please do, I'll try to read the backlog. You could always mark the bug as a dup by yourself if you think it is.
[20:51] <andersk> Keybuk: there is a situation in which /etc/kernel/postinst.d/dkms is insufficient to guarantee that modules are always available for the current kernel.
[20:52] <Keybuk> andersk: what situation is that?
[20:52] <andersk> Namely, upgrading nvidia-185-kernel-source causes all old nvidia modules to be deleted and a new module for the current and newest kernels to be built.
[20:53] <andersk> So if you boot into an older kernel after upgrading the module package, one needs to be compiled at boot.
[20:53] <Keybuk> we've already discussed that
[20:53] <Keybuk> we're going to make X fallback to the free in that case
[20:54] <Keybuk> free driver
[20:55] <andersk> Hmm, okay.  I missed that.
[20:55] <andersk> However, video drivers aren’t the only user of dkms.  openafs has the same problem, and there’s no fallback there.
[20:55] <Keybuk> and it's arguably a bug that nvidia-kernel-source *deletes* things
[20:55] <Keybuk> andersk: it shouldn't delete things then
[20:56] <Keybuk> kernel postrm already takes care of that
[20:56] <andersk> But it’s important that the openafs kernel module is the same version as the userspace daemon, so it isn’t good enough to keep old modules around for old kernels.
[20:58] <Keybuk> so?
[20:58] <Keybuk> then don't boot into old kernels with it
[20:58] <Keybuk> or namespace the daemon by module version
[20:58] <Keybuk> as we're already doing with things like perf
[20:58] <Keybuk> their are proper and correct fixes for these things
[20:59] <superm1> there is another situation that i just thought of too that was benefiting the postinst.  if a user is booted into say 2.6.32-7-generic, and installs 2.6.32-8-generic but doesn't reboot yet, but installs bcmwl-kernel-source lets say.  the postinst doesn't know that the user actually wants the module on both kernels, and the kernel postinst won't catch it on either
[20:59] <Keybuk> yes it does
[21:00] <Keybuk> I fixed that
[21:00] <superm1> how?  the kernel postinst wont be called, if you install bcmwl AFTER installing the kernel
[21:00] <Keybuk> why not look
[21:00] <Keybuk> the same way we already solved this for the initramfs
[21:00] <Keybuk> if you install 2.6.32-8-generic, then install something that goes in the initramfs
[21:00] <slangasek> Keybuk: one more question about plymouth - the cryptsetup init script that you whiteboarded at UDS doesn't yet work reliably, because gdm kills plymouthd and once that happens, calling plymouth doesn't do anything sensible.  Is the X plymouth plugin still on the radar for lucid?
[21:00] <Keybuk> lo and behold
[21:00] <Keybuk> it works
[21:00] <Keybuk> slangasek: (a) yes
[21:01] <Keybuk> but also (b) gdm should never start before cryptsetup finishes
[21:01] <andersk> The module postinst (at least if it uses /usr/lib/dkms/common.postinst) builds modules for the current kernel and the “newest” kernel, which solves that particular problem.
[21:01] <Keybuk> now, I'm going to eat my dinner
[21:01] <superm1> andersk, yeah, that's why i'm filing bug 497149 for anything not using it
[21:01] <Keybuk> and watch Alicia Silverstone in a, like, really totally rad Jane Austen remake
[21:01] <Keybuk> :p
[21:01] <superm1> i think that will take care of this situation
[21:01] <slangasek> Keybuk: why, and how do you intend to ensure this?  cryptsetup can be used on lots of devices not related to our FHS mounts...
[21:02] <Keybuk> slangasek: I removed all that FHS/bootwait stuff
[21:02] <Keybuk> mountall waits for everything now
[21:02] <slangasek> uh
[21:02] <Keybuk> I got sick of the whining
[21:02] <slangasek> excluding network mounts, at least?
[21:02] <andersk> OTOH, if the user upgrades from 2.6.32-7-generic to 2.6.32-8-generic while they also have 2.6.33~rc1 installed for occasional testing, that fix isn’t quite good enough for them.
[21:02] <Keybuk> slangasek: no everything
[21:02] <Keybuk> right *going*
[21:03] <slangasek> well, that'll be a critical bug then :P
[21:07] <superm1> andersk, yeah, i'm not sure how to address that scenario
[21:08] <andersk> Well, there are certainly ways.  One way would be for common.postinst to build modules for _every_ kernel, or at least every kernel that’s at least as new as the current kernel.
[21:09] <andersk> But there are very plausable scenarios under which that would take a really long time.
[21:09] <superm1> yeah
[21:10] <andersk> Maybe dkms could try to parse out the current default kernel from GRUB and compile modules for that one too?  (Ew.)
[21:11] <slangasek> why is it a problem for it to take a long time, if it's done at package install time?
[21:12] <andersk> It probably isn’t a huge problem for most people, it’s just a little irritating for package upgrades to take many minutes.
[21:13] <slangasek> if you're aware enough to be irritated by this, aren't you aware enough to remove the old kernels you're not using?
[21:13] <andersk> *shrug* Perhaps.
[21:15] <andersk> They might not be old kernels; it could just be someone who’s installed several newer kernels than the current one but hasn’t rebooted into any of them yet.
[21:16] <andersk> If you’re okay with such users having to wait a long time for upgrades, I think this is a mostly workable solution.
[21:20] <slangasek> andersk: I think that's better than making them wait at boot time, sure
[21:55] <kees> bug 494575
[21:55] <Laney> you tease
[21:56] <kees> LP API is being slow it's not private...
[21:56] <wgrant> It is private.
[21:56] <kees> let me clarify, my tool for unprivating it is being slow
[21:56] <kees> bug 494575
[21:56] <wgrant> Heh.
[23:29] <ion> superm1: The xorg upload still leaves /etc/init/failsafe-x.conf to the system.
[23:30] <ion> superm1: Ah, sorry. I see it’s supposed to.
[23:43] <lamont> so... where is this REVU thing and how can I fetch source from someones upload to same?
[23:43] <lamont> thouhg I suppose I should be asking in -motu
[23:54] <cjwatson> lamont: revu.ubuntuwire.com
[23:54] <lamont> thanks
[23:59] <lamont> slangasek: you have implicit-pointer-functions checking globally now, holler if you find any false positives