=== JaneW [n=JaneW@dsl-146-167-152.telkomadsl.co.za] has joined #ubuntu-kernel === sevrin [n=sevrin@202.75.186.154] has joined #ubuntu-kernel === Lathiat [n=lathiat@ubuntu/member/pdpc.basic.lathiat] has left #ubuntu-kernel [] === tuxmaniac [n=aanjhan@59.92.44.253] has joined #ubuntu-kernel === tuxmaniac [n=aanjhan@59.92.48.73] has joined #ubuntu-kernel === Lure [n=lure@ubuntu/member/lure] has joined #ubuntu-kernel === doko_ [n=doko@dslb-088-073-104-140.pools.arcor-ip.net] has joined #ubuntu-kernel === jose [n=jose@201.211.101.163] has joined #ubuntu-kernel [10:33] please...what change is necessary in source.list to install linux-image-amd64-k8 ??? === jose [n=jose@201.211.101.163] has left #ubuntu-kernel ["Leaving"] === johnm [n=johnm@gentoo/developer/johnm] has joined #ubuntu-kernel === johnm [n=johnm@gentoo/developer/johnm] has joined #ubuntu-kernel === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel === brokenthorn [n=brokenth@85.204.146.192] has joined #ubuntu-kernel [03:34] Hello people [03:34] I want to know how much will ubuntu break if I use a patched vanilla kernel (2.6.16-beyond) [03:35] Are any patches applied to the ubuntu kernels critical to it's well function? [03:44] brokenthorn: Should work. [03:44] all the bug fixes [03:46] BenC: please pull from my dapper tree [03:47] there should be only a cosmetic change left for debian/changelog [03:47] cjb, What does usplash require in the kernel? [03:47] Nothing [03:47] Other than vga16fb [03:47] Well, strictly, any working framebuffer [03:48] we also fixed other stuff like modular vesa [03:49] mjg59: hi, any idea who maintains/knows about usplash on dapper? [03:49] Me [03:49] Or Scott [03:50] mjg59: yay .. I tried following https://wiki.ubuntu.com/USplashCustomizationHowto [03:50] but it stays black [03:51] I do notice an 'splash not found' or similar, while doing 'sudo dpkg-reconfigure linux-image-...' [03:52] That's unrelated [03:52] No idea, I'm afraid. The instructions look correct [03:52] mjg59: any idea how to debug? any options to usplash? [03:52] Nope [03:52] gdb is your best bet [03:53] ok, thanks.. [03:53] 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] (Like a failed assertion because your splash image was bigger than your framebuffer, for instance) [03:53] running what at the command line? [03:54] usplash [03:54] infinity: nice point.. will try [03:57] infinity: how long is the timeout? [03:59] infinity: you were right.. 'Assertion 'yy + pixmap->height <= bogl_yres' failed.' === tuxmaniac [n=aanjhan@59.92.58.55] has joined #ubuntu-kernel [04:13] that's pretty angry ;) [04:33] infinity: is there any way to make the picture centered? [04:34] infinity: if it's smaller, then it defaults top-left. I tried making the picture wider (630px, but it still is off..) [04:38] infinity: nm, I'm just beeing stupid today :( [04:40] mjg59: is there any place where I can read how the usplash stuff works? [04:40] Nope [04:40] The code is pretty straightforward, though [04:41] mjg59: I am wondering how to build a deb that contains the new usplash [04:41] or will a new make-kpkg already do that? [04:43] No [04:43] You need to provide the file in /usr/lib/usplash and update alternatives === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [04:44] hey [04:44] zul: Hey dude, 2.6.12 failed on amd64 the same way that 2.6.10 did (more or less) [04:44] zul: 2.6.12 also failed on sparc. [04:45] zul: You want the logs? [04:45] infinity: meh.. [04:45] yeah [04:45] im fixing breezy as we speak [04:46] mjg59: as a post-install ? [04:46] alex_joni: Yes [04:46] mjg59: ty, so I guess I need to hack the make-kpkg debian/rules [04:46] infinity: good morning to you too :) [04:47] alex_joni: Ideally, you don't want to distribute it with your kernel image. [04:47] infinity: why not? [04:47] It would tie a kernel to a given picture [04:47] Put the artwork in a separate package (which is how kubuntu, xubuntu and edubuntu do it) === tuxmaniac [n=aanjhan@59.92.40.159] has joined #ubuntu-kernel [04:48] oh.. ok, I'll investigate [04:49] zul: Sent. [04:50] thanks...ill take care of it now [04:50] Danke. [04:52] mjg59, infinity: thanks, looks exactly like what I need [05:09] grrr.. === Lure [n=lure@ubuntu/member/lure] has joined #ubuntu-kernel === tuxmaniac [n=aanjhan@59.92.49.182] has joined #ubuntu-kernel === Lukketto [n=Lukketto@host147-92.pool8261.interbusiness.it] has joined #ubuntu-kernel === Lukketto [n=Lukketto@host147-92.pool8261.interbusiness.it] has left #ubuntu-kernel [] [05:44] mjg59, You said that usplash needs nothing than vga16fb or strictly any working framebuffer. [05:44] mjg59, I've chosen vesafb-tng [05:45] mjg59, what default mode should I pass: 640x480@60? [05:45] mjg59, So that bootsplash won't stay centered or scale ugly if so [05:45] Anyone else know? === NuxTech [n=nux@dsl-146-68-236.telkomadsl.co.za] has joined #ubuntu-kernel === NuxTech [n=nux@dsl-146-68-236.telkomadsl.co.za] has left #ubuntu-kernel [] === Keybuk [n=scott@syndicate.netsplit.com] has joined #ubuntu-kernel [06:19] infinity: any word on that email account? === ajmitch [n=ajmitch@203.89.166.123] has joined #ubuntu-kernel [07:31] infinity: is l-r-m uploaded for dapper? [07:36] BenC: Hrm. CONFIG_USB_SUSPEND possibly ought to have been switched on. [07:39] mjg59: ok, done [07:39] Ta [07:46] mjg59: how experimental is that still? [07:49] To the best of my knowledge, not very [07:49] (Now - it used to be horribly flaky) [07:51] Biggest issue is that it's also tied into device suspend as well as host suspend [07:57] and the device suspend code isn't so crash hot? [07:59] or just the fact that devices have to be suspended as well now? [08:00] whee...fixing FTBS is fun.. [08:00] Yeah [08:00] Hm. I should really set up a linux-laptop git tree at some point [08:00] zul: already fixed hoary/breezy FTBFS [08:01] hoary yes, breezy still working it [08:01] I already did I mean :) [08:01] oh...what about the sparc one? === ajmitch__ [n=ajmitch@203.89.166.123] has joined #ubuntu-kernel [08:01] didn't know about the sparc one [08:01] is that dapper? [08:01] breezy [08:03] so will you take care of all of breezy? [08:04] im lookin at it right now [08:04] I can send you my fixed dpatch for the i387 amd64 typo [08:04] sure.. [08:05] email? [08:05] yes please [08:05] zulcss at something or other [08:05] zulcss@gmail.com [08:05] ok, thanks :) [08:06] http://zulinux.homelinux.net/ubuntu/kernel/sparc-error.txt [08:06] sent [08:06] why are we building kernels for breezy-sparc anyway?> [08:08] infinity: had sent me the build logs and i assumed i ad to fix it *shrug* === johnm [n=johnm@gentoo/developer/johnm] has joined #ubuntu-kernel [08:13] just wondering why the build system even bothers :) [08:13] hehe...dont as k me :) [08:26] BenC: breezy is building now === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [08:56] BenC: include/asm/i387.h:193: error: parse error before "GENERIC_NOP8" [08:56] interesting [08:56] breezy? [08:58] yep [08:58] is that x86 or x86_64? [08:59] x86_64 [09:00] $ cat include/asm-x86_64/i387.h | wc -l [09:00] 150 [09:00] how can there be an error on line 193? [09:00] i dont think GERNIC_NOP8 is defined anywhere [09:00] but there are only 150 lines in the file [09:01] mine has 220 [09:01] sh-3.00# cat i387.h | wc -l [09:01] 220 [09:01] sh-3.00# pwd [09:01] /tmp/linux-source-2.6.12-2.6.12/debian/build/build-amd64-generic/include/asm-x86_64 [09:02] even the one in 2.6.17 is only 206 lines [09:02] weird [09:02] something's not right [09:02] yeah let me look around [09:05] zul: did you use the dpatch I sent you? [09:05] I put that into my breezy tree and it built [09:06] grr...let me try again... [09:07] that patch does add about 50 lines, and I thought I had it patched when I checked the file size [09:07] I didn't, but now that I do, I still don't see a GENERIC_NOP8 in there [09:07] same here [09:09] can you send me the patch for breezy? [09:18] sent [09:19] thanks.. === ajmitch [n=ajmitch@203.89.166.123] has joined #ubuntu-kernel [09:40] BenC: its building now [10:13] BenC: should i do another upload with a version bump or how should i handle it === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [11:31] BenC: Whn do you think I'll see the new kernel as an update for Dapper? [11:38] zul: in the debian/changelog, change just bump the version on the same changelog entry [11:38] zul: and rename the debian/00list-* files to that version [11:38] WebMaven: it's up to the -security folks, I have no idea [11:38] they are probably waiting on the breezy update to finish [11:39] zul: debian/patches/00list-* files I mean [11:39] don't forget the hppa one [11:40] BenC: OK. So when will the Breezy update finish? [11:40] WebMaven: when it happens === WebMaven rolls eyes [11:41] BenC: Do you have an educated guess, based on your past experience? [11:42] anywhere from 1 hour to 7 days [11:43] Wow. Okay.... [11:43] I guess I'll just wait then.... [11:43] BenC rocks, but he can't predict the future. Yet. [11:43] Wasn't asking for a prediction, just a guess. === WebMaven settles in for a long wait. === lloydinho [n=andreas@rosinante.egmont-kol.dk] has joined #ubuntu-kernel [11:51] 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] Right. [11:57] BenC: breezy kernel built on amd64 [11:57] 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] 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] I hate doing that. [12:00] 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] 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] 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.