[00:07] <bjf> infinity, turning the crank boss
[00:07] <bjf> i swear i'm going to get the bot to also monitor this channel so you can tell it run
[00:08] <infinity> +1
[00:23] <infinity> bjf: I suspect we have an oops with 1117447 ... Maybe I should just handle it manually instead of trying to teach the bot WTF is going on there.
[00:23] <infinity> bjf: (Its parent bug was duped to the new master bug, due to an x86-only revert, so the parent never got "promoted", so this one will sit in a holding pattern)
[00:24] <bjf> infinity, if you mark the Kernel SRU Workflow task as invalid the bot will ignore it
[00:25] <infinity> bjf: Sure, ignoring it wasn't what I was hoping for, but "the bot doing the right thing" probably means teaching it reasoning. :)
[00:25] <infinity> bjf: So, ignoring it seems fine.  I'll do that and update it manually.
[07:39] <ppisati> moin
=== smb` is now known as smb
[08:16] <smb> moin
=== henrix_ is now known as henrix
[09:23]  * apw yawns
[11:58] <henrix> apw: you around?
[12:00] <henrix> i'm having a weird build failure for armel. this morning i had a build failure with this: http://pastebin.ubuntu.com/1681519/
[12:00] <henrix> i tried a build in gomeisa and it was building fine, so i tried a rebuild
[12:01] <henrix> but its failing again with same error but in a different file
[12:01] <henrix> (previous file succeeded)
[12:01] <henrix> apw: any ideas?
[12:02] <henrix> apw: the current failure is here: https://launchpadlibrarian.net/131735908/buildlog_ubuntu-quantal-armel.linux_3.5.0-25.38_FAILEDTOBUILD.txt.gz
[12:04] <apw> henrix, very odd
[12:04] <henrix> apw: yep. looks like the file is corrupted, but it isn't
[12:05] <henrix> apw: i can try another rebuild, but since the build can take a couple of hours...
[12:05] <apw> we have had this before if it happens a couple of times on the same buildd, then we might need to get that buildd looked at
=== arun_ is now known as arun
[12:05] <apw> henrix, so i would note where it buolded and take the log, and put it back again
[12:06] <henrix> apw: ok, i'll keep all the logs and retry
[12:06] <henrix> apw: thanks
[12:06] <apw> henrix, but it is a worry for sure
[12:11] <henrix> apw: the build restarted in a different buildd (the 2 previous failures occurred in the same buildd)
[12:57]  * henrix -> SIGFOOD
[13:12] <apw> henrix, well that is a good thing to know, perhaps that original buildd is bust
[13:16]  * rtg rebases raring against 3.8 final
[13:35] <brendand> henrix, will the new -proposed kernels be prepped and ready for verification testing by the end of this week?
[13:36] <henrix> brendand: yes
[13:46] <sforshee> stgraber, did you ever get your x230 fixed?
[13:51] <infinity> henrix: Curious.  Why did the recent SRU patches cause an ABI bump for quantal, but not precise?
[13:52] <henrix> infinity: actually, i'm also a little bit puzzled with that. i know that Q failed to build in the ABI checks for armel and armhf, and P didn't
[13:52] <henrix> infinity: i haven't analysed the reason yet
[13:53] <rtg> different compiler versions ?
[13:54] <infinity> henrix: Seems a bit odd.  Anyhow, the reason I need to pay attention is because I need to remember to copy the lbm/meta to security from the previous SRU when we release this one, which will be a bit annoying.
[13:54] <infinity> (I still need to figure out how to win the "screw ABI numbers, let's just bump on every build" fight)
[13:55] <henrix> rtg: that could explain it, i believe
[13:55] <henrix> if i figure that out, i'll let you guys know
[13:56] <infinity> Different compiler versions shouldn't be leading to different symbols being exported when one introduces the same patches, one would hope.
[13:56] <infinity> But it's possible.
[13:57] <henrix> well, i know if was failing for armel and armhf but not for amd64 and i386
[13:58] <henrix> s/if/it
[14:01] <infinity> henrix: That's even more weird.
[14:01] <henrix> yep
[14:02] <ppisati> armel? quantal?
[14:03] <henrix> ppisati: yes
[14:03] <ppisati> thos two words in the same sentence sound like an oximoron to me
[14:03] <ogra_> yeah
[14:03] <ogra_> not worth even wasting thoughts on it
[14:03] <ppisati> +1
[14:03] <infinity> Except that the problem was also there for armhf.
[14:04] <infinity> So...
[14:04] <ogra_> we never supported armel after 12.04 ... its "just there"
[14:04] <ppisati> ah then...
[14:04] <ogra_> yeah, indeed,, if its armhf too, its valid
[14:04] <infinity> Which makes sense, since kernels compiled on armel and armhf should be identical.
[14:04] <henrix> ppisati: right, i keep forgetting that and my scripts will try to build both armel and armhf
[14:05]  * henrix goes remove armel from the Q builds!
[14:05] <infinity> I had a dream last night that we replaced all our ARM buildds with datacenter-grade armv8 machines.
[14:05] <infinity> Waking up to reality was unpleasant.
[14:05] <infinity> henrix: No, don't do that.
[14:05] <infinity> henrix: If we were going to do that, we should have done it before release, not now.
[14:05] <maswan> infinity: those are what, at least a year out still?
[14:05] <infinity> henrix: You're not going to have any armel-specific failures, so just leave it be.
[14:06] <henrix> infinity: oh, i meant from my build test scripts ;)
[14:06] <infinity> maswan: At least, yeah.  I guess I'm more optimistic in my sleep.
[14:06] <infinity> henrix: Oh, sure.  You could have done that ages ago, since armel/armhf kernels should be identical, save timestamps.
[14:06] <stgraber> sforshee: nope, they ended up having to ship the unit to Ontario for someone there to take a look. Should have it back by EOW
[14:06] <infinity> henrix: That's true on precise too, for that matter.
[14:06] <henrix> infinity: ack
[14:06] <sforshee> stgraber, that's too bad
[14:07] <ppisati> infinity: how abot those calxeda nodes that were spposed to replace all our buildds?
[14:07] <sforshee> stgraber, so Ted Tso commented on the upstream bug that his x230 works fine, and he was using a newer firmware version than you had
[14:07] <infinity> ppisati: People got all excited about getting me those, then I heard something about availability issues, then I heard... Nothing.
[14:08] <infinity> ppisati: Given that I know Linaro just got some new toys along those lines, I should probably reopen that conversation.
[14:08] <ppisati> infinity: life sucks and then you die.
[14:08] <stgraber> sforshee: yeah, IIRC I was 2 firmware updates behind but they were just adding support for a longer serial number and some new hardware support (I definitely would have updated if I saw anything related to UEFI bugs). Anyway, I'll make sure the one I get back is fully up to date.
[14:08] <infinity> ppisati: That's a bit dark for a Tuesday morning, but I can't say I disagree with the sentiment. :/
[14:09] <sforshee> stgraber, okay. I didn't see anything in the changes that looked like it should address the bug either. But his bios version also wasn't listed on Lenovo's website ...
[14:22] <hggdh> infinity: the Precise armadaXP kernel is all yours
[14:23] <infinity> henrix: Want to crank the bot a couple of times, so the tracking bug agrees with hggdh?
[14:23] <henrix> infinity: sure, in a minute
[14:26] <henrix> infinity: should be all done
[14:26] <infinity> henrix: Danke.
[14:28] <rtg> apw, 'UBUNTU: [Config] CONFIG_MTD_ONENAND_SIM=n' caused a build failure. tsk, tsk.
[14:33] <smb> rtg, he isn't listening right now
[14:33] <rtg> smb, s'alright. I was just hassling him
[14:34] <smb> rtg, Obviously, but it is more fun when he can see it. :)
[14:35]  * rtg will be back in a bit
[15:06] <bjf> bug 1092924
[15:06] <ubot2> Launchpad bug 1092924 in UTAH "Cobbler install of recent raring-desktop images failing" [High,Triaged] https://launchpad.net/bugs/1092924
[15:09] <doanac> bjf: yes - I spent some time running the 20130116 and 20130204 builds and out of 6 failures I hit, this stack trace was in 5 of them
[15:11] <bjf> doanac, has someone tried installing the daily iso onto that machine just using a usb stick?
[15:11] <doanac> bjf: I think plars does that type of install and it hasn't been a problem
[15:12] <doanac> however, that way won't work for us in qa automation
[15:12] <bjf> doanac, i understand, i'm just trying to get more data
[15:13] <gema> bjf: given the rate at which this error happens, if it happened with a usb it'd be fixed by now
[15:13] <gema> bjf: that'd be my take on it
[15:14] <gema> bjf: it makes our automation on hardware non-usable
[15:14] <bjf> gema, i'm quite aware of that
[15:16] <doanac> bjf: do you think that trace is enough information to help?
[15:17] <bjf> doanac, it helps, not sure it's going to be enough though
[15:18] <bjf> doanac, it would be good to get that system up so that we can collect all the log information (that contains info about the system hardware)
[15:18] <doanac> bjf: i can do that.
[15:18] <doanac> how do you prefer I get that information?
[15:18] <bjf> jsalisbury, ^ needs to be on our hot list (for now)
[15:20] <bjf> doanac, "apport-collect 1092924"
[15:21] <doanac> bjf: okay, I'll give that a shot right now. thanks
[15:22] <jsalisbury> bjf ack
[15:23] <bjf> doanac, if we can get more of the syslog than just the stack trace, that would also be helpful
[15:23] <doanac> bjf: sure, I'll grab the full install log
[15:25] <bjf> doanac, is this the same errors that you are having on the power testing systems?
[15:26] <doanac> bjf: I haven't dug into those jobs, so I don't know for sure
[15:26] <bjf> doanac, ack
[15:28] <gema> bjf: it is
[15:28] <gema> bjf: at least one of them
[15:28] <bjf> gema, interesting since the HW is different
[15:29] <gema> doanac: maybe we should try to reproduce on one of those machines also and attach some more logs
[15:29] <gema> doanac: plars could get you access to those
[15:29] <doanac> gema: i've got things set up now to make it pretty easy to reproduce a bug
[15:29] <gema> bjf: indeed, we were seeing the same behaviour in the installs, but until now, we didn't have logs
[15:30] <gema> bjf: now we can have some runs and try to gather more logs from those
[15:30] <gema> doanac: sounds good
[15:31] <bjf> gema, doanac, yes, please try to reproduce there and if you have problems, open a new bug with the logs for that system attached to that bug
[15:31] <bjf> gema, doanac, we will dupe one against the other if it truly is a duplicate
[15:31] <gema> bjf: ack
[15:35] <lool> rtg, apw: Hey!  I was wondering whether someone is looking at updating hte Nexus 7 kernel with Android 4.2.2 changes?  there might be some interesting bug fixes there
[15:35] <rtg> lool, last I looked the kernel had not changed.
[15:35] <lool> oh really
[15:36] <rtg> lool, that was a week ago. checking...
[15:36] <rtg> lool, hmm, new branch: android-tegra3-grouper-3.1-jb-mr1.1
[15:37]  * ogasawara back in 20
[15:37] <rtg> lool, guess we'll take a stab at it.
[15:40] <lool> rtg: seems to be about 3 commits on top of -mr1
[15:41] <rtg> lool, I'll pick 'em up and test them on my N7
[15:41] <lool> rtg: awesome, thanks!
[15:41] <lool> video, proximity sensor and wifi fixes apparently
[15:42] <lool> ogra_: ^
[15:42] <lool> ogra_: https://android.googlesource.com/kernel/tegra/+log/android-tegra3-grouper-3.1-jb-mr1.1
[15:44] <ogra_> lool, thanks
[15:55] <jsalisbury> **
[15:55] <jsalisbury> ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:55] <jsalisbury> **
[16:30] <rtg> apw, ogasawara: uploaded raring rebase on 3.8 final
[16:30] <rtg> working on N7
[16:30] <ogasawara> rtg: ack
[16:40] <rtg> herton, henrix: y'all might want to have a look at the bug states for bug #1130111. create-release-tracker puked a python stack dump after the bug was created. I assume it failed to set some states correctly.
[16:40] <ubot2> Launchpad bug 1130111 in Kernel Development Workflow "linux: 3.8.0-6.14 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1130111
[16:40] <herton> rtg, ack, do you have the trace
[16:40] <herton> ?
[16:41] <rtg> oh right, like I'd do something smart like that.
[16:41] <herton> the bug looks ok, though since I changed create-release-tracker last week probably introduced a bug with it
[16:42] <rtg> herton, I'll be smarter about it next time. I frequently use 'screen' which is lousy at allowing to scroll back (and it was a lot of stack dump output)
[16:43] <herton> rtg, np, I'll try to reproduce
[16:43] <rtg> herton, I was on Precise at the time
[16:52] <herton> rtg, just noted that bug is pointing at the wrong kernel version. I guess create-release-tracker was running at some point before the version was ok at the changelog
[16:53] <rtg> herton, I thought I updated the description. refresh ?
[16:53] <herton> rtg, indeed :)
[16:59] <cking> rtg, I've kicked off a clean smatch run, will take a few hours to complete
[17:00] <rtg> cking, ack. thanks
[17:00] <jsalisbury> ##  
[17:00] <jsalisbury> ## Meeting starting now
[17:00] <jsalisbury> ##
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues February 26th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!
[17:13]  * ppisati goes to get some food, brb
[17:36] <bjf> doanac, once you file the bug for the power testing system, post the bug number back here please
[17:37] <doanac> bjf: will do,
[17:37] <rtg> lool, uploaded linux-nexus7_3.1.10-9.27, rebased on android-tegra3-grouper-3.1-jb-mr1.1. tests looked OK
[17:57] <lool> rtg: \o/
[17:57] <lool> rtg: thanks
[17:57] <lool> ogra_: ^
[17:57] <ogra_> yay
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
[18:18]  * rtg -> lunch
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
=== henrix_ is now known as henrix
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
=== sabayonuser is now known as Tuxkalle
[21:29] <ogasawara> rtg: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1026831
[21:29] <ubot2> Ubuntu bug 1026831 in debian-installer (Ubuntu Precise) "Seed the correct Q LTS backport kernel meta package in the 12.04.2 point release" [High,Fix released]
[21:31] <rtg> ogasawara, https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1026831/comments/2
[21:31] <ubot2> Ubuntu bug 1026831 in debian-installer (Ubuntu Precise) "Seed the correct Q LTS backport kernel meta package in the 12.04.2 point release" [High,Fix released]
[21:40]  * rtg -> EOD
=== henrix is now known as henrix_
=== ben1u is now known as benlu