[00:03] camden: i've never tried applying them myself, but my impression is that con develops against upstream linux, not the ubuntu tree [00:05] this is my impression as well [00:06] I may have had some success [00:06] we will see when my compilation is done. [00:11] Anyone have time for, what I hope is, a quick newbie question? [00:11] godber: just ask. someone may see the question later and have a response [00:11] just want to know how to build for x86 when on amd64 [00:12] https://help.ubuntu.com/community/Kernel/Compile [00:12] according to those instructions ^^ [00:12] does running [00:12] debian/scripts/misc/oldconfig ARCH [00:12] somehow make the build be for that architecture? [00:13] 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] yes, 64bit host [00:14] want a 32bit kernel [00:14] godber: i'm not familiar with the Ubuntu way. but the upstream way is to say: linux32 make [00:14] ok [00:15] godber: so, you might want to experiment with: linux32 debian/scripts/misc/oldconfig x86 [00:15] yeah, I am trying that right now ... will let you know, thanks === kees___ is now known as kees [00:16] except of course oldconfig doesnt exist === BenC__ is now known as BenC [00:18] theres kernelconfig [00:18] godber: did you run debian/rules updateconfigs ? [00:18] oh, I thought those were alternatives [00:18] will try [00:18] godber: and probably, what you want would be: linux32 debian/rules updateconfigs [00:18] godber: but i'm just guessing. [00:19] k [00:19] actually looking at the kernelconfig script, it looks like it might do the same thing [00:19] godber: should i ask why you think you want to do this? or should i be afraid? :) [00:20] well, I have been questioning the wisdom of my actions all day [00:20] since I put the odds of success low [00:20] but I was going to try and identify which patch causes [00:20] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/659422 [00:20] 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] alright, kernel done. wish me luck [00:23] godber: yuck. [00:24] godber: i assume you're doing a git bisection run, and not a manual one? [00:24] agreed, but until I can convince someone to care, I am out of luck [00:24] that was the plan [00:24] I thought the exercise would be worth it ... at least up until a point [00:24] then I accidentally spent the last hour building the wrong arch :) [00:24] I think its been at least ten years since I built a kernel, things have changed [00:27] godber: i don't think you need to run updateconfigs [00:27] or even kernelconfig, really [00:28] hmm, I am trying to get as close to the Ubuntu way as I can [00:28] 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] true, though ... [00:29] * achiang is grabbing the lucid tree to poke around a bit [00:30] oh, you don't have to bother, I am gonna have to split soon [00:30] I appreciate your help though [00:30] I am gonna have to pickt this pack up in the morning [00:31] do you know the kernel revisions between .32-24-generic and .32-25-generic? [00:31] well, that's easy enough to find, actually [00:31] no, I thought I could use the git tags [00:31] right, you can [00:31] i found them [00:31] and the bisect good/bad stuff [00:32] really, I am on step one ... which is "Create an identical kernel to the one that fails" [00:33] at least I am building on an 8core ec2 instance now, instead of my laptop [00:40] it really seems to me that the arch should be an argument here [00:40] DEB_BUILD_OPTIONS=parallel=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-generic [00:41] godber: you have picked a bad day, most of us are away, /me included :) [00:41] https://wiki.ubuntu.com/Kernel/Dev [00:41] contains all the docs on how we build kernels etc [00:41] yeah, I have been digging around in some of those [00:42] generally, you can just git bisect, and remove debian/stamps-build* [00:43] and then build using fakeroot debian/rules binary-generic [00:43] jj-afk: the challenge is building i386 on an x86_64 host [00:44] you just need to setup up and i386 chroot and use schroot [00:44] ew, there's no way to use linux32 somehow? [00:44] 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] achiang: you can but the packaging depends on other bits, so it gets messy fast [00:44] achiang, its building a whole deb package, so the chroot needs to match the arch [00:45] I see [00:45] if I am just building kernels I can do it, but packaging up a deb, I just use the chroot [00:45] there is a script to set them up for you its pretty painless [00:45] jj-afk: got it. [00:45] https://wiki.ubuntu.com/KernelTeam/BuildKernelWithChroot [00:46] godber: ok, sounds like you know the steps then, good luck. :) [00:46] ok ... yeah, brilliant [00:46] now I know where to start tomorrow [00:46] thanks guys [00:46] godber: http://pastebin.ubuntu.com/530367/ [00:46] fortunately, you probably don't have to iterate very many times, since you've isolated your issue to -24 and -25 [00:47] oh, yeah, good, thanks [00:55] thanks again guys, bywe [04:17] 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. === BenC__ is now known as BenC [05:02] 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 === _LibertyZero is now known as LibertyZero_ === amitk_ is now known as amitk-afk === amitk-afk is now known as amitk [08:20] What are the plans for the .26 kernel in lucid-proposed? When will it be moved to lucid-updates? [08:23] 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] smb: so the screen resolution on Esprimo E patch would be safe as I've spent quite some time testing it? [08:24] If you mention/report this in the bug report, yes. That should be ok [08:29] smb: was done, the tag verification_done was added too [08:30] TeTeT, Then I would say you are good/safe [08:30] (As long as the scripting goes right of course, but I am pretty sure they double/triple check on that :)) [08:33] 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] 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] smb: sounds reasonable [08:41] 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] (Martin not being affected there, of course) [08:44] * smb waves to cking [08:46] * cking waves back [08:46] cking, cannot hear [09:03] * smb got a feeling there is an apw hiding somewhere [09:04] smb, now what makes you think that [09:04] apw, Some Andy sends out mail. :) [09:04] damn i should have thought of that [09:04] :) morning anyway [09:05] morning === Nafallo_ is now known as Nafallo === ivoks-afk is now known as ivoks [12:57] bug #640254 [12:57] 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] Can somebody tell me how this stuff is supposed to work with the new throw-your-patches-out policy? [12:58] First it was accepted to pre-stable [12:58] Then it came from upstream [12:59] neither seems to be enough to avoid the throw-patches-out [13:00] I thought we would keep whatever came from upstream. [13:00] upstream stable, that is. [13:00] diwic, I would hope that upstream stable takes precedence [13:00] but that might be a special case the scripts to come need to handle [13:01] 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] 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] right, and I think that you would get the benefit of not getting reverted in that case [13:14] Though it does not really matter what I think [13:14] diwic, things coming down from upstream stable are meant to be immune to the validation failure mode [13:14] so if its being thrown out coming down from there there is something wrong [13:15] Just make sure that people writing scripts are aware, too [13:16] 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] 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] 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] There is this thing about programs written by humans not always being bulletproof [13:22] yeah. [13:57] 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] apw, just two what? === jdstrand_ is now known as jdstrand [14:03] 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] apw, so, now I have bitched. [14:38] diwic, hehe good man [14:39] apw, now that I got your attention, how do I review my personal patches for upstreaming and update? [14:40] that work item is about looking at the ones we are carrying in your name and deciding whether they should be upstream [14:40] if they should not then let me know and i will mark them so that i don't ask you again [14:40] if they should be, its a reminder to push them along up there [14:40] apw, and how do I know which ones we are carrying in my name? [14:41] ahh they are listed on https://wiki.ubuntu.com/KernelTeam/Specs/KernelNattyUbuntuDeltaReview search for your name [14:43] apw, ok, only one and that one should be dropped. Someone else tried to upstream it, I think it got rejected. [14:44] 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] then you can close your work-item :) [14:47] apw, thanks === yofel_ is now known as yofel === jjohansen is now known as jj-afk [16:51] apw, smb: https://patchwork.kernel.org/patch/249861/ === Ian__ is now known as Ian_Corne [19:46] howdy, anyone an idea what's going wrong here? http://pastebin.com/sBp8d3ag [19:46] the problem happens on a via esther, is there any issue with the cpu scalling? [19:46] it's reproducable when heavy disk i/o happens === zul_ is now known as zul === dannf is now known as bisdannf === ivoks is now known as ivoks-afk === bisdannf is now known as dannf