[05:27] <Endler> Is anyone working on backporting the patch for kernel bug #8791 fixed in 2.6.23 to 2.6.22.  I'd like to try test gutsy, but all drives are on a HPT374 controller, so I'm out of luck until this patch is applied.
[05:29] <Endler> Seems like it going to be rough going for Gutsy using the .22 kernel with bugs fixed in .23
[07:18] <arno-t> Hi. I used git to get the feisty source, and did a make clean, make xconfig and "make-kpkg -rootcmd fakeroot --initrd linux_image". It did a lot of compiling and ended up with: "cannot change ownership of debian/linux-headers-2.6.20.arno1/usr/share" "Error 1". Suggestions? Are there better ways of compiling?
[08:49] <kraut> moinm
[06:18] <mjg59> BenC: My patch to add GTM and STM support to libata seems to have fallen out of gutsy
[06:19] <BenC> mjg59: Ok, we'll get it back in. Initially I had left it out because it didn't apply, and I was hoping it would get upstream
[06:19] <mjg59> BenC: Ok. It's kind of critical.
[06:20] <mjg59> I can't remember what the upstream situation was. I'll track that down and repush.
[06:22] <mjg59> BenC: Do you have a list of *all* the patches that were in feisty but haven't been applied to gutsy? I've asked this before and you gave me some, but that wasn't one of them. I'm uncomfortable not knowing what else has been dropped.
[06:23] <BenC> everyrthing from libata was dropped
[06:23] <BenC> all the acpi stuff got in
[06:23] <BenC> pretty much libata was left alone
[06:23] <mjg59> That's not the entire set of the kernel I touched
[06:23] <BenC> I did re-integrate the HPA patch though
[06:24] <BenC> mjg59: everything else is in there
[06:24] <mjg59> BenC: It's just that you previously told me that everything else was in there, which is why I've been scratching my head over this regression on HPs for a couple of months
[06:24] <BenC> libata was such an ugly delta it was near impossible to strip things out
[06:24] <mjg59> I'm happy to regenerate patches, but that's kind of hard if I don't know that they've been dropped :)
[06:25] <BenC> mjg59: unfortunately I deleted all the data I had from doing the feisty to gutsy merge :/
[06:25] <BenC> that whole deal isn't going to happen after gutsy because of the way we've been able to rebase the tree and keep it cleaner
[06:26] <mjg59> BenC: That makes life... awkward.
[06:26] <BenC> mjg59: I can take some time this weekend to go over the feisty patches and check against gutsy
[06:26] <mjg59> Ok, that would be helpful
[06:26] <BenC> but I'm pretty sure that libata was the only thing that got screwed on the merge for gutsy
[06:28] <mjg59> The GTM stuff /seems/ to be upstream now
[06:28] <mjg59> But not in 22
[06:31] <rtg> BenC: when are you planning to merge 2.6.22.5?
[06:32] <BenC> mjg59: ah, wonder if we can just cherry pick
[06:32] <BenC> will make gutsy+1 merge easier
[06:32] <BenC> rtg: should do it now while we still can
[06:32] <rtg> BenC: my thought exactly.
[06:32] <mjg59> BenC: It's in linus's tree, by the looks of it
[06:33] <BenC> mjg59: if you can give a SHA(s), we can pull it in
[06:33] <BenC> brb
[06:38] <zul_> BenC: got a sec?
[06:38] <BenC> yeah
[06:39] <zul_> for 84965 the microsoft keyboard bug there is a driver out there for 2.6.22 but it depends on a usb-hid input system that is not accepted upstream yet, not sure what to do
[06:40] <zul_> the hid simple driver interface is what its called
[06:41] <BenC> zul_: we can't fix the bug in current code?
[06:41] <zul_> nope doesnt look like it, its intertwinned with the interface
[06:41] <BenC> then we can't fix it :/
[06:42] <zul_> thats what I thought
[06:42] <zul_> oh well :)
[06:47] <zul_> ill give an explanation and place it as wont fix
[06:50] <zul_> done
[06:50] <zul_> back to oops training
[07:02] <mjg59> BenC: Ok, I have a patch
[07:03] <BenC> mjg59: 
[07:03] <BenC> err, cool
[07:03] <mjg59> BenC: Sent to kernel-team
[07:03] <BenC> I'm off to lunch in a bit
[07:03] <BenC> mjg59: thanks
[07:05] <BenC> \
[07:06] <rtg> mjg59: How come you don't use your kernel.ubuntu.com account to produce a git commit?
[07:07] <mjg59> Because I haven't got round to setting stuff up there yet
[07:12] <rtg> mjg59: cherry picking is a lot less work for me.
[07:13] <mjg59> rtg: I couldn't just pull this from upstream, because that would have introduced dependencies on various changes to libata-core that we don't want
[07:14] <rtg> mjg59: I know that. But cherry picking the final commit from your Gutsy tree is trivial.
[07:15] <rtg> trivial for me, that is.
[07:16] <mjg59> rtg: Just pipe the mail to git-applypatch?
[07:17] <mjg59> (git-am, rather)
[07:18] <rtg> mjg59: hmm, I've not used that one. Lemme give it a whirl.
[07:26] <rtg> mjg59: I think BenC and kylem need to look at it. Thats a big honking patch meddling in stuff I have no experience with.
[07:27] <mjg59> rtg: Probably a good thing you couldn't just pull it into the tree, then :)
[07:27] <rtg> mjg59: well, I always look first anyways.
[08:11] <mjg59> BenC: While the HPA code is in gutsy, it seems to be disabled by default
[08:11] <mjg59> (ata_ignore_hpa is 0)
[08:14] <elmo> maybe this is a stupid question, but wouldn't ignore_hpa being false, mean don't ignore it?
[08:15] <elmo> tho that might explain the problem I had on the Equium the other day
[08:15] <mjg59> elmo: If it doesn't ignore the HPA, the HPA is still in effect. Therefore your disk is smaller.
[08:16] <mjg59> So ata_ignore_hpa has to be true
[08:16] <elmo> oh, right
[08:16] <elmo> mjg59: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/134950 <- could that be due to HPA?
[08:17] <mjg59> elmo: Don't /think/ so
[08:17] <mjg59> I just saw exactly the same thing on this device
[08:18] <mjg59> Vista 32-bit or 64-bit?
[08:20] <elmo> mjg59: 32
[08:32] <mjg59> Ok, so it turns out that I've screwed that patch up
[08:32] <mjg59> Just working on it
[08:33] <mjg59> Right, much better
[08:33] <mjg59> Just need to figure out why atapi is unhappy
[08:41] <rtg> BenC: just pushed gutsy-lum for Dell 1420 sound fix. Try it on your XPS 1330.
[08:45] <mjg59> Ngh. Actually, these commands are failing on both devices
[09:30] <sparrw> when compiling a module, gcc is complaining "expected ')' before string constant" about MODULE_PARM(debug,"i");, there may be gcc/kernel version compatibilty issues.  any ideas?
[09:35] <IntuitiveNipple> sparrw: what are the lines leading up to that line? usually there's a syntax error, missing ; or something
[09:35] <infinity> s/MODULE_PARM(debug,"i")/module_param(debug, ulong, 0)/
[09:35] <sparrw> MODULE_AUTHOR("..."); MODULE_DESCRIPTION("..."); MODULE_LICENSE("...");
[09:35] <sparrw> infinity: ill try that
[09:36] <infinity> (or bool, or whatever)
[09:36] <infinity> Probably a bool, in your case, since debug's kinda an on or off thing.
[09:37] <sparrw> warning, return from incompatible pointer type...  probably bool then?
[09:37] <infinity> Well, I don't know, not having seen the rest of your code. :P
[09:37] <sparrw> yeah, ill just try it
[09:38] <infinity> I'd tend to want a debug flag to be bool, but that's just me.
[09:38] <IntuitiveNipple> what's the type of debug?
[09:38] <infinity> If I had to guess, based on "random C coder laziness", I'd guess it's an int currently.
[09:39] <infinity> Because, y'know, everything is an int.
[09:39] <infinity> Or a char.. *shudder*
[09:39] <sparrw> could be worse...  could be an assumed-32-bit-int  :)
[10:18] <sparrw> i have a problem with -dev packages...  /usr/include/unistd.h and /usr/include/xorg/xf86_ansic.h disagree wbout the definition of xf86usleep (and there are other conflicts)...  help
[10:18] <sparrw> ?