[13:50] <apw> Keybuk, thats an amazing jump in times since alpha-1
[13:50] <apw> (a positive jump)
[14:22] <Keybuk> apw: you mean a good jump? :p
[14:23] <apw> heheh yeah i do :)
[14:23] <apw> Keybuk, looks like you moved everything out to plumbing though, so i guess its a bit less good than it seems
[14:25] <Keybuk> i took out the framebuffer driver loading, etc.
[14:25] <Keybuk> so we could get a clear picture of where we're really at
[14:25] <Keybuk> if the cost of the splash screen is seconds, then that's an argument for trying to avoid having on
[14:32] <apw> yeah not much point if all it does is slow things down
[14:32] <apw> X seem to be doing a fine job ...
[14:33] <apw> kernel had a good increment, but most of its the usplash shift
[14:37] <Keybuk> yeah, definite half a second from the kernel itself though
[14:40] <Keybuk> the other bit that's not obvious is that it already takes almost 3s of plumbing to get gdm started
[14:40] <Keybuk> which is enough time to load the i915 driver in parallel
[14:40] <Keybuk> (blacklisting it doesn't speed that up any)
[14:43] <apw> Keybuk, ouch thats a long time
[14:43] <Keybuk> yeah
[14:43] <Keybuk> we budgeted 2s
[14:50] <apw> Keybuk, do we have any idea what the heck the dkms component is in that boot? is this a first boot or is that there in all boots
[14:51] <Keybuk> it's there in all boots
[14:51] <Keybuk> I just took an axe to dkms
[14:51] <Keybuk> mario will cry like a baby
[14:51] <Keybuk> but there's no reason in hell dkms needs to run on boot
[14:51] <Keybuk> it can build modules in postinst
[14:51] <apw> hehe ... /me thinks there is a reason
[14:52] <Keybuk> the reason is so that when you boot an old kernel, it recompiles drivers for you
[14:52] <Keybuk> which is clearly broken
[14:52] <Keybuk> if you boot an old kernel, it's because something with the new one *didn't work out*
[14:52] <apw> yeah that sounds like the reason
[14:52] <Keybuk> you don't want the new drivers backported - they might be the very things that were broken
[14:52] <Keybuk> not to mention that we don't rebuild the initramfs either
[14:52] <apw> a reasonable reposte to the argument me thinks
[14:53] <Keybuk> fabbione: hey!
[14:53] <apw> Keybuk, it feels like the dkms ending is when X starts
[14:53] <fabbione> Keybuk: hi
[14:53] <fabbione> feenode bump... just for a change
[14:54] <Keybuk> apw: it is
[14:54] <Keybuk> so dkms now doesn't have any boot-time scripts
[14:54] <Keybuk> because taking 4s made it go BEEEEP on my radar
[14:54] <apw> Keybuk, heh, so how much time you recon that is going to save?
[14:54] <Keybuk> apw: dunno
[14:54] <Keybuk> probably about a third of a second in reality
[14:55]  * apw isn't going to sniff at .3s
[14:55] <Keybuk> though a second copy does seem to block X for a second
[14:55] <Keybuk> so maybe 1.5s
[14:59] <fabbione> smells like fun
[14:59] <Keybuk> fabbione: yeah, we're still having fun here ;-)
[14:59] <Keybuk> how's things with you?
[14:59] <fabbione> pretty good
[15:00] <fabbione> we are about to open the new development cycle for the next cluster generation
[15:00] <fabbione> that's going to be a killer
[15:00] <Keybuk> fabbione: awesome
[15:00] <Keybuk> apw: did we ever chase down those modules.builtin patches?
[15:00] <fabbione> is there anybody here specifically in charge of dvb-t?
[15:00] <fabbione> kernel driver regression
[15:01] <Keybuk> fabbione: not specifically, but let either apw or smb know - depending whether it's lucid or karmic
[15:01] <fabbione> karmic
[15:01] <apw> Keybuk, i went looking for them on friday but didn't find them merged as yet
[15:01] <fabbione> can't really explain the meaning of regressions to my wife when she holds a MythTV remote
[15:01]  * smb knew fabbione just came to complain
[15:01] <Keybuk> apw: I don't think they're merged yet - but they would be nice
[15:01] <fabbione> smb: actually no.. i was about to offer help because I wrote most of that driver
[15:02] <Keybuk> the author is the new kbuild maintainer, so they have a good chance :p
[15:02] <fabbione> smb: and something did regress between .28 adn .31
[15:02] <Keybuk> shall I drop him a mail to find out the status, cc you, and if he says ok, then you can merge?
[15:02] <fabbione> smb: i really complain when you break LTS
[15:02] <smb> fabbione, Hey cool. Don't take me too seriously
[15:02] <fabbione> that really seriously annoy the hell out of me :)
[15:02] <smb> :)
[15:02] <fabbione> no trust me.. it takes a lot more than that to go on my nerves
[15:03] <smb> fabbione, Ok, so what do we have as info. You have a bug report already?
[15:04] <fabbione> Keybuk: btw.. nfs mount in karmic (with the new upstart jobs start) fails from time to time at boot, then recovers itself. Nothing critical whatsoever but spurious warnings can raise a flag for less experienced (l)users
[15:04] <fabbione> maybe you already know
[15:04] <fabbione> just can't even find the time to look at LP
[15:04] <Keybuk> fabbione: yeah, slangasek is looking into it
[15:05] <fabbione> ok
[15:05] <fabbione> it's really a non-issue :)
[15:05] <fabbione> "fail to mount /var/lib/mythtv/videos/porn" :P
[15:05] <fabbione> kind of thing ;)
[15:06] <apw> Keybuk, yep sounds like a plan to me
[15:07] <logari81> hi, could anyone give me a hint on "EE: Previous or current ABI file missing! " ? google doesn't know a lot about it.
[15:08] <fabbione> wow.. still ABI checker kicking in!
[15:08] <fabbione> impressive to see that stuff still holds up after 5 years we did it :)
[15:08] <smb> Heh, yeah. Amazing that google does not know anything about it
[15:09] <fabbione> exactly
[15:09] <smb> logari81, https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#ABI
[15:12] <logari81> smb: thanks, google probably knows enough about kernel ABI, but not about the error string I was looking for :) .
[15:14] <smb> logari81, Yeah, maybe. :) In short, you start a new version, you need to have the abi files from the last version. Check for debian.master/scripts/misc/getabis
[15:21] <Keybuk> apw: are you sure they didn't get merged?
[15:21] <apw> Keybuk, nope, they may have now, there was 10k changes in there today
[15:22] <Keybuk> ah no
[15:22] <Keybuk> some confusion over the branch
[15:22] <Keybuk> Subject: 	[resend][GIT PULL] kbuild updates for 2.6.33
[15:22] <Keybuk> From: 	Michal Marek <mmarek@suse.cz>
[15:23] <Keybuk> Date: 	12/12/09 14:47:30 (Sat, 12 Dec 2009 15:47:30 +0100)
[15:23] <Keybuk> is the relevant thread
[15:23] <Keybuk> the modules.builtin patches are in that tree
[15:36] <bjf> **
[15:36] <bjf> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:36] <bjf> **
[15:46] <apw> Keybuk, remind me was there a bug on this modules.builtin stuff to help coordinate the kernel/modprobe stuff?
[16:40] <bjaglin> rtg: thanks for the fsam7400 pull :)
[16:40] <rtg> bjaglin, np
[16:42] <apw> bjf, is there a bug associated with this 4MB buffer thing?
[16:42] <bjf> apw, no, a request from dtchen
[16:42] <apw> bjf ta
[16:46] <apw> bjf ... meeting in 15 ?
[16:47] <bjf> apw, yup
[16:50] <bjf> ##
[16:50] <bjf> ## Ubuntu Kernel Team Meeting - in 10 minutes - #ubuntu-meeting
[16:50] <bjf> ##
[16:54] <rtg> apw, do you remember where ubuntu/Kconfig gets picked up from when running 'make oldconfig' ?
[16:55] <apw> arch/x86/Kconfig ?
[16:56] <rtg> apw, ah!
[16:56] <rtg> thanks
[16:56] <apw> :)
[17:00] <bjf> ##
[17:00] <bjf> ## Meeting starting now
[17:00] <bjf> ##
[17:14] <apw> smb, you there?
[18:52] <Kano> hi, now it is 7 week after last karmic update and still no 2.6.31.7 update - since yesterday there is even .8. so who is sleeping all day long?
[18:57] <apw> the last karmic update was 6 days ago
[18:58] <Kano> apw: .7 and .8 kernels are already out - last with lots of ext4 fixes just like 2.6.32.1
[18:58] <apw> yep.  but just cause they are out 'now' doesn't mean they can be released now, we have processes to prevent regressions
[18:59] <Kano> well you told me that 1 week ago and absolutely nothing happend
[18:59] <Kano> is that the process?
[19:00] <apw> since 1 week ago we have released a security update and spun a new proposed, plus started reviewing the .8 patches.  so no, not nothing
[19:00] <Kano> nothing in git visable
[19:01] <apw> every release in the archive is in our tree
[19:01] <mjg59> Kano: Ubuntu release process is, I suspect, primarily oriented towards Ubuntu rather than being especially concerned about niche derived distributions
[19:02] <mjg59> Kano: Rebasing the Ubuntu patchset on top of newer upstream stable releases should be trivial for you to do yourself, if you're interested in doing so
[19:02] <mjg59> In most cases it would just be a single git command
[19:02] <apw> trust me, if we could get the stable updates out faster we would, they are nothing but a royal pain in the rear end to have more and more pending
[19:04] <Kano> mjg59: usually a git pull fails because of some sauce patches
[19:06] <Keybuk> Kano: that's probably why mjg59 said "rebase" instead
[19:06] <Kano> the question is: why are those patches not upsteam
[19:06] <Keybuk> Kano: the answer to that question can be found in each commit log
[19:06] <Kano> thats why the .X.Y releases are
[19:06] <Kano> i see no reason to add some extra ids or so just for U
[19:07] <Keybuk> in those kinds of cases, the patches came from the upstream kernel
[19:07] <Keybuk> just the current linux-2.6 tree rather than stable
[19:07] <Kano> the really needed ones are officially backported
[19:08] <apw> if you don't think any of the commits in our tree are needed other than those in 2.6.32.y why don't you make kernrels from there instead?
[19:08] <Keybuk> e.g.
[19:08] <Keybuk>     Note: This patch is useful to powertop to tell the utilisation of the sound
[19:08] <Keybuk>     device. It is cherry-picked from upstream
[19:08] <Keybuk>     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
[19:08] <Keybuk>     SHA ID: a2f6309e8
[19:08] <Keybuk> from the commit log of the first SAUCE patch I found
[19:08] <Keybuk> but, if you want to whine, I'm sure things like that won't stop you
[19:08] <Kano> apw: just for a few extra things like aufs and some drivers
[19:09] <apw> and thats how we end up with the patch load we have, things which people need which arn't in upstream in a timely fashion for our release schedule, its the same everywhere i am sure
[19:10] <Kano> but not all backports are applied, thats why a git pull even fails after you updated it
[19:19] <apw> indeed some patches are deemed too invasive or too risky dispite being in stable