[00:03] chadhogg: I wish I could tell you, usually if there is a known good point in the past and the problem is due to a single commit [00:04] bisecting will find it [00:04] there are of course build failures that can mess you up, and disheartening [00:05] chadhogg: did you find any kernel to work for you on your bisect? [00:07] there was only one that I was able to successfully build, and it exhibited my bug [00:08] chadhogg: okay, what range did you do the bisect on? [00:09] I couldn't figure out how to translate my working release into a tag, so I did the oldest commit in the log to the head [00:10] chadhogg: you don't need to use a tag for git bisect [00:10] the midpoint of those lacked a debian/rules file, so I marked it as "good", figuring I could come back and figure out the old build process if I found that my bug went back that far, but that this would be unlikely [00:10] you can just give it the hash [00:10] rephrase: I didn't know how to translate my working release into a hash [00:12] chadhogg: so 2.6.35 succeeds and 2.6.36 fails [00:12] yes [00:12] wait, no [00:12] err, yes [00:12] and I mean it this time :) [00:12] but the natty source tree has nothing tagged as being part of 2.6.35 [00:13] right [00:13] bisecting our kernels can be a bit of a pain when it comes to crossing releases [00:14] you see we rebase to upstream, and start fresh for each new release [00:15] chadhogg: what is the hash of the last build failure you have [00:15] 974ead458b4832b34ecd8fc71c28e25783683fbd [00:16] specifically, due to a function signature mismatch on line 350 of security/yama/yama_lsm.c [00:17] I should mention that I made the default selection for all configuration options [00:17] right [00:24] chadhogg: ugh, you didn't even get into the kernel proper [00:25] what does that mean? [00:26] chadhogg: hrmm, I would recommend you stop atm, I am about to duck out for abit but when I get back I'll set up a bisect, and build you a kernel to try [00:27] thanks; I'll continue idling in here, though the easiest way to communicate might be through my launchpad bug [00:27] chadhogg: I mean that you where really just in ubuntu patches that are on top of upstream kernel [00:27] chadhogg: sure, when I get a kernel built I will drop a link for you to test in there [00:27] well, my (perhaps unfounded) suspicion is that that is where the problem lies [00:32] chadhogg: I highly doubt it but we will find out whether that is the case rather quickly === fairuz_ is now known as fairuz [08:24] * smb mornings [08:59] * smb needs more coffee [08:59] * ikepanhc needs some food [13:58] gah, where did my night go? [13:59] k [13:59] Down the drains it seems [13:59] smoser, you erm stayed up through it as normal ? [13:59] jjohansen, ^^ even [14:01] apw: sadly yes, but /me hasn't even gotten through even half of what was planned for a few hours :/ [14:06] jjohansen, that always happens, nothing is ever as simple as it seems [14:06] "lets just change the version number from 2.6.39 to 3.0, should be simple" [14:07] apw: hehe, yeah [14:07] Well, changing it _was_ simple. Handle the fallout not so much [14:16] ogasawara, i am assuming that revert worked ok for you ? [14:17] ogasawara, though i think i have the right fix now === cking_ is now known as cking [14:17] apw: it did, feel free to drop it and push the proper fix over it [14:17] apw: as I've pushed it to master-next [14:18] ogasawara, so you have, good stuff [14:18] apw, stupid question time: are kernel .ddebs automatically built, and if so, where can I get them? [14:18] cking, yes and from ddebs.ubuntu.com [14:18] thanks [14:19] apw: once you push, I'll do a quick test and then plan to upload [14:20] apw: I'm also away tomorrow and friday, can you handle the release meeting friday? otherwise I'll send skaet our part to paste in [14:21] ogasawara, ok pushed try that [14:37] apw: seems to be working, my kernel is still building at least [14:38] ogasawara, good stuff ... i've pushed it to linus as well [14:38] nie [14:38] nice even [14:39] * ogasawara replaces her dev box which magically died overnight [14:40] ogasawara, ouch [14:41] hi. anyone seen major memory issues with current kernel ? [14:41] http://paste.ubuntu.com/627335/ [14:41] smoser, what in there tells you you have memory issues ? [14:41] i was mostly idle, basically desktop and firefox running, and using all 4G + 4G swap, nothing appeared to me to be using excessive memory [14:42] smoser, yet nothing is dieing with OOM ? [14:42] apw, i was using 100% swap, and iotop showed kswapd running full bore, system was unusable. [14:42] i'm not sure whether or not i had rebooted since yesterday, when the oom *did* kill some processes. [14:42] the system was too unusable to get a dmesg even. [14:43] smoser, no not seen anything like that on the two machines i am regularly using it [14:43] i literally could not log in with ssh or use one of the gnome terminals that was open. [14:43] so... if I had not rebooted since yesterday, what I did yesterday that *did* cause massive issues was trying to do an install in kvm. [14:44] smoser, i guess we need /proc/slabinfo as its not in kernel processes [14:44] s/kernel/user [14:44] i'll try the kvm install from yesterday and see if I go out to lunch again [14:44] /dev/sda6 partition 7823616 977416 -1 [14:45] swap stats on a machine up 7 days with that kernel [14:46] shoot. i realized that pastebin didn't have one line of free -m [14:46] should have also had: [14:46] Swap: 4000 4000 0 [14:46] (4000 available, 4000 used) [14:47] but /proc/meminfo had that . so anyway, i'll see if i can't reproduce. [14:50] why is the ubuntu kernel gitweb so sloooooow? [14:50] cking: in the afternoon is always slow [14:50] cking: in the morning i find it snappier [14:51] the server is being hammered at the moment :-( [14:51] cking, the machine isn\t the biggest [14:51] it's a 386? [14:52] its a 2 cpuu amd64 i think [14:52] looks memory+CPU+I/O bound to me [14:53] cking, its a tiny machine [14:53] well, we've not up-scaled it compared to how much more we use it nowadays [14:54] yep [14:55] poor thing [14:56] right now, there seem to be a lot of git pack-objects going on... [15:01] well, so far just running kvm the same way I did yesterday hasn't triggered anything bad. [15:01] smoser, hrm, not good [15:14] * ogasawara back in 20 [16:06] * jjohansen steps away for a bit === jjohansen is now known as jj-afk === stdin is now known as Guest80131 === Guest80131 is now known as ts2 [16:43] apw, ogasawara FYI: Being bored (or weird or both) I had been running the qa-regression-test suite on 3.0.0-1 and got one failure. Not sure this is moot but the test runs "getpcaps 1" and expects ": =ep cap_setpcap-e" but only gets ": =ep". Same test works on Natty. [17:00] smb: thanks, I'll try running it here to re-create and investigate [17:04] ogasawara, OK, cool. Let me know if it does not or whatever comes out of it. [17:08] apw: you uploaded kexec-tools to the kernel ppa today? [17:21] bjf, yeah i wanted to get a powerpc build for it, feel free to just delete it finished or not [17:21] bjf, i've now uploaded it to the archive and said balls to it [17:22] apw, that's a pretty od version string and it's busted my scripts (made me sad) [17:22] heh :) [17:22] apw, bjf: can we as a policy only use that PPA for stable team builds please? [17:22] sconklin, arn't you mean with your pretty toys [17:23] not nice of you to say that after having smashed those toys ;) [17:23] admittedly, they are somewhat fragile toys [17:24] apw, is a ':' legal? [17:24] just delete the package [17:24] 8: at the front, yes, its an epoch, and optional [17:24] apw, thanks [17:27] much thanks for linux-lts-backport-natty. I just deployed some new lucid machines today that needed it === jj-afk is now known as jjohansen [18:13] sforshee: do you have a machine affected by this bug? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/424142 [18:13] Ubuntu bug 424142 in linux "Address Collision" [Medium,Fix committed] [19:10] sconklin, I don't, BenC was working with some machines that were affected and verified the fix in the test build [19:11] sforshee: ok, I spammed the bug again, maybe we'll get a response. Thanks [19:17] BenC, you probably want to verify the fix for bug #424142 in proposed or else sconklin is going to revert the patch [19:17] Launchpad bug 424142 in linux "Address Collision" [Medium,Fix committed] https://launchpad.net/bugs/424142 [19:18] sconklin cracks his knuckles and fetches the repo . . . [19:19] seriously, we have a couple of days. [19:19] sconklin, fyi that patch is queued for .32-longterm as well [19:20] normally that would make me want to take it, but I'm still sore from the last round of longterm updates [19:20] that's understandable === yofel_ is now known as yofel [21:05] * jjohansen -> lunch [21:23] * vanhoof reads a novel from jjohansen [21:23] vanhoof: haha sorry about that [21:23] * jjohansen is trying to spread the pain around :) [21:24] jjohansen: lol [21:24] jjohansen: did you sleep last night? :) [21:26] no === ogasawara changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Natty Kernel Version: 2.6.38 || Ubuntu Kernel Team Meeting - June-21 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! [23:27] sconklin: I have a bug where the fix has made it in to the stable tree, so it will be coming in through stable updates. Do you want bug report tasks for this type of bug [23:34] jjohansen: if it matters to you then you better open a bug. I think we may declare a moratorium on taking upstream stable patches unless it's within 90 days of a release or SRUd. It needs discussion but opening a bug is the best way to make sure it gets included [23:35] sconklin: okay thanks