[01:47] <infinity> xnox: It's not noatime, it's ext3 versus ext4, I suspect.  A testsuite that expects high resolution *times is probably broken, IMO.
[08:10] <xnox> infinity: built on sagari just fine =) and i'm going to ignore zsh for another decade if I can =)
[09:02] <bzoltan> Hello release team. I have a problem with a failing  autopkgtests http://paste.ubuntu.com/7762643/ on the online_accounts_ui.tests.test_online_accounts_ui.OnlineAccountsUiTests.test_title.   We cornered the issue and there is an MR https://code.launchpad.net/~elopio/ubuntu-system-settings-online-accounts/clean_tests/+merge/225437 to address this problem. Is there a way to unblock the UITK landing as this failure is more about the flaky
[09:29] <cjwatson> bzoltan: I'd like to see the tests passing first, at which point, well, the easiest thing would be to just land the u-s-s-o-a change ...
[09:30] <bzoltan> cjwatson: that would block the UITK for an other day
[09:31] <cjwatson> I'm more worried about allowing regressions into the archive which will mean that we then lose our guard against other regressions in the same component
[09:31] <cjwatson> Has somebody run the u-s-s-o-a tests in a clean autopkgtest environment?
[09:31] <cjwatson> (with the change above)
[09:31] <bzoltan> cjwatson: I do not know, but I do not think so.
[09:32] <cjwatson> OK, I guess I have to then :-(
[09:32] <bzoltan> cjwatson: thank you
[09:32] <cjwatson> This will take some time
[09:35] <bzoltan> cjwatson: my problem is that the UITK tests cover practically _all_ app tests on _all_ environment ... and we suffer from flaky or badly written tests. elopio and timp are already fixing the tests for dozen of apps, because if I would just wait for the app devs to fix their tests I would never be able to release the UITK. Even now with the whole SDK team fixing other teams tests it takes a week to land the UITK.
[09:38] <cjwatson> Nevertheless, I'm not going to override a failure when I haven't confirmed that the putative fix actually fixes it
[09:39] <cjwatson> Because while I sympathise with what you're describing it *also* describes a component where we have to take care to ensure it doesn't genuinely regress
[09:41] <bzoltan> cjwatson: Your point is valid. If I were you most probably I would make the same call. Maybe it is just not realistic to expect daily UITK release. We better be careful with a component what is so broadly used.
[09:42] <bzoltan> cjwatson:  I think I will take the autopkg tests on the UITK test plan. Is this guide valid : http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test ?
[09:45] <ginggs> Hi, nvidia-graphics-drivers Trusty SRU (LP: #1247736) has been sitting in unapproved for a month.  Is anything needed?
[09:48] <cjwatson> bzoltan: I believe so, though I haven't used the cloud-image-based execution mode as yet myself (there are more lightweight but less accurate versions); trying that for the first time now
[09:48] <cjwatson> argh, urllib.ContentTooShortError: retrieval incomplete: got only 202031681 out of 260178432 bytes
[09:49] <cjwatson> Maybe that was a bad time to upgrade squid
[13:02] <Saviq> cjwatson, hey, apparently http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings-online-accounts missed the new needed dep of ubuntu-ui-toolkit-autopilot for autopkgtests
[13:02] <Saviq> cjwatson, could you please do a direct upload with that added?
[13:08] <Laney> Saviq: I'll test/upload that
[13:09] <bzoltan> Laney: thank you for that
[13:09] <Saviq> Laney, thanks
[13:09] <Laney> sure
[13:20] <Laney> yeah that passes
[13:30] <Mirv> excellent
[13:38] <bzoltan> Laney: cool
[13:39] <Laney> they asked me to increase the upstream version of ubuntu-ui-toolkit
[13:39] <Laney> so give me a few minutes to upload this and then version the test-dep
[16:01] <ginggs> Anyone in SRU team able to look at nvidia-graphics-drivers Trusty SRU (LP: 1247736) please?  It has been sitting in 'unapproved' for some time.
[16:15] <psivaa> infinity: cjwatson: Precise d-i installer throws 'no packages matching running kernel 3.11.0-23-generic in archive'. this transient mismatching kernel version issue?
[16:15] <psivaa> s/this/is this/
[16:29] <infinity> psivaa: Erm, it shouldn't.
[16:30] <infinity>  linux-image-3.11.0-23-generic | 3.11.0-23.40~precise1 | precise-updates  | amd64, armhf, i386
[16:31] <infinity> psivaa: Wait, is this a netinst, or an ISO?
[16:31] <psivaa> infinity: this is the iso
[16:31] <infinity> psivaa: Ahh, kay, CDs might be mismatched right now.
[16:31] <psivaa> infinity: ack, thanks
[16:31] <infinity> psivaa: And in need of s/saucy/trusty/ and other bits while we prep for the point release.
[16:32] <infinity> psivaa: I should go mangle some seeds to resolve that.
[16:32] <psivaa> infinity: ack
[16:32] <psivaa> infinity: wasn't urgent. just thought of informing :)
[16:33] <infinity> psivaa: Yeah.  The ISOs will probably be a mess for the next week or so while we sort out .5
[16:33] <infinity> psivaa: Should be a bit more testable (and on trusty's HWE stack) by next week, I hope.
[16:33] <psivaa> infinity: ack, will check by then.
[17:42] <bdmurray> Is there any way to SRU verify bug 1233185 on porter-armhf? I'd need to install the package from -proposed.
[19:34] <doko> bdmurray, -proposed should be enabled on the porter boxes
[19:36] <bdmurray> doko: it wasn't when I looked
[19:37] <doko> hmm, well, makes sense for stable releases
[19:37] <doko> maybe we need chroots with proposed enabled for stable releases too
[19:37] <doko> anyway, semi finale now ...  schlaaaaaaaaaaaaaand!
[19:51] <slangasek> bdmurray: have you worked around the SRU verification?  Maybe running gdb under qemu-user in a chroot?