achiang | camden: i've never tried applying them myself, but my impression is that con develops against upstream linux, not the ubuntu tree | 00:03 |
---|---|---|
camden | this is my impression as well | 00:05 |
camden | I may have had some success | 00:06 |
camden | we will see when my compilation is done. | 00:06 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
=== kees___ is now known as kees | ||
godber | except of course oldconfig doesnt exist | 00:16 |
=== BenC__ is now known as BenC | ||
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:18 |
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:19 |
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:20 |
camden | alright, kernel done. wish me luck | 00:22 |
achiang | godber: yuck. | 00:23 |
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:24 |
achiang | godber: i don't think you need to run updateconfigs | 00:27 |
achiang | or even kernelconfig, really | 00:27 |
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:28 |
godber | true, though ... | 00:29 |
* achiang is grabbing the lucid tree to poke around a bit | 00:29 | |
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:30 |
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:31 |
godber | really, I am on step one ... which is "Create an identical kernel to the one that fails" | 00:32 |
godber | at least I am building on an 8core ec2 instance now, instead of my laptop | 00:33 |
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:40 |
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:41 |
jj-afk | generally, you can just git bisect, and remove debian/stamps-build* | 00:42 |
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:43 |
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:44 |
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:45 |
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:46 |
godber | oh, yeah, good, thanks | 00:47 |
godber | thanks again guys, bywe | 00:55 |
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. | 04:17 |
=== BenC__ is now known as BenC | ||
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 | 05:02 |
=== _LibertyZero is now known as LibertyZero_ | ||
=== amitk_ is now known as amitk-afk | ||
=== amitk-afk is now known as amitk | ||
TeTeT | What are the plans for the .26 kernel in lucid-proposed? When will it be moved to lucid-updates? | 08:20 |
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:23 |
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:24 |
TeTeT | smb: was done, the tag verification_done was added too | 08:29 |
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:30 |
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:33 |
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:35 |
TeTeT | smb: sounds reasonable | 08:38 |
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:41 |
* smb waves to cking | 08:44 | |
* cking waves back | 08:46 | |
smb | cking, cannot hear | 08:46 |
* smb got a feeling there is an apw hiding somewhere | 09:03 | |
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:04 |
apw | morning | 09:05 |
=== Nafallo_ is now known as Nafallo | ||
=== ivoks-afk is now known as ivoks | ||
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:57 |
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:58 |
diwic | neither seems to be enough to avoid the throw-patches-out | 12:59 |
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:00 |
smb | You may want to talk to Brad and/or Steve on Monday about that | 13:01 |
* diwic does NOT like the new policy. | 13:02 | |
* smb is not the one to complain about it ;-P | 13:03 | |
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:09 |
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:14 |
smb | Just make sure that people writing scripts are aware, too | 13:15 |
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:16 |
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:17 |
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:20 |
diwic | yeah. | 13:22 |
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:57 | |
diwic | apw, just two what? | 13:59 |
=== jdstrand_ is now known as jdstrand | ||
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:03 |
diwic | apw, so, now I have bitched. | 14:37 |
apw | diwic, hehe good man | 14:38 |
diwic | apw, now that I got your attention, how do I review my personal patches for upstreaming and update? | 14:39 |
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:40 |
apw | ahh they are listed on https://wiki.ubuntu.com/KernelTeam/Specs/KernelNattyUbuntuDeltaReview search for your name | 14:41 |
diwic | apw, ok, only one and that one should be dropped. Someone else tried to upstream it, I think it got rejected. | 14:43 |
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:44 |
diwic | apw, thanks | 14:47 |
=== yofel_ is now known as yofel | ||
=== jjohansen is now known as jj-afk | ||
lag | apw, smb: https://patchwork.kernel.org/patch/249861/ | 16:51 |
=== Ian__ is now known as Ian_Corne | ||
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 | 19:46 |
=== 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 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!