[12:16] <BenC> mjg59: depends on where you are talking about
[12:16] <mjg59> BenC: Random driver patches
[12:16] <mjg59> Like the aforementioned quiesce-ipw2200
[12:16] <BenC> mjg59: most everything got forward ported, except all of sound, and anything that didn't patch cleanly
[12:16] <mjg59> BenC: Have you got a list of the ones that didn't apply?
[12:17] <BenC> I already took care of the ones I know about
[12:17] <mjg59> Ok
[12:17] <BenC> ipw2200 probably just got clobbered because I updated it and again, forgot about cherry-picking the quiesce patch
[12:17] <mjg59> Ok
[12:20] <BenC> cherry picked now
[12:21] <mjg59> Ta
[12:27] <mjg59> Hm.
[12:27] <mjg59> Shouldn't the kernelteam wiki page suggest using git:// rather than rsync:// ?
[12:40] <mjg59> BenC: Hm. There's a patch missing from the sdhci driver as well.
[12:40] <mjg59> (I was actually going to ask you to drop it, but still :) )
[04:48] <zul> BenC: ping
[04:49] <zul> http://xenbits.xensource.com/ext/linux-2.6.tip-xen.hg merc tree based off of 2.6.18 lets see how crazy i can be
[04:52] <BenC> please don't do a 2.6.18 xen...then ppl will start complaining "if we can have a 2.6.18 xen, why can't we have a normal kernel that's 2.6.18"
[04:52] <BenC> :)
[04:53] <zul> nah...im going to try to extract 2.6.17
[04:54] <BenC> there should be a way to get all the xen patches that aren't in linux-2.6 HEAD, and cherry-pick them to 2.6.17.y branch
[04:54] <zul> thats what im trying to find out
[04:55] <BenC> #git on OFTC might be helpful on how to do that
[04:58] <zul> okie dokie
[04:59] <zul> im going to go play some unreal while this downloads
[05:09] <zul> BenC: hmm...interesting
[05:09] <zul> VERSION = 2
[05:09] <zul> PATCHLEVEL = 6
[05:09] <zul> SUBLEVEL = 17
[05:09] <zul> EXTRAVERSION =
[05:09] <zul> NAME=Crazed Snow-Weasel
[05:23] <zul> ah ok...i see what redhat is doing..they are hardcoding mach-xen in their include files
[05:30] <scottevil> hello, I have a question I'd like to ask that people in #ubuntu don't seem to know
[05:31] <scottevil> I have hardware RAID, need to load a custom built module with the livecd to install ubuntu
[05:31] <scottevil> have vmware set up, built kernel module, but it is built with 2.6.15.7-ubuntu1
[05:31] <scottevil> where livecd (even latest daily) is 2.6.15-26
[05:32] <scottevil> and says struct kernel_module does not agree, so it will not load
[05:32] <scottevil> how do I get ahold of 2.6.15-26 kernel to build the proprietary module?
[05:32] <crimsun> you need linux-headers-2.6.15-26-$arch
[05:33] <scottevil> I am not completely new to ubuntu, but havent tried to do anything difficult yet
[05:33] <scottevil> can I apt-get that somehow?
[05:34] <crimsun> yes
[05:34] <scottevil> sudo apt-get linux-headers-2.6.15-26-386?
[05:34] <crimsun> apt-get install
[05:35] <scottevil> sudo apt-get install ....
[05:35] <scottevil> ?
[05:35] <crimsun> linux-headers-2.6.15-26-386  if you want $arch to be 386
[05:35] <crimsun> really, this is a #ubuntu question.
[05:35] <scottevil> I know I know, but I've been lurking there for a couple of days
[05:36] <scottevil> probably more of an ubuntuforums.org question actually :)
[05:37] <scottevil> one other question is, why linux-headers and not kernel-source?  I do have to build a kernel to build the module...
[05:38] <crimsun> because you compile external kernel modules against linux-headers, not linux-source
[05:39] <scottevil> ahh, interesting.  I wrote a kernel module as part of my job and didnt know that (very limited time to develop)
[05:40] <scottevil> will try that, thanks.
[05:40] <crimsun> np
[03:34] <zul> blah
[04:02] <jbailey> zul: hmm?
[04:03] <zul> i dont wanna work today
[04:06] <zul> hey jeff btw
[04:06] <ajmitch> hello jeff
[04:09] <jbailey> zul: Nor do I, but largely because on Thursday I'm not working for a short period of time
[04:09] <jbailey> And it's always hard to keep from going into vacation mode early. =)
[04:09] <jbailey> Hi andrew
[04:11] <zul> jbailey: yeah but im not suppose to be at work today and the wifey is freaking out again
[04:11] <jbailey> About you working?
[04:11] <jbailey> Offer to stop. ;)
[04:12] <zul> yeah well i have tomorrow off and taking thursday off
[04:22] <mjg59> Hm.
[04:22] <mjg59> We don't seem to have many acpi patches.
[04:23] <mjg59> Should probably be rectified...
[04:26] <jbailey> mjg59: What, your Ph.D leaving you too much spare time again? ;)
[04:26] <mjg59> Haha
[04:27] <mjg59> Actually, today, yes
[07:11] <Keybuk> so, if one steals the console from X, it gets upset
[07:35] <jbailey> Keybuk: More usplash playing? =)
[07:35] <jbailey> Keybuk: I noticed that until yesterday, I had to hit alt-f1 to get X to start.
[07:35] <jbailey> whatever did you guys do to the fonts, btw? =)
[07:35] <jbailey> And NM seems to work better now. =)
[07:35] <mjg59> jbailey: I fixed that
[07:36] <mjg59> Which fonts?
[07:36] <jbailey> In the little usplash box.
[07:36] <mjg59> usplash-with-svgalib uses a different font to usplash-with-bogl
[07:36] <jbailey> They now remind me of a hercules graphics card.
[07:36] <jbailey> Ah, I hadn't noticed that it'd changed from bogl.
[07:36] <mjg59> That's how it can run in different resolutions now
[07:36] <jbailey> Handy!
[07:37] <jbailey> Is svgalib actually cross platofrm, or is this just a hack for the most popular arches?
[07:38] <Keybuk> mjg59: interestingly, the svgalib version gets the palette badly wrong forme
[07:40] <mjg59> Keybuk: Interesting. How?
[07:40] <mjg59> jbailey: Should actually work on anything with a PC BIOS
[07:40] <mjg59> But pragmatically speaking, we have working framebuffers on everything other than x86 and amd64, so.
[07:41] <Keybuk> mjg59: 0 thru 8 are all black
[07:41] <mjg59> Keybuk: Oh. I get that as well. I assumed that the testcard was supposed to be broken like that.
[07:41] <Keybuk> mjg59: no
[07:41] <mjg59> Gosh, you're right
[07:41] <mjg59> Heh
[07:42] <mjg59> Ok, either the palette setting code or the de-RLEing code is wrong
[07:42] <Keybuk> the test card is a standard vga palette with 0 and 7 reversed
[07:42] <Keybuk> (ie, grey and black)
[07:42] <mjg59> Should be easy enough to fix
[07:46] <mjg59> The RLE stuff looks good, so I suspect it's the palette setting
[07:54] <mjg59> Keybuk: Ok, the colours are getting to vga_setpalette without any problems
[07:54] <mjg59> Ah. Then they're supposed to vanish into vesa.
[07:56] <mjg59> Hm. Could just set up a non-palettised screenmode, that would probably fix it :)
[08:23] <zul> interesting: http://kernel.macosforge.org/
[08:24] <mjg59> No drivers included
[08:24] <zul> ah that sucks
[09:46] <mjg59> BenC: I think we want newer acpi
[09:47] <crimsun> (and a newer alsa)
[09:48] <BenC> I grabbed aoa from latest alsa
[09:48] <BenC> latest also is filled with IRQF_* changes, so I need to take some time to grab the whole thing
[09:48] <crimsun> BenC: ah, ok, thanks.
[09:48] <BenC> mjg59: is there an easy way to get the latest acpi stuff?
[09:48] <mjg59> BenC: Nope
[09:48] <mjg59> I'm poking it now
[09:49] <fabbione> git diff
[09:49] <fabbione> -CONFIG_ACPI=y
[09:50] <fabbione> +# CONFIG_ACPI is not set
[09:50] <fabbione> whops..
[09:50] <BenC> hehe
[10:57] <mjg59> BenC: What's the issue with making 0386 SMP?
[10:57] <mjg59> -386
[10:57] <mjg59> Damned fingers
[11:05] <crimsun> BenC: RE: bug 40737: current ubuntu-2.6 git has the patch, which I submitted on 24 July, but the patch wasn't merged into ubuntu-2.6 until 01 Aug, so unless the reporter is using one of your daily kernels, the report for edgy (and dapper) is not current