[01:22] <infinity> ogasawara / apw: kernel iz broke on armhf.
[01:22] <infinity> https://launchpad.net/ubuntu/+source/linux/3.5.0-17.26/+build/3876916
[11:18]  * apw is looking into the -17 quantal armhf build failure
[12:15]  * henrix -> lunch
[12:31] <jussi> apw: ping? 
[12:32] <apw> oing
[12:33] <ogasawara> apw: I seemed to have missed what our build failure was for armhf
[12:34] <ogasawara> apw: looks like the build was restarted though
[12:34] <apw> ogasawara, the error was essentiall the compiler trynig to read the file with the first 3 lines missing
[12:35] <apw> ogasawara, it worked just fine on armel with the same config, so we put it back to see if it is transient
[12:35] <apw> ogasawara, if it is we should cry
[12:35] <ogasawara> apw: first 3 lines missing?!?!  that doesn't sound good.
[12:36] <apw> no, its first error was about the @ in the copyright messages
[12:36] <ogasawara> apw: very odd
[12:37] <apw> ogasawara, worrying is the word i am using
[12:38] <ogasawara> apw: indeed, worrying is a better word
[12:45] <smb> ogasawara, Just to get some feeling, when would you plan a next upload to the quantal kernel?
[12:45] <ogasawara> smb: in a perfect world, not until after we release.  we obviously know that's never the case.
[12:46] <ogasawara> smb: so I suspect upon the next critical bug fix, whenever that may be.
[12:46] <smb> Then I hope for the imperfect world and that I get more feedback on my latest test kernel for 1021471
[12:46] <smb> bug 1021471
[12:46] <ubot2> Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Triaged] https://launchpad.net/bugs/1021471
[12:47] <rtg> that one prolly counts as critical
[12:47] <ogasawara> smb: I think that itself would be the critical bug we're looking for
[12:47] <ogasawara> smb: and I suspect, the release team would allow an upload to fix that between now and next friday
[12:48] <smb> :) Ok, then I need to get feedback aspish. I think the last iteration step at least looks minimal invasive and works on the testcase
[12:49] <ogasawara> apw: do you remember how far into the armhf build it failed?  just curious if we've made it past the trigger for the previous failure.
[12:51] <ppisati> ogasawara: smb: i think i've a commit for master too
[12:51] <ogasawara> ppisati: ack
[12:52] <ppisati> apw: last week we had a compiler failure on O armel, build was restarted and the failure disappeared
[12:52] <ppisati> apw: you should prod infinity
[12:56] <apw> i am sure he will say buildds are like that
[12:57] <apw> ogasawara, 41 minutes in
[13:02] <ppisati> apw: do we have a dmesg of that builder?
[13:03] <apw> ppisati, not that i know of
[13:11] <bjf> skaet: still looking for verification of bug 1033568. i'd hate to have to revert it.
[13:11] <ubot2> Launchpad bug 1033568 in linux "ACER aspire S3 track pad doesn't work with 12.04, backport needed from 12.10" [Medium,Fix committed] https://launchpad.net/bugs/1033568
[13:21] <xnox> bjf: well, the worst case? it didn't work before and still doesn't?
[13:31] <rbasak> robher: where can I find the commit that you mention in https://bugs.launchpad.net/eilt/+bug/1061070/comments/11 please? I want to cherry-pick it for a test on 3.2.
[13:31] <ubot2> Launchpad bug 1061070 in linux "Reboot sometimes fails on highbank" [Medium,Confirmed]
[13:33] <robher> rbasak: ubuntu-quantal branch on our kernel tree or ikepanhc's kernel tree.
[13:35] <ikepanhc> rbasak: the patch in quantal-proposed (Ubuntu-3.5.0-17.26)
[13:37] <ikepanhc> rbasak: robher: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=commit;h=4743004fad90f0078073222342c62557bdd5d6b7
[13:38] <rbasak> ikepanhc: thank you! I was looking for it by commit hash thinking that it was the hash in that repo. I guess not :)
[13:39] <ikepanhc> hash is not stable until it get into mainline... sometimes I need to grep the git log to find out, especially for CVE patches
[13:40] <bjf> xnox, that's not the worst case. if it's not verified it gets reverted.
[13:40] <rbasak> I understand. I just thought it was the hash of the entry in some repo I could get to
[13:41] <robher> rbasak: sorry, I should have been more specific.
[13:42] <robher> ikepanhc: when will it land in quantal?
[13:43] <ikepanhc> apw: do we have plan to land quantal-17.26 before quantal release?
[13:43] <apw> ikepanhc, i would expect it to be copied over once it has built yes
[13:43] <xnox> bjf: ok. I thought if a revert happens -> new upload -> everything needs to be retested.
[13:44] <xnox> bjf: but I am not familiar with kernel procedures to be honest.
[13:44] <bjf> xnox, nah, we're not that bad
[13:44] <ikepanhc> apw: thanks
[13:44] <xnox> bjf: I had to retest everything after a revert in mdadm sru =(
[13:44] <ikepanhc> robher: very soon I believe
[13:44] <bjf> xnox, and honestly, before it's reverted we will look at it again to see if it's so trivial that we'll let it pass
[13:45] <bjf> xnox, but if it is verifed, we don't have to do the review and it just sails through so that's what we prefer and why i nag (plus i like to nag)
[13:47] <henrix> bjf: for this specific bug, there are 3 (not so trivial) commits
[13:47] <bjf> henrix, ouch
[13:48] <rbasak> 4743004
[13:48] <rbasak> oops
[16:03]  * ppisati goes out to buy some stuff
[16:07] <rtg> ogasawara, looks like armhf is building correctly this time
[16:07] <ogasawara> rtg: indeed, appears to have gotten much farther than the initial build
[16:08] <ogasawara> rtg: which is good, but also concerning as to why the first build failed
[16:08] <rtg> ogasawara, ghost in the machine
[16:10] <ogasawara> rtg: I'm trying to wrap my brain around how the first build failure would even happen where the compiler just overlooks the initial lines in a file
[16:10] <ogasawara> I'm guessing some level of corruption?
[16:10] <rtg> ogasawara, its more likely that the source package wasn't delivered correctly.
[16:27] <apw> ogasawara, i think we have had cases where throwing the builds back at the wall until the stick is a normal approach
[16:27] <apw> ogasawara, it oculd be a compiler bug with something unitialised, or just bust h/w
[16:28] <apw> ogasawara, not that we should not be crapping selves over it of course
[16:29] <ogasawara> apw: indeed, it's definitely not the first time we're kicked a rebuild and "it worked".  But I would say I have never seen this type of failure before.
[16:41] <apw> ogasawara, i was an oddy indeed
[17:04] <Daviey> apw: rebuild worked!
[17:05] <apw> Daviey, that a worry and no mistake
[17:05] <Daviey> I should have just given it back last night, in retrospect.
[17:05] <apw> meh, it should be very rare that giving it back helps
[17:06] <Daviey> apw: clearly you don't have the racey unit tests we have to put up with in userspace.
[17:06] <apw> heh no, but this died compliling a simple file, in the first lines
[17:11]  * rtg gets a whopping 50KiB/s from github
[17:34] <rtg> sconklin, are you working on bug #987566 ?
[17:34] <ubot2> Launchpad bug 987566 in linux-armadaxp "CVE-2012-2119" [Low,Fix released] https://launchpad.net/bugs/987566
[17:35] <sconklin> rtg: why yes I am, right now.
[17:35] <rtg> sconklin, ok, I'll leave you to it.
[17:35] <sconklin> I should have lied. It's not straightforward :-)
[17:36] <rtg> sconklin, this is the macvtap bug, right ?
[17:36] <sconklin> yes
[17:36] <sconklin> I'm just looking at Oneiric now
[17:38] <rtg> sconklin, it would be helpfull if you'd set those bugs to 'inprogress' and assign them so I don't replicate what you're doing.
[17:38] <sconklin> ack
[17:41]  * rtg -> lunch
[17:43] <apw> sconklin, CVE-2012-2390 on oneiric is actually fixed already, its an attibution error.  i have just shoved the annotation in and it is rebuilding
[17:43] <ubot2> apw: Memory leak in mm/hugetlb.c in the Linux kernel before 3.4.2 allows local users to cause a denial of service (memory consumption or system crash) via invalid MAP_HUGETLB mmap operations. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2390)
[17:45] <sconklin> apw: ack
[18:30] <skaet> henrix, bjf -  1033568,  has been validated to work fine.   Thanks henrix, bjf, jsalisbury :D
[18:31] <bjf> skaet, thanks
[18:31] <henrix> skaet: ack, thanks!
[18:43]  * henrix -> EOD
[18:45] <sconklin> apw: you here?
[18:49] <apw> sconklin, yep
[18:50] <sconklin> when I set correct break-fix lines in a CVEs tracker file, do I also have to set not-affected for the appropriate releases, or will that happen automagically?
[18:51] <apw> if you add break-fix: and push them then the next run at :20 will update the tracker and you will get needes/pending etc
[18:51] <sconklin> remind me to buy you a beer at UDS
[18:52] <sconklin> the CVE matrix is looking pretty good
[19:07] <apw> yeah we did pretty well zapping the ones which were old and actually closed
[19:07] <apw> there are a few i think still which are closed and not right but jj is sorting those in theory when he gets time
[19:32] <bjf> apw, if we could get rid of those natty columns we'd look *really* good
[19:48] <apw> bjf, they will go away RSN when we go EOL, what 3 weeks?
[20:02] <bjf> apw, yup
[20:15]  * ogasawara lunch
[20:36]  * rtg -> EOD
[21:28] <cyphermox> fyi; https://bugs.launchpad.net/ubuntu/+source/linux/+bug/992639
[21:28] <ubot2> Launchpad bug 992639 in linux "Regression: 12.04 update breaks support for Internet Sticks (3G modems): Nokia CS-15, Nokia cs-17 and perhaps many others" [High,Confirmed]
[21:29] <cyphermox> re: delay_use for usb_storage.
[22:03] <jjohansen> bjf: Was there a bug filed for the apparmor regression test failure I was looking at?
[22:04] <bjf> jjohansen: yes
[22:04]  * jjohansen has been looking back through his logs and has only found Bug #1057623
[22:04] <ubot2> Launchpad bug 1057623 in ubuntu-kernel-tests "test_apparmor failures on armhf-omap4" [Undecided,New] https://launchpad.net/bugs/1057623
[22:04] <bjf> jjohansen: that looks like one, but i think i filed one as well
[22:05] <bjf> looking
[22:05] <sbeattie> yeah, but that's a different failure, due to PAGE_SIZE not being defined.
[22:05]  * sbeattie is not sure what that's about.
[22:10] <bjf> jjohansen: bug 1050430
[22:10] <ubot2> Launchpad bug 1050430 in apparmor "QRT regression test failure on quantal" [Undecided,New] https://launchpad.net/bugs/1050430
[22:11] <sbeattie> bjf: thanks
[22:14] <jjohansen> bjf: thanks