[07:17]  * abogani waves all
[07:19]  * apw yawns
[07:19] <RAOF> Time for the bees!
[07:20]  * apw giggle insanly
[07:20] <smb> apw, Has there been back in 20mins mentioned?
[07:21] <apw> sadly not
[07:22]  * smb wonders what made apw loose control. :)
[07:22] <apw> its just going to me one of those days
[07:23] <abogani> ogasawara: ping
[07:23] <RAOF> Bah.  Bluetooth, why do you suck so?
[07:25] <ppisati> CFLAGS+=-DENABLE_GPIO_RADIO_CTL
[07:26] <ppisati> ops
[07:26] <ppisati> http://pastebin.ubuntu.com/642447/
[07:45] <apw> ppisati, ok seems i've pushed an update to lucid master-next which should sort you out
[07:45] <apw> no idea why i didn't think it applied to lucid
[09:10] <ppisati> apw: cool, btw disabling that driver fixed the compilation
[09:16] <ppisati> apw: when available, can you open CVE-2010-4805? thanks
[09:16] <ubot2> ppisati: The socket implementation in net/core/sock.c in the Linux kernel before 2.6.35 does not properly manage a backlog of received packets, which allows remote attackers to cause a denial of service by sending a large amount of network traffic, related to the sk_add_backlog function and the sk_rmem_alloc socket field.  NOTE: this vulnerability exists because of an incomplete fix for CVE-2010-4251. (http://cve.mitre.org/cgi-bin/cvename.c
[10:52]  * ppisati -> out for food
[12:30]  * apw lunche
[12:49] <herton> smb: natty is failing on QA for -virtual flavour, because CONFIG_DEBUG_RODATA is disabled for it (bug 802464)
[12:49] <ubot2> Launchpad bug 802464 in linux "linux: 2.6.38-10.46 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/802464
[12:50] <herton> smb: we don't remember now if it was you which was going submit a patch for it, as it was reported before, but I can do it in any case
[12:50] <smb> herton, wtf. Thanks, though I would have thought that Natty should not be able to get built without...
[12:51] <smb> The last one it was not would have been hardy
[12:51] <herton> ah... ok, natty seems to require the same fix then
[12:51] <smb> I thought we had that in the big mean config checker, but I need to have a look at that
[12:52] <tgardner> smb, its in the enforcer, but looks like virtual is excluded
[12:53]  * smb wonders whether there was a case where that broke ec2
[12:53] <tgardner> herton, why is that failing now ?
[12:53] <smb> tgardner, Guess because now we are really really testing
[12:53]  * smb will have a look and see whether it can be turned on and still boots on ec2
[12:54] <herton> it seems we got this reported in June, but was forgotten (https://lists.ubuntu.com/archives/ubuntu-kernel-sru/2011-June/000158.html)
[12:54] <tgardner> smb, in the meantime I suggest we get an exception so it doesn't hold up everything else. its not like its a regression.
[12:55] <tgardner> herton, ^^
[12:55] <smb> +1
[12:55] <herton> tgardner: yep, I agree
[13:01] <smb> herton, tgardner I think the problem should now be fixed through stable but we deliberately have been disabling that for i386 (see 0b111980fe515c5ab24bf21aca5aebd24c70f605)
[13:02] <smb> But I'll better get it tested to be sure
[13:03] <tgardner> smb, herton: so an exception should be acceptable since we made the change with malice aforethought.
[13:03] <apw> ppisati: did someone do this for you: CVE-2010-4805
[13:03] <ubot2> apw: The socket implementation in net/core/sock.c in the Linux kernel before 2.6.35 does not properly manage a backlog of received packets, which allows remote attackers to cause a denial of service by sending a large amount of network traffic, related to the sk_add_backlog function and the sk_rmem_alloc socket field.  NOTE: this vulnerability exists because of an incomplete fix for CVE-2010-4251. (http://cve.mitre.org/cgi-bin/cvename.cgi?n
[13:04]  * smb has not
[13:04] <herton> yes, +1 on that, it isn't a regression from the released natty kernel
[13:04]  * ogasawara drowns in email
[13:05] <tgardner> ogasawara should never take vacation again
[13:05] <ogasawara> I miss anything exciting?
[13:05]  * apw votes for ogasawara to not have any too
[13:05] <smb> ...ctrl-a del
[13:06] <apw> ogasawara: na things went ok for the milestone
[13:08] <ogasawara> apw: I thought you'd pushed over the top of linux-meta to drop versatile?
[13:09] <apw> ogasawara: i did i thought  /me checks
[13:09]  * tgardner defers UDS registration until August in case the dates change again.
[13:09] <apw> ogasawara: i think its on master-next
[13:10] <apw> i think we need to shift that back
[13:11] <apw> ogasawara: let me look maybe i've bust it
[13:12] <tgardner> apw, you should drop an example of MSS clamping in that IPv6 wiki page.
[13:12] <apw> tgardner: will do ...
[13:13] <ogasawara> apw: yep, looks like it's on master-next.  I'll get master updated.
[13:13] <apw> ogasawara: yeah i think its time to lose master-next
[13:13] <apw> (from meta)
[13:14] <ogasawara> apw: yah, I'll drop that branch too
[13:16] <ogasawara> apw: I assume you have the commit for 3.0.0-5.6 for linux-meta in your tree then?  care to just push that to master?
[13:17] <apw> ppisati: https://bugs.launchpad.net/bugs/809318
[13:17] <ubot2> Ubuntu bug 809318 in linux-ti-omap4 "CVE-2010-4805" [Undecided,New]
[13:17] <ogasawara> apw: nm, looks like it's tgardner who's got it
[13:17] <apw> ogasawara: ok ... get him to shove
[13:18] <tgardner> ogasawara, what am I shoving? apw did the last meta upload.
[13:19] <ogasawara> tgardner: am trying to find the commit which closed out linux-meta for 3.0.0-5.6
[13:20] <ppisati> apw: 10x
[13:20] <tgardner> ogasawara, well, I don't think anyone has done it yet. 5.6 isn't finished building.
[13:20] <apw> ppisati: i am going to assume thats positive
[13:22] <ogasawara> tgardner: ack, you're right
[13:22] <tgardner> ogasawara, I just got it uploaded about 10P your time.
[13:23] <ogasawara> I'll keep an eye on the builds and then get linux-meta uploaded/updated 
[13:24] <tgardner> ogasawara, I've nothing unpushed in my natty-meta repo, so feel free to hack and slash
[14:26] <tgardner> bjf, given that you are the resident python expert, how about reviewing sforshee's patch lest he become discouraged? https://lists.ubuntu.com/archives/kernel-team/2011-July/016142.html
[14:27] <bjf> tgardner, roger, roger
[14:27] <sforshee> tgardner, bjf: at this point it doesn't seem to matter much since we've switched back to 3 numbers in the version
[14:30] <apw> i recon we should fix them anyhow
[14:31] <sforshee> it would be simpler if we could assume a '-' between the upstream version and the ABI, but right now it looks for '.' or '-'. I assume that's for legacy reasons?
[14:32] <apw> sforshee, per
[14:32] <abogani> ogasawara: ping
[14:32] <apw> sforshee, perhaps for meta as well
[14:32] <apw> which uses the . . . . form
[14:32] <sforshee> I see
[14:32] <ogasawara> ogasawara: pong
[14:32] <ogasawara> heh
[14:32] <ogasawara> abogani: pong
[14:32]  * apw giggles at ogasawara
[14:33] <smb> one of those days...
[14:33] <abogani> ogasawara: Could you renew me in bugcontrol, please?
[14:33] <ogasawara> abogani: sure, just a sec
[14:34] <abogani> ogasawara: Thank you 
[14:34] <ogasawara> abogani: done, renewed for another year
[14:35] <abogani> ogasawara: Thanks again 
[14:44] <bjf> sforshee, yes the '.' is to support meta
[14:45] <bjf> ##
[14:45] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[14:45] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[14:45] <bjf> ##
[14:45] <apw> bjf, again, so soon ?
[14:46] <bjf> apw, we could go to once a month, no-one would notice
[14:51] <apw> :)
[15:03] <ogasawara> apw: aside from the 3.0.0-5.6 upload, anything else happen I should mention in the meeting?
[15:04] <apw> ogasawara, no i don't think so, we were all quiet.  of course you should mention 3.0.0 change
[15:04] <ogasawara> apw: right, will add that
[15:10] <apw> sconklin, i see a lot of our master-nexts have not 
[15:10] <apw> been rebased, its making the pre-proposed kernels come out with funny old version numbers
[15:11] <tgardner> apw, we can fix that
[15:11] <tgardner> the rebase, I mean
[15:11] <apw> tgardner, i wanted to check he hasn't done them already
[15:12] <apw> tgardner, i guess as they are rebasable i can jstu do them and not care
[15:13] <apw> sconklin, scream now if you don't want them rebased
[15:13] <tgardner> apw, he could be screaming, but his pulse-audio has died.
[15:14]  * smb would sort of expect some "hold now" and "go" to know when one should be careful on touching -nexts
[15:14] <apw> smb, well you can tell if you push over someone so ... its entirly safe, just hard-ish to un-fook when you do overlap
[15:14] <smb> apw, Just don't like to find out by the time I would push, I guess
[15:18] <sconklin> apw: I have no issues with fixing up the -next branches, I just usually don't use a rebase to do it. 
[15:18] <sconklin> For reasons we discussed at the rally
[15:19] <smb> we did?
[15:19] <smb> Ah well
[15:19] <apw> sconklin, i am using the term rebase in its literal form, to move the base of the branch to the tip of master, not implying what you use to do it
[15:19] <smb> Its not really the rebase but the need to have a sensible (higher) version number
[15:19] <sconklin> There was a long discussion of why I prefer to cherry pick all the new commits from -next to the last tag, and force push that over master-next
[15:20] <sconklin> it amounts to the same thing.
[15:20]  * smb remembers now
[15:20] <apw> sconklin, right i don't care how one choses to do it, what i a complaining about is it not being dne
[15:20] <sconklin> Want me to do it, or does apw have it under control?
[15:20] <apw> sconklin, and if you haven't the time to do it i can do it, just say
[15:20] <sconklin> agreed. It's "yet another thing that doesn't have a checkbox that's enforced and gets forgotten"
[15:21] <apw> sconklin, i'll just go ahead and move them up then
[15:21] <sconklin> I can easily get it done today, probably in the next couple of hours including the meeting
[15:21] <sconklin> whatever
[15:21] <apw> sconklin, ok i'll let you
[15:21] <sconklin> ack
[15:22] <apw> (and i am complaining cause the pre-proposed kernels are getting dumb versions not cause i inherantly care)
[15:22] <sconklin> no, I understand
[15:23] <apw> sconklin, are we close to releasng any of these -proposed kernels?
[15:24] <sconklin> afaik, it's all in qa and cert now. So the answer is a provisional yes
[15:25] <sconklin> I'm compiling that information now for the meeting
[15:26] <apw> sconklin, cool, i am getting bored waiting for the lts-backport for natty to arrive 
[15:27] <sconklin> did you prep and build that? I'm not sure we did
[15:27] <sconklin> It ftbfs a while back and I don't think I got back to it
[15:27] <apw> i suspect i did originally
[15:28] <sconklin> I'll have a look
[15:28] <apw> it ftbs's on everything other than x86 and x86_64, but that is an archive error
[15:28] <apw> as we only target those two architectures, it is not even meant to start on the others
[15:28] <apw> i have been assured its not our fault
[15:28] <apw> that the control file is right and does not specify those other arches, but it goes there anyhow
[15:29] <sconklin> then it may just be sitting and waiting to be copied out of the ppa. I'll check
[15:30] <herton> yes, the script probably didn't get the build status as FULLY_BUILT because of the other arches which failed
[15:30] <herton> thus it didn't set the prepare-package to fix released for the lts-backport tracking bugs
[15:31] <herton> (script = shank bot)
[15:37]  * apw will once more try and get to the bottom of whether we can fix this
[15:40] <micahg> are you aware that the new 3.0.0-x kernel is showing up under the 3.0-x kernel in grub1?
[15:42] <apw> micahg, under? as in appearing 'lower' in version ?
[15:42] <micahg> apw: yes, options 3 and 4 :)
[15:42] <apw> micahg, why the heck is grub1 still on anything ?
[15:42] <micahg> I've been upgrading since hardy on that machine I think :)
[15:43] <micahg> I can file a bug, I just wanted to make you aware
[15:43] <apw> cjwatson, do we care a
[15:43] <tgardner> micahg, delete the 3.0-x kernel ?
[15:43] <apw> cjwatson, do we care any more about grub1 ?
[15:43] <micahg> tgardner: I can't be the only one with the issue ;)
[15:44] <tgardner> micahg, perhaps, but I'm not sure its something we'll fix 'cause 3.0-x was temporary
[15:44] <smb> apw, Just fwiw, you may encounter similar code in pv-grub on ec2
[15:44] <apw> ok confirmed that grub2 is at least ordering them right
[15:44] <apw> smb, nnng, well as we will release with a 3.0.0 i don't think we should hit it right ?
[15:45] <tgardner> apw, right. its a developer issue
[15:45] <smb> apw, no, you are right. 
[15:45] <micahg> it's ascii ordering instead of version ordering
[15:45] <apw> micahg, but do file a bug
[15:45] <micahg> k
[15:45] <apw> at least that way people will stumble on it, and we can document removing the old ones as a work-around
[15:50] <micahg> apw: bug 809401
[15:50] <ubot2> Launchpad bug 809401 in grub "grub is ascii ordering instead of version ordering kernels" [Undecided,New] https://launchpad.net/bugs/809401
[16:00] <bjf> ##
[16:00] <bjf> ## Kernel team meeting in one hour
[16:00] <bjf> ##
[16:04] <cjwatson> apw: we've never auto-upgraded people, so yes we do slightly care
[16:04] <cjwatson> also I thought the sorting in GRUB Legacy was the same as that in GRUB 2 ...
[16:06] <cjwatson> hm, perhaps not
[16:06] <cjwatson> anyway, it's my responsibility to fix, not yours
[16:06] <cjwatson> and it's not just ascii-ordering, it's more complicated than that
[16:07] <cjwatson> I'll have a look
[16:07] <tgardner> cjwatson, its really only a developer issue, i.e., only folks that had 3.0-x installed are affected. the normal upgrade from Natty to Oneiric should be fine.
[16:07] <cjwatson> tgardner: it's a bug, and should be fixed
[16:07] <cjwatson> sure, not very high priority :)
[16:16] <lamont> tgardner/herton: 3.0.0-4.5 seemed to fix that.  what are the chances of getting a r8169 driver backport to natty?
[16:17] <tgardner> lamont, hmm, I can check into it. perhaps an LBM backport ?
[16:18] <tgardner> on the other hand, the in-kernel driver is so broken that maybe I should just SRU a replacement
[16:19] <lamont> tgardner: I'd prefer to run "a natty kernel"  I have absolutely no care as to how we define that
[16:31] <tgardner> lamont, I've forgotten. Is there an existing bug no this r8169 issue?
[16:32] <lamont> 809000 is the best candidate
[16:32] <tgardner> lamont, ack
[16:33] <lamont> I haven't proven it - turns out that my spare network card has more pins on its edge connector than the mobo has pins in the slot
[16:33] <lamont> :(
[16:33] <lamont> the plan for today is to go drop $20 on a network card on my way ome
[16:33] <lamont> home. even
[16:34] <tgardner> ogasawara, given our policy of not modifying user space for backports, how do I note in the KernelOneiricUbuntuDeltaReview that we'll continue to carry a patch, likely in perpetuity ?
[16:34] <tgardner> in particular 'UBUNTU: Sony laptop: Some Sony Vaia laptops do not enable wwan power by default.'
[16:37] <ogasawara> tgardner: add a note to the wiki, and on the next rebase I can munge the commit message to note "SAUCE: (no-up)" so we know we'll carry it going forward
[16:38] <herton> lamont: hmm ok, would be good indeed to check with another network card still
[16:38] <tgardner> ogasawara, ack
[16:38] <sconklin> apw: The natty backports kernel needs to be respun, since we dropped some regressions out of Natty since it was made
[16:39] <apw> sconklin, excellent let me do it
[16:39] <apw> sconklin, as i think i have the fix for the erroring foun
[16:39] <sconklin> I suspect that the same is true of Maverick, checking
[16:39] <apw> foudn
[16:39] <apw> sconklin, i will do both if they need it ... let me know
[16:39] <herton> yes, maverick is the same
[16:40] <herton> we reverted two patches (1 failed verification, the other is the tlb regression)
[16:40] <sconklin> and - it's difficult to determine exactly what Natty the backports kernel is based on, because when we drop the patches and respin Natty and only change the upload number, that doesn't get propagated into the backports version or log that I can see
[16:40] <apw> sconklin, the version of the backports is identicle to the one is it based on
[16:41] <apw> sconklin, with ~lucid1 on the end
[16:42] <sconklin> oh, well then perhaps it does contain the reverts and is up to date
[16:42] <sconklin> one sec
[16:43] <sconklin> Yes, it appears that what's in the PPA for natty backports reflects the latest natty (.46), so it only needs copying to -proposed.
[16:44] <sconklin> apw: I get it now, thanks
[16:44] <apw> sconklin, ok and i think i have the erroring out crap sorted for next time, pushed to natty and maverick backports branches
[16:44] <sconklin> excellent
[16:52] <sconklin> apw, smb, tgardner: who is qualified to make a decision about whether it's OK to ship Natty with the CONFIG_DEBUG_RODATA issue? As it is it's stopped based on the QA testing failure, and we need to know whether to override that or respin (please be the former).
[16:52] <tgardner> sconklin, we talked about that earlier this morning. its not a regression so shouldn't hold up this release. smb is investigating....
[16:53] <smb> sconklin, We had been disabling that because of some i386 ec2 problem
[16:53] <tgardner> it _used_ to cause ec2 issues, but has perhaps been fixed in the interim
[16:53] <smb> sconklin, So its not a regression. But it seems based on my current test that it could get enabled again
[16:53] <smb> sconklin, Is there a bug open for it already?
[16:53] <sconklin> ok, I'm going to consider that two acks for releasing what we have
[16:54] <sconklin> smb: Not that I'm aware of. herton may know
[16:54] <herton> I think there is no bug open for that
[16:55] <smb> Ok, so I will open one for submitting the patch to enable it again when I am done with all the tests I wanted to do
[16:56] <bjf> sconklin, as stable mgr. i think it's your call
[16:56] <sconklin> bjf: Updating the bug now to ship it.
[16:56] <sconklin> I just wasn't clear on the technical implications.
[16:58] <sconklin> apw: when do the build run on the master-next branches?
[16:58] <sconklin> builds
[16:58] <bjf> sconklin, new tag: "let 'er buck"
[17:01] <sconklin> bjf: http://en.wikipedia.org/wiki/File:Slim-pickens_riding-the-bomb_enh-lores.jpg
[17:02] <ppisati> don't we have the meeting now?
[17:03] <bjf> ppetraki, was daydreaming
[17:20] <smb> bjf, nice the tags listing sort of is just the right start point to look for some of my tags of interest
[17:21] <bjf> smb, if there are other spins/mappings you'd like to see, let me know, i plan on adding more that I think are of value
[17:21] <apw> sconklin, as in when is pre-proposed uploaded?  09:00 UTC
[17:22] <tgardner> bjf, how about a graph showing the number of comments in a bug? or the number of subscribers, or the number of 'affects me', etc
[17:22] <apw> though i have been thinking it should be checked hourly and uploaded if its more than 24 hours since it last was uploaded and different
[17:24] <sconklin> ok, I am commencing fixup of the -next branches
[17:24] <bjf> tgardner, i'll put that on the list
[17:25] <tgardner> bjf, just thoughts on how to gauge what bugs are really pissing people off
[17:25] <apw> heat ?
[17:25] <bjf> tgardner, apw, "kernel gravity"
[17:26] <bjf> tgardner, apw, "bitch factor"
[17:26]  * smb thinks bugs against dapper, gutsy and feisty at least should be targets to kill...
[17:26] <apw> heh i meant there is already a heat
[17:26] <bjf> smb, yes, a script is on my list
[17:27] <bjf> smb, "won't fix" all unsupported series
[17:27] <smb> bjf, nice :)
[17:27] <apw> bjf, i may have the bones of that already, in the bugs/proc-cve-bugs
[17:27] <apw> which works out the same equasion, is this package supported on this release
[17:27] <smb> apw, There is definitely heat... oh you meant the bug heat :-P
[17:28] <sconklin> heat index is 105F here
[17:28] <apw> 18.9c here, which is nowhere near that, less than 70f
[17:29] <smb> 28°C -> 82°F in my room...
[17:29] <apw> smb, man you need to smash some windows
[17:30] <mjg59> apw: That'll just let the heat in
[17:30]  * smb hopes the distant grumble means coolness
[17:30] <apw> mjg59, without aircon, its almost cirtain that his machine heavy room is hotter than outside
[17:31] <smb> apw, Was suppusedly 30 outside
[17:31] <apw> smb, you need to move
[17:31] <apw> (slowly :)
[17:32] <smb> apw, Was about to say that moving makes me feel even warmer
[17:32] <smb> :)
[17:36] <bjf> smb, the high for the next 10 days is 26C, mostly 18 - 23
[17:37] <smb> bjf, I hope they are right
[17:43]  * tgardner reboots to test CVE-2010-4251
[17:43] <ubot2> tgardner: The socket implementation in net/core/sock.c in the Linux kernel before 2.6.34 does not properly manage a backlog of received packets, which allows remote attackers to cause a denial of service (memory consumption) by sending a large amount of network traffic, as demonstrated by netperf UDP tests. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4251)
[18:15] <tgardner> sconklin, when a Q/A test fails do they stop testing right away?
[18:16] <sconklin> tgardner: good question. I assumed not because the bug said something like "18 tests, 1 fail", but there may have been 30 tests total. I don't know.
[18:17] <tgardner> sconklin, likely worth following up on before setting a Q/A to released
[18:17] <tgardner> a Q/Q task*
[18:17] <tgardner> bah
[18:17] <sconklin> yeah, probably too late for this one, but good question. bjf, do you know? ^^
[18:17] <tgardner> sconklin, I know cert baila on the first failure
[18:17] <tgardner> bails*
[18:18] <sconklin> that's not terribly useful
[18:18] <tgardner> doesn't seem like it to me either
[18:18] <bjf> sconklin, from what i've seen, it depends on the failure
[18:19] <bjf> hggdh, ^^ thoughts?
[18:19] <hggdh> sconklin: no, I do not stop on first failure
[18:20] <hggdh> the failure may be localised, or other archs/kernels may show different failures, so I consider it worth the time to keep on
[18:21] <hggdh> what I do is warn I found a failure, tag the bug accordingly, and keep on
[18:21] <hggdh> bjf: ^ 
[18:22] <bjf> hggdh, thanks, i think that is what we'd like to see done as well
[18:22] <bjf> sconklin, tgardner ^^
[18:22] <tgardner> ack
[18:22] <sconklin> hggdh: thanks!
[18:22] <hggdh> specifically to the QRTs, all unit tests on each module are run to the end
[18:23] <sconklin> hggdh: did you see that I overrode your QA failure?
[18:23] <hggdh> sconklin: yes, I did see. I had just ended with the KVM tests, so all is kosher
[18:23] <sconklin> hggdh: Thanks!
[18:24] <hggdh> sconklin: and this is actually what I expect to happen. I should not decide on overriding or not
[18:25] <hggdh> so... Lucid and Natty done. bjf, sconklin, a specific version you would like me to work on now, or anyone left is good?
[18:25] <sconklin> hggdh: ok, thanks. We'll have to modify processes as appropriate as QA gets more integrated and automated.
[18:26] <sconklin> Maverick is important for some folks. It may not be back in -proposed yet, let me check - hold on
[18:27] <hggdh> aye. Hoiw do you want go to forward on this error (Natty EC2 m1.small/i386 CONFIG_DEBUG_RODATA)? Pass the next one, or still mark as failure?
[18:27] <sconklin> still mark as failure, because we should have it fixed in the next release. Force me to override it if needed ;)
[18:28] <hggdh> :-) a pleasure to, er, help ;-)
[18:30] <sconklin> hggdh: Maverick is still awaiting copy to -proposed, and as soon as that is done we will mark it verification complete because it is simply a respin with some reverts.
[18:30] <sconklin> So in the meantime, grab something else . . .
[18:30] <hggdh> sconklin: roger wilco
[18:32]  * tgardner --> lunch
[19:31]  * jjohansen -> lunch
[19:35] <njin> hello, there's someone experiencing Error insetingpadlock_sha in 3.0.0-4 ? any workaround to restore system?
[19:36] <njin> Error inserting padlock_sha
[19:41] <tgardner> njin, is it the right kind of CPU ? 
[19:41] <tgardner> this is not typically a fatal error
[19:42] <njin> tgardner, is the yesterday update, system is locked at login screen, nothing working, no panic
[19:43] <tgardner> njin, thats likely something other then a crypto engine failure
[19:43] <njin> encrypted /home cannot be mounted, no mouse or console, only sysrq
[19:43] <njin> unfortunately no thing in the log files
[19:43] <tgardner> njin, and 3.0-3 consistently works ?
[19:44] <njin> 3.0-3 yes fine
[19:44] <tgardner> njin, boot 3.0-3 and run 'ubuntu-bug linux' with a description of the problem. 3.0.0-5.6 is almost ready as well (-rc7)
[19:45] <njin> tgardner, many thanks, i'll do it
[19:55] <bjf> jjohansen, ok as roomie for orlando?
[19:57] <tgardner> ogasawara, oneiric is done building. would you like me to upload -meta ?
[19:57] <ogasawara> tgardner: go for it
[20:01] <jjohansen> bjf: yep
[20:04] <bjf> jjohansen, ok, i've entered it into the write-only registration system
[20:05] <jjohansen> bjf: ugh, I can't believe we have to use that system again
[20:06] <tgardner> ogasawara, uploaded and announcement sent
[20:06] <ogasawara> tgardner: awesome, thanks
[20:06] <ogasawara> tgardner: I'll post a blurb to voices.c.c too
[20:07] <tgardner> ogasawara, hmm, did ubuntu-mobile@lists.ubuntu.com go away? I got a bounce message
[20:07] <ogasawara> tgardner: it bounced for me as well so I quit sending to it
[20:08] <tgardner> ogasawara, I guess I'll fix the wiki
[20:17] <hggdh> smb: there still?
[20:23] <jjohansen> hggdh: hopefully not, its 22:22 for him
[20:23] <hggdh> jjohansen: heh. I had to try... will ping him tomorrow, then, thank you
[20:23] <jjohansen> hggdh: anything I can help with?
[20:24] <jjohansen> hggdh: I could also rely a message when he comes on in the morning
[20:33] <hggdh> jjohansen: this is related to bug 790712 -- smb asked for a syslog. But a debian-installer "syslog" shows much of the installer activities, and almost nothing else...
[20:33] <ubot2> Launchpad bug 790712 in linux "20110531 i386 server ISO: order 5 allocation failure during install" [High,Confirmed] https://launchpad.net/bugs/790712
[20:33] <hggdh> jjohansen: so I added a d-i syslog to the bug, but I am unsure on what he will find there...
[20:34] <jjohansen> hggdh: can you add the kernel log as well
[20:34] <hggdh> jjohansen: there is no kernel log
[20:34] <jjohansen> hggdh: no kernel log?  How about dmesg?
[20:35] <jjohansen> is it possible to retrieve that
[20:35] <hggdh> hum
[20:35] <hggdh> not directly -- the install never ends, so we do not have control/access to the VM. But I can run it manually here, reproduce the error, and collect it (I hope)
[20:36] <jjohansen> hggdh: if its doing order 5 allocations, it isn't surprising that it is failing
[20:36] <jjohansen> hggdh: worth a try
[20:36] <hggdh> I do not disagree. The thing is 480M should be enough to install an i386 kernel... and it does not happen always
[20:41] <ogasawara> apw: just fyi, I'm able to post to voices.c.c/kernelteam
[21:22] <manjo> ogasawara, in delta review Manoj Iyer
[21:22] <manjo> Quirk to fix suspend/resume on Lenovo Edge 11,13,14,15
[21:22] <manjo> UBUNTU: SAUCE: (drop after 2.6.38) add ricoh 0xe823 pci id.
[21:22] <manjo> those two patches can be dropped as they should be in stable already
[21:23] <manjo> ogasawara, the 3rd one has original author as Timo so I have emailed him to report the status
[21:23] <bjf> manjo, did you add your comments to the blueprint like everyone else?
[21:24] <manjo> bjf, not yet ... this was just brought to my attn so going to do that next .. thought I will tell ogasawara 1st 
[21:24] <bjf> manjo, and actually its the spec at: https://wiki.ubuntu.com/KernelTeam/Specs/KernelOneiricUbuntuDeltaReview
[21:25] <manjo> bjf, thanks yes I know
[21:27] <manjo> bjf, just updated blueprint
[21:28] <manjo> bjf, I think ogasawara needs to mod the wiki? 
[21:55] <ogasawara> manjo: thanks, if you can just make a note of this in the wiki under your section that'd be good.  I'll revert the two patches for now and then drop them upon the next rebase.