=== Ursinha-afk is now known as Ursinha [01:47] 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] infinity: built on sagari just fine =) and i'm going to ignore zsh for another decade if I can =) [09:02] 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] 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] cjwatson: that would block the UITK for an other day [09:31] 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] Has somebody run the u-s-s-o-a tests in a clean autopkgtest environment? [09:31] (with the change above) [09:31] cjwatson: I do not know, but I do not think so. [09:32] OK, I guess I have to then :-( [09:32] cjwatson: thank you [09:32] This will take some time [09:35] 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] Nevertheless, I'm not going to override a failure when I haven't confirmed that the putative fix actually fixes it [09:39] 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] 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] 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] Hi, nvidia-graphics-drivers Trusty SRU (LP: #1247736) has been sitting in unapproved for a month. Is anything needed? [09:45] Launchpad bug 1247736 in nvidia-graphics-drivers-340 "[SRU] nvidia-opencl-icd-* should not conflicts/replaces on opencl-icd" [Undecided,Confirmed] https://launchpad.net/bugs/1247736 [09:48] 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] argh, urllib.ContentTooShortError: retrieval incomplete: got only 202031681 out of 260178432 bytes [09:49] Maybe that was a bad time to upgrade squid === doko__ is now known as doko [13:02] 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] cjwatson, could you please do a direct upload with that added? [13:08] Saviq: I'll test/upload that [13:09] Laney: thank you for that [13:09] Laney, thanks [13:09] sure [13:20] yeah that passes === Adri2000_ is now known as Adri2000 [13:30] excellent [13:38] Laney: cool [13:39] they asked me to increase the upstream version of ubuntu-ui-toolkit [13:39] so give me a few minutes to upload this and then version the test-dep [16:01] 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:01] Launchpad bug 1247736 in nvidia-graphics-drivers-340 "[SRU] nvidia-opencl-icd-* should not conflicts/replaces on opencl-icd" [Undecided,Confirmed] https://launchpad.net/bugs/1247736 === gaughen_ is now known as gaughen [16:15] 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] s/this/is this/ [16:29] psivaa: Erm, it shouldn't. [16:30] linux-image-3.11.0-23-generic | 3.11.0-23.40~precise1 | precise-updates | amd64, armhf, i386 [16:31] psivaa: Wait, is this a netinst, or an ISO? [16:31] infinity: this is the iso [16:31] psivaa: Ahh, kay, CDs might be mismatched right now. [16:31] infinity: ack, thanks [16:31] psivaa: And in need of s/saucy/trusty/ and other bits while we prep for the point release. [16:32] psivaa: I should go mangle some seeds to resolve that. [16:32] infinity: ack [16:32] infinity: wasn't urgent. just thought of informing :) [16:33] psivaa: Yeah. The ISOs will probably be a mess for the next week or so while we sort out .5 [16:33] psivaa: Should be a bit more testable (and on trusty's HWE stack) by next week, I hope. [16:33] infinity: ack, will check by then. [17:42] Is there any way to SRU verify bug 1233185 on porter-armhf? I'd need to install the package from -proposed. [17:42] bug 1233185 in gdb "gdb-multiarch cannot read ARM cores: "wrong size gregset struct in core file"" [High,Fix committed] https://launchpad.net/bugs/1233185 [19:34] bdmurray, -proposed should be enabled on the porter boxes [19:36] doko: it wasn't when I looked [19:37] hmm, well, makes sense for stable releases [19:37] maybe we need chroots with proposed enabled for stable releases too [19:37] anyway, semi finale now ... schlaaaaaaaaaaaaaand! [19:51] bdmurray: have you worked around the SRU verification? Maybe running gdb under qemu-user in a chroot? === xnox is now known as xnox_ === xnox_ is now known as Eisbrecher === Eisbrecher is now known as Eisbrecher_xnox