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