[10:33] <jose> please...what change is necessary in source.list to install linux-image-amd64-k8 ???
[03:34] <brokenthorn> Hello people
[03:34] <brokenthorn> I want to know how much will ubuntu break if I use a patched vanilla kernel (2.6.16-beyond)
[03:35] <brokenthorn> Are any patches applied to the ubuntu kernels critical to it's well function?
[03:44] <cjb> brokenthorn: Should work.
[03:44] <fabbione> all the bug fixes
[03:46] <fabbione> BenC: please pull from my dapper tree
[03:47] <fabbione> there should be only a cosmetic change left for debian/changelog
[03:47] <brokenthorn> cjb, What does usplash require in the kernel?
[03:47] <mjg59> Nothing
[03:47] <mjg59> Other than vga16fb
[03:47] <mjg59> Well, strictly, any working framebuffer
[03:48] <fabbione> we also fixed other stuff like modular vesa
[03:49] <alex_joni> mjg59: hi, any idea who maintains/knows about usplash on dapper?
[03:49] <mjg59> Me
[03:49] <mjg59> Or Scott
[03:50] <alex_joni> mjg59: yay .. I tried following https://wiki.ubuntu.com/USplashCustomizationHowto
[03:50] <alex_joni> but it stays black
[03:51] <alex_joni> I do notice an 'splash not found' or similar, while doing 'sudo dpkg-reconfigure linux-image-...'
[03:52] <mjg59> That's unrelated
[03:52] <mjg59> No idea, I'm afraid. The instructions look correct
[03:52] <alex_joni> mjg59: any idea how to debug? any options to usplash?
[03:52] <mjg59> Nope
[03:52] <mjg59> gdb is your best bet
[03:53] <alex_joni> ok, thanks.. 
[03:53] <infinity> alex_joni: Have you tried just running it at the command line, waiting for it to time out, and see if it had anything angry to say?
[03:53] <infinity> (Like a failed assertion because your splash image was bigger than your framebuffer, for instance)
[03:53] <alex_joni> running what at the command line?
[03:54] <infinity> usplash
[03:54] <alex_joni> infinity: nice point.. will try
[03:57] <alex_joni> infinity: how long is the timeout?
[03:59] <alex_joni> infinity: you were right.. 'Assertion 'yy + pixmap->height <= bogl_yres' failed.'
[04:13] <bernard_> that's pretty angry ;)
[04:33] <alex_joni> infinity: is there any way to make the picture centered?
[04:34] <alex_joni> infinity: if it's smaller, then it defaults top-left. I tried making the picture wider (630px, but it still is off..)
[04:38] <alex_joni> infinity: nm, I'm just beeing stupid today :(
[04:40] <alex_joni> mjg59: is there any place where I can read how the usplash stuff works?
[04:40] <mjg59> Nope
[04:40] <mjg59> The code is pretty straightforward, though
[04:41] <alex_joni> mjg59: I am wondering how to build a deb that contains the new usplash
[04:41] <alex_joni> or will a new make-kpkg already do that?
[04:43] <mjg59> No
[04:43] <mjg59> You need to provide the file in /usr/lib/usplash and update alternatives
[04:44] <zul> hey
[04:44] <infinity> zul: Hey dude, 2.6.12 failed on amd64 the same way that 2.6.10 did (more or less)
[04:44] <infinity> zul: 2.6.12 also failed on sparc.
[04:45] <infinity> zul: You want the logs?
[04:45] <zul> infinity: meh..
[04:45] <zul> yeah 
[04:45] <zul> im fixing breezy as we speak
[04:46] <alex_joni> mjg59: as a post-install ?
[04:46] <mjg59> alex_joni: Yes
[04:46] <alex_joni> mjg59: ty, so I guess I need to hack the make-kpkg debian/rules
[04:46] <zul> infinity: good morning to you too :)
[04:47] <infinity> alex_joni: Ideally, you don't want to distribute it with your kernel image.
[04:47] <alex_joni> infinity: why not?
[04:47] <mjg59> It would tie a kernel to a given picture
[04:47] <mjg59> Put the artwork in a separate package (which is how kubuntu, xubuntu and edubuntu do it)
[04:48] <alex_joni> oh.. ok, I'll investigate
[04:49] <infinity> zul: Sent.
[04:50] <zul> thanks...ill take care of it now
[04:50] <infinity> Danke.
[04:52] <alex_joni> mjg59, infinity: thanks, looks exactly like what I need
[05:09] <zul> grrr..
[05:44] <brokenthorn> mjg59, You said that usplash needs nothing than vga16fb or strictly any working framebuffer. 
[05:44] <brokenthorn> mjg59, I've chosen vesafb-tng
[05:45] <brokenthorn> mjg59, what default mode should I pass: 640x480@60?
[05:45] <brokenthorn> mjg59, So that bootsplash won't stay centered or scale ugly if so
[05:45] <brokenthorn> Anyone else know?
[06:19] <zul> infinity: any word on that email account?
[07:31] <BenC> infinity: is l-r-m uploaded for dapper?
[07:36] <mjg59> BenC: Hrm. CONFIG_USB_SUSPEND possibly ought to have been switched on.
[07:39] <BenC> mjg59: ok, done
[07:39] <mjg59> Ta
[07:46] <bernard_> mjg59: how experimental is that still?
[07:49] <mjg59> To the best of my knowledge, not very
[07:49] <mjg59> (Now - it used to be horribly flaky)
[07:51] <mjg59> Biggest issue is that it's also tied into device suspend as well as host suspend
[07:57] <bernard_> and the device suspend code isn't so crash hot?
[07:59] <bernard_> or just the fact that devices have to be suspended as well now?
[08:00] <zul> whee...fixing FTBS is fun..
[08:00] <mjg59> Yeah
[08:00] <mjg59> Hm. I should really set up a linux-laptop git tree at some point
[08:00] <BenC> zul: already fixed hoary/breezy FTBFS
[08:01] <zul> hoary yes, breezy still working it
[08:01] <BenC> I already did I mean :)
[08:01] <zul> oh...what about the sparc one?
[08:01] <BenC> didn't know about the sparc one
[08:01] <BenC> is that dapper?
[08:01] <zul> breezy
[08:03] <BenC> so will you take care of all of breezy?
[08:04] <zul> im lookin at it right now
[08:04] <BenC> I can send you my fixed dpatch for the i387 amd64 typo
[08:04] <zul> sure..
[08:05] <BenC> email?
[08:05] <zul> yes please
[08:05] <BenC> zulcss at something or other
[08:05] <zul> zulcss@gmail.com
[08:05] <BenC> ok, thanks :)
[08:06] <zul> http://zulinux.homelinux.net/ubuntu/kernel/sparc-error.txt
[08:06] <BenC> sent
[08:06] <BenC> why are we building kernels for breezy-sparc anyway?>
[08:08] <zul> infinity: had sent me the build logs and i assumed i ad to fix it *shrug*
[08:13] <BenC> just wondering why the build system even bothers :)
[08:13] <zul> hehe...dont as k me :)
[08:26] <zul> BenC: breezy is building now
[08:56] <zul> BenC: include/asm/i387.h:193: error: parse error before "GENERIC_NOP8"
[08:56] <BenC> interesting
[08:56] <BenC> breezy?
[08:58] <zul> yep
[08:58] <BenC> is that x86 or x86_64?
[08:59] <zul> x86_64
[09:00] <BenC> $ cat include/asm-x86_64/i387.h | wc -l
[09:00] <BenC> 150
[09:00] <BenC> how can there be an error on line 193?
[09:00] <zul> i dont think GERNIC_NOP8 is defined anywhere
[09:00] <BenC> but there are only 150 lines in the file
[09:01] <zul> mine has 220
[09:01] <zul> sh-3.00# cat i387.h | wc -l
[09:01] <zul> 220
[09:01] <zul> sh-3.00# pwd
[09:01] <zul> /tmp/linux-source-2.6.12-2.6.12/debian/build/build-amd64-generic/include/asm-x86_64
[09:02] <BenC> even the one in 2.6.17 is only 206 lines
[09:02] <zul> weird
[09:02] <BenC> something's not right
[09:02] <zul> yeah let me look around
[09:05] <BenC> zul: did you use the dpatch I sent you?
[09:05] <BenC> I put that into my breezy tree and it built
[09:06] <zul> grr...let me try again...
[09:07] <BenC> that patch does add about 50 lines, and I thought I had it patched when I checked the file size
[09:07] <BenC> I didn't, but now that I do, I still don't see a GENERIC_NOP8 in there
[09:07] <zul> same here
[09:09] <zul> can you send me the patch for breezy?
[09:18] <BenC> sent
[09:19] <zul> thanks..
[09:40] <zul> BenC: its building now
[10:13] <zul> BenC: should i do another upload with a version bump or how should i handle it
[11:31] <WebMaven> BenC: Whn do you think I'll see the new kernel as an update for Dapper?
[11:38] <BenC> zul: in the debian/changelog, change just bump the version on the same changelog entry
[11:38] <BenC> zul: and rename the debian/00list-* files to that version
[11:38] <BenC> WebMaven: it's up to the -security folks, I have no idea
[11:38] <BenC> they are probably waiting on the breezy update to finish
[11:39] <BenC> zul: debian/patches/00list-* files I mean
[11:39] <BenC> don't forget the hppa one
[11:40] <WebMaven> BenC: OK. So when will the Breezy update finish?
[11:40] <BenC> WebMaven: when it happens
[11:41] <WebMaven> BenC: Do you have an educated guess, based on your past experience?
[11:42] <BenC> anywhere from 1 hour to 7 days
[11:43] <WebMaven> Wow. Okay....
[11:43] <WebMaven> I guess I'll just wait then....
[11:43] <crimsun_> BenC rocks, but he can't predict the future. Yet.
[11:43] <WebMaven> Wasn't asking for a prediction, just a guess.
[11:51] <BenC> WebMaven: you do realize that this fixed kernel isn't going to act any different than with acpi=noirq kernel command line, right?
[11:56] <WebMaven> Right.
[11:57] <zul> BenC: breezy kernel built on amd64
[11:57] <WebMaven> But then, I won't have to worry about re-applying the fix when I do a kernel upgrade, or install the K7 kernel.
[11:58] <WebMaven> For example, I just un-installed the 2.6.17 kernel you had me test, and had to apply the flag to the 2.6.15 kernel that was applied by default.
[11:59] <WebMaven> I hate doing that.
[12:00] <WebMaven> I deal with a lot of FS, and install, upgrade, and modify it all the time, but it's all at the web-app-server level.
[12:00] <WebMaven> I really don't want to even have to think about the OS at all, and prefer think about the desktop as little as possible.
[12:03] <WebMaven> I know I'm acting a bit like a dog with a bone here, but I wasn't the first reporter for this bug, and I wouldn't be worrying about testing the new kernel so much if the previous reporter hadn't been blown off with only a workaround and no permanent fix.