[00:03] <achiang> camden: i've never tried applying them myself, but my impression is that con develops against upstream linux, not the ubuntu tree
[00:05] <camden> this is my impression as well
[00:06] <camden> I may have had some success
[00:06] <camden> we will see when my compilation is done.
[00:11] <godber> Anyone have time for, what I hope is, a quick newbie question?
[00:11] <achiang> godber: just ask. someone may see the question later and have a response
[00:11] <godber> just want to know how to build for x86 when on amd64
[00:12] <godber> https://help.ubuntu.com/community/Kernel/Compile
[00:12] <godber> according to those instructions ^^
[00:12] <godber> does running
[00:12] <godber> debian/scripts/misc/oldconfig ARCH
[00:12] <godber> somehow make the build be for that architecture?
[00:13] <achiang> godber: i'm confused. what is it you are trying to do? build a 32 bit kernel or a 64 bit kernel? it sounds like you have a 64 bit host, is that right?
[00:14] <godber> yes, 64bit host
[00:14] <godber> want a 32bit kernel
[00:14] <achiang> godber: i'm not familiar with the Ubuntu way. but the upstream way is to say: linux32 make
[00:14] <godber> ok
[00:15] <achiang> godber: so, you might want to experiment with: linux32 debian/scripts/misc/oldconfig x86
[00:15] <godber> yeah, I am trying that right now ... will let you know, thanks
[00:16] <godber> except of course oldconfig doesnt exist
[00:18] <godber> theres kernelconfig
[00:18] <achiang> godber: did you run debian/rules updateconfigs ?
[00:18] <godber> oh, I thought those were alternatives
[00:18] <godber> will try
[00:18] <achiang> godber: and probably, what you want would be: linux32 debian/rules updateconfigs
[00:18] <achiang> godber: but i'm just guessing.
[00:19] <godber> k
[00:19] <godber> actually looking at the kernelconfig script, it looks like it might do the same thing
[00:19] <achiang> godber: should i ask why you think you want to do this? or should i be afraid? :)
[00:20] <godber> well, I have been questioning the wisdom of my actions all day
[00:20] <godber> since I put the odds of success low
[00:20] <godber> but I was going to try and identify which patch causes 
[00:20] <godber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/659422
[00:20] <ubot2> Launchpad bug 659422 in linux (Ubuntu) "Boot failure after upgrading kernel to 2.6.32-25-generic (affects: 4) (heat: 133)" [Undecided,New]
[00:22] <camden> alright, kernel done. wish me luck
[00:23] <achiang> godber: yuck.
[00:24] <achiang> godber: i assume you're doing a git bisection run, and not a manual one?
[00:24] <godber> agreed, but until I can convince someone to care, I am out of luck
[00:24] <godber> that was the plan
[00:24] <godber> I thought the exercise would be worth it ... at least up until a point
[00:24] <godber> then I accidentally spent the last hour building the wrong arch :)
[00:24] <godber> I think its been at least ten years since I built a kernel, things have changed
[00:27] <achiang> godber: i don't think you need to run updateconfigs
[00:27] <achiang> or even kernelconfig, really
[00:28] <godber> hmm, I am trying to get as close to the Ubuntu way as I can
[00:28] <achiang> godber: right, but you really only need to run that script if you've updated the Kconfig, which it doesn't sound like you're trying to do
[00:29] <godber> true, though ...
[00:29]  * achiang is grabbing the lucid tree to poke around a bit
[00:30] <godber> oh, you don't have to bother, I am gonna have to split soon
[00:30] <godber> I appreciate your help though
[00:30] <godber> I am gonna have to pickt this pack up in the morning
[00:31] <achiang> do you know the kernel revisions between .32-24-generic and .32-25-generic?
[00:31] <achiang> well, that's easy enough to find, actually
[00:31] <godber> no, I thought I could use the git tags
[00:31] <achiang> right, you can
[00:31] <achiang> i found them
[00:31] <godber> and the bisect good/bad stuff
[00:32] <godber> really, I am on step one ... which is "Create an identical kernel to the one that fails"
[00:33] <godber> at least I am building on an 8core ec2 instance now, instead of my laptop
[00:40] <godber> it really seems to me that the arch should be an argument here
[00:40] <godber> DEB_BUILD_OPTIONS=parallel=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic
[00:41] <jj-afk> godber: you have picked a bad day, most of us are away, /me included :)
[00:41] <jj-afk> https://wiki.ubuntu.com/Kernel/Dev
[00:41] <jj-afk> contains all the docs on how we build kernels etc
[00:41] <godber> yeah, I have been digging around in some of those
[00:42] <jj-afk> generally, you can just git bisect, and remove debian/stamps-build*
[00:43] <jj-afk> and then build using fakeroot debian/rules binary-generic
[00:43] <achiang> jj-afk: the challenge is building i386 on an x86_64 host
[00:44] <jj-afk> you just need to setup up and i386 chroot and use schroot
[00:44] <achiang> ew, there's no way to use linux32 somehow?
[00:44] <rlpb> any ideas about getting a crash dump when I can't get the kernel to reboot after panic (if that's the cause)?
[00:44] <jj-afk> achiang: you can but the packaging depends on other bits, so it gets messy fast
[00:44] <godber> achiang, its building a whole deb package, so the chroot needs to match the arch
[00:45] <godber> I see
[00:45] <jj-afk> if I am just building kernels I can do it, but packaging up a deb, I just use the chroot
[00:45] <jj-afk> there is a script to set them up for you its pretty painless
[00:45] <achiang> jj-afk: got it.
[00:45] <godber> https://wiki.ubuntu.com/KernelTeam/BuildKernelWithChroot
[00:46] <achiang> godber: ok, sounds like you know the steps then, good luck. :)
[00:46] <godber> ok ... yeah, brilliant
[00:46] <godber> now I know where to start tomorrow
[00:46] <godber> thanks guys
[00:46] <achiang> godber: http://pastebin.ubuntu.com/530367/
[00:46] <achiang> fortunately, you probably don't have to iterate very many times, since you've isolated your issue to -24 and -25
[00:47] <godber> oh, yeah, good, thanks
[00:55] <godber> thanks again guys, bywe
[04:17] <Maahes> I could use some advice, my touchpad won't come back after suspend. I've tried reloading psmouse (the only module I've found running prior), I've tried loading synaptics(_i2c) but it says the modules don't exit (but zsh autocompletes them for me) the touchpad is no longer in /proc/bus/input/devices but tpconfig sees that's there, but cannot get information from it.
[05:02] <Maahes> Additionally, I tried binding XF86TouchpadToggle to Ctrl+shift+t, but it says there's an error, no output to any error log though, additionally manually clicking and unclicking the gconf setting for touchpad_enabled does nothing as well
[08:20] <TeTeT> What are the plans for the .26 kernel in lucid-proposed? When will it be moved to lucid-updates?
[08:23] <smb> TeTeT, I believe that one too will be subject to exercise the new revert patches if not tested process, which Steve wants to have a go on Monday. From then on it depends a bit on the decision of waiting for regression testing or not. I would ask him on Monday
[08:24] <TeTeT> smb: so the screen resolution on Esprimo E patch would be safe as I've spent quite some time testing it?
[08:24] <smb> If you mention/report this in the bug report, yes. That should be ok
[08:29] <TeTeT> smb: was done, the tag verification_done was added too
[08:30] <smb> TeTeT, Then I would say you are good/safe
[08:30] <smb> (As long as the scripting goes right of course, but I am pretty sure they double/triple check on that :))
[08:33] <TeTeT> smb: does this mean after removing the untested patches, the kernel will be published in -updates right away, or does it stay in proposed for another week?
[08:35] <smb> TeTeT, The target for the future will be a re-upload with untested things reverted. Then another week for qa regression testing. I don't think we are quite there, but I would think that this at least will be kept for another week in proposed to have some baking time.
[08:38] <TeTeT> smb: sounds reasonable
[08:41] <smb> TeTeT, Mind that I am not authoritative there anymore. Last words would be Steve (or Martin). Just most of the US might be on swap days after the holiday yesterday.
[08:41] <smb> (Martin not being affected there, of course)
[08:44]  * smb waves to cking 
[08:46]  * cking waves back
[08:46] <smb> cking, cannot hear
[09:03]  * smb got a feeling there is an apw hiding somewhere
[09:04] <apw> smb, now what makes you think that
[09:04] <smb> apw, Some Andy sends out mail. :)
[09:04] <apw> damn i should have thought of that 
[09:04] <smb> :) morning anyway
[09:05] <apw> morning
[12:57] <diwic> bug #640254
[12:57] <ubot2> Launchpad bug 640254 in linux (Ubuntu Maverick) (and 1 other project) "[Dell Inspiron M101z] Internal speakers does not function in Ubuntu after booting into Win7 once (affects: 1) (heat: 64)" [Undecided,Fix committed] https://launchpad.net/bugs/640254
[12:58] <diwic> Can somebody tell me how this stuff is supposed to work with the new throw-your-patches-out policy?
[12:58] <diwic> First it was accepted to pre-stable
[12:58] <diwic> Then it came from upstream
[12:59] <diwic> neither seems to be enough to avoid the throw-patches-out 
[13:00] <diwic> I thought we would keep whatever came from upstream.
[13:00] <diwic> upstream stable, that is.
[13:00] <smb> diwic, I would hope that upstream stable takes precedence
[13:00] <smb> but that might be a special case the scripts to come need to handle
[13:01] <smb> You may want to talk to Brad and/or Steve on Monday about that
[13:02]  * diwic does NOT like the new policy.
[13:03]  * smb is not the one to complain about it ;-P
[13:09] <diwic> smb, assuming people do what they should and send things to upstream stable, that is the common case rather than a special case
[13:14] <smb> right, and I think that you would get the benefit of not getting reverted in that case
[13:14] <smb> Though it does not really matter what I think
[13:14] <apw> diwic, things coming down from upstream stable are meant to be immune to the validation failure mode
[13:14] <apw> so if its being thrown out coming down from there there is something wrong
[13:15] <smb> Just make sure that people writing scripts are aware, too
[13:16] <diwic> apw, so if you look at the bug you would agree with me that the threat comment by sconklin (or his bot) is wrong in this case?
[13:17] <apw> diwic, if it came from stable it is a bug yes.  he is probabally assuming all patches with BugLink are not from stable
[13:20] <smb> It could just be a matter of updating the bot not to send a threat when there is a buglink to a stable tracking bug in the same patch as well as being the only one
[13:20] <smb> There is this thing about programs written by humans not always being bulletproof
[13:22] <diwic> yeah.
[13:57] <apw> yeah.  diwic just make sure you bitch at them in email to say you don't think this bug is one that should be on the drop list
[13:57]  * apw notes we are down to just two now
[13:59] <diwic> apw, just two what?
[14:03] <apw> oh ... heh ... /me notes we are down to just two patches dropped from Maverick to Natty which I do not either know should be dropped or have replacements for
[14:37] <diwic> apw, so, now I have bitched.
[14:38] <apw> diwic, hehe good man
[14:39] <diwic> apw, now that I got your attention, how do I review my personal patches for upstreaming and update?
[14:40] <apw> that work item is about looking at the ones we are carrying in your name and deciding whether they should be upstream
[14:40] <apw> if they should not then let me know and i will mark them so that i don't ask you again
[14:40] <apw> if they should be, its a reminder to push them along up there
[14:40] <diwic> apw, and how do I know which ones we are carrying in my name?
[14:41] <apw> ahh they are listed on https://wiki.ubuntu.com/KernelTeam/Specs/KernelNattyUbuntuDeltaReview search for your name
[14:43] <diwic> apw, ok, only one and that one should be dropped. Someone else tried to upstream it, I think it got rejected.
[14:44] <apw> ok if you edit the Spec there and add a * this should be dropped (diwic) under them, then i'll drop them as i go
[14:44] <apw> then you can close your work-item :)
[14:47] <diwic> apw, thanks
[16:51] <lag> apw, smb: https://patchwork.kernel.org/patch/249861/
[19:46] <kraut> howdy, anyone an idea what's going wrong here? http://pastebin.com/sBp8d3ag
[19:46] <kraut> the problem happens on a via esther, is there any issue with the cpu scalling?
[19:46] <kraut> it's reproducable when heavy disk i/o happens