[01:22] ogasawara / apw: kernel iz broke on armhf. [01:22] https://launchpad.net/ubuntu/+source/linux/3.5.0-17.26/+build/3876916 === henrix_ is now known as henrix === henrix is now known as henrix_ === henrix_ is now known as henrix [11:18] * apw is looking into the -17 quantal armhf build failure [12:15] * henrix -> lunch === doko__ is now known as doko [12:31] apw: ping? [12:32] oing [12:33] apw: I seemed to have missed what our build failure was for armhf [12:34] apw: looks like the build was restarted though [12:34] ogasawara, the error was essentiall the compiler trynig to read the file with the first 3 lines missing [12:35] ogasawara, it worked just fine on armel with the same config, so we put it back to see if it is transient [12:35] ogasawara, if it is we should cry [12:35] apw: first 3 lines missing?!?! that doesn't sound good. [12:36] no, its first error was about the @ in the copyright messages [12:36] apw: very odd [12:37] ogasawara, worrying is the word i am using [12:38] apw: indeed, worrying is a better word [12:45] ogasawara, Just to get some feeling, when would you plan a next upload to the quantal kernel? [12:45] smb: in a perfect world, not until after we release. we obviously know that's never the case. [12:46] smb: so I suspect upon the next critical bug fix, whenever that may be. [12:46] Then I hope for the imperfect world and that I get more feedback on my latest test kernel for 1021471 [12:46] bug 1021471 [12:46] 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] that one prolly counts as critical [12:47] smb: I think that itself would be the critical bug we're looking for [12:47] smb: and I suspect, the release team would allow an upload to fix that between now and next friday [12:48] :) 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] 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] ogasawara: smb: i think i've a commit for master too [12:51] ppisati: ack [12:52] apw: last week we had a compiler failure on O armel, build was restarted and the failure disappeared [12:52] apw: you should prod infinity [12:56] i am sure he will say buildds are like that [12:57] ogasawara, 41 minutes in [13:02] apw: do we have a dmesg of that builder? [13:03] ppisati, not that i know of [13:11] skaet: still looking for verification of bug 1033568. i'd hate to have to revert it. [13:11] 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] bjf: well, the worst case? it didn't work before and still doesn't? [13:31] 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] Launchpad bug 1061070 in linux "Reboot sometimes fails on highbank" [Medium,Confirmed] [13:33] rbasak: ubuntu-quantal branch on our kernel tree or ikepanhc's kernel tree. [13:35] rbasak: the patch in quantal-proposed (Ubuntu-3.5.0-17.26) [13:37] rbasak: robher: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=commit;h=4743004fad90f0078073222342c62557bdd5d6b7 [13:38] 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] 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] xnox, that's not the worst case. if it's not verified it gets reverted. [13:40] I understand. I just thought it was the hash of the entry in some repo I could get to [13:41] rbasak: sorry, I should have been more specific. [13:42] ikepanhc: when will it land in quantal? [13:43] apw: do we have plan to land quantal-17.26 before quantal release? [13:43] ikepanhc, i would expect it to be copied over once it has built yes [13:43] bjf: ok. I thought if a revert happens -> new upload -> everything needs to be retested. [13:44] bjf: but I am not familiar with kernel procedures to be honest. [13:44] xnox, nah, we're not that bad [13:44] apw: thanks [13:44] bjf: I had to retest everything after a revert in mdadm sru =( [13:44] robher: very soon I believe [13:44] 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] 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] bjf: for this specific bug, there are 3 (not so trivial) commits [13:47] henrix, ouch [13:48] 4743004 [13:48] oops === yofel_ is now known as yofel [16:03] * ppisati goes out to buy some stuff [16:07] ogasawara, looks like armhf is building correctly this time [16:07] rtg: indeed, appears to have gotten much farther than the initial build [16:08] rtg: which is good, but also concerning as to why the first build failed [16:08] ogasawara, ghost in the machine [16:10] 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] I'm guessing some level of corruption? [16:10] ogasawara, its more likely that the source package wasn't delivered correctly. [16:27] ogasawara, i think we have had cases where throwing the builds back at the wall until the stick is a normal approach [16:27] ogasawara, it oculd be a compiler bug with something unitialised, or just bust h/w [16:28] ogasawara, not that we should not be crapping selves over it of course [16:29] 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] ogasawara, i was an oddy indeed [17:04] apw: rebuild worked! [17:05] Daviey, that a worry and no mistake [17:05] I should have just given it back last night, in retrospect. [17:05] meh, it should be very rare that giving it back helps [17:06] apw: clearly you don't have the racey unit tests we have to put up with in userspace. [17:06] 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] sconklin, are you working on bug #987566 ? [17:34] Launchpad bug 987566 in linux-armadaxp "CVE-2012-2119" [Low,Fix released] https://launchpad.net/bugs/987566 [17:35] rtg: why yes I am, right now. [17:35] sconklin, ok, I'll leave you to it. [17:35] I should have lied. It's not straightforward :-) [17:36] sconklin, this is the macvtap bug, right ? [17:36] yes [17:36] I'm just looking at Oneiric now [17:38] 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] ack [17:41] * rtg -> lunch [17:43] 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] 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] apw: ack === henrix is now known as henrix_ === henrix_ is now known as henrix [18:30] henrix, bjf - 1033568, has been validated to work fine. Thanks henrix, bjf, jsalisbury :D [18:31] skaet, thanks [18:31] skaet: ack, thanks! [18:43] * henrix -> EOD === henrix is now known as henrix_ [18:45] apw: you here? [18:49] sconklin, yep [18:50] 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] 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] remind me to buy you a beer at UDS [18:52] the CVE matrix is looking pretty good [19:07] yeah we did pretty well zapping the ones which were old and actually closed [19:07] 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] apw, if we could get rid of those natty columns we'd look *really* good [19:48] bjf, they will go away RSN when we go EOL, what 3 weeks? === Nafallo is now known as ubot2 === ubot2 is now known as Nafallo [20:02] apw, yup [20:15] * ogasawara lunch [20:36] * rtg -> EOD [21:28] fyi; https://bugs.launchpad.net/ubuntu/+source/linux/+bug/992639 [21:28] 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] re: delay_use for usb_storage. [22:03] bjf: Was there a bug filed for the apparmor regression test failure I was looking at? [22:04] jjohansen: yes [22:04] * jjohansen has been looking back through his logs and has only found Bug #1057623 [22:04] Launchpad bug 1057623 in ubuntu-kernel-tests "test_apparmor failures on armhf-omap4" [Undecided,New] https://launchpad.net/bugs/1057623 [22:04] jjohansen: that looks like one, but i think i filed one as well [22:05] looking [22:05] 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] jjohansen: bug 1050430 [22:10] Launchpad bug 1050430 in apparmor "QRT regression test failure on quantal" [Undecided,New] https://launchpad.net/bugs/1050430 [22:11] bjf: thanks [22:14] bjf: thanks