=== TheLordOfTime is now known as teward === doko_ is now known as doko [10:30] can I force mplayerthumbs through on arm64? mplayer not compiling saying "It seems nobody has ported MPlayer to your OS or CPU type yet." [10:37] port it ;-) [10:38] wibble [10:51] Riddell: please can we stop building mplayerthumbs on arm64 if it's uninstallable, then [10:51] and actually not sure that port would be terribly hard ... I think it might just be configure nonsense? [10:52] let me see, this has enough rdeps that it would be worthwhile. last I looked it was blocked by dependencies but apparently not any more. [11:08] cjwatson: mm yes we could just not build it you're right [11:10] Riddell: I think it might not be hard to do a minimal port at this point, so please hold off a bit? [11:10] Riddell: I'll let you know if I give up :) [11:11] cjwatson: gotcha === psivaa_ is now known as psivaa [11:46] Riddell: uploaded mplayer [11:46] oh nice, thanks cjwatson [12:51] please could I get a release team ack on #1 of bug 1287147 [12:51] Launchpad bug 1287147 in juju-core (Ubuntu Trusty) "[FFe] juju-core 1.18/2.0" [High,New] https://launchpad.net/bugs/1287147 [12:51] its not a stable release but it does move the version we have in 14.04 forwards and fixes some key bugs. [13:17] hello [13:17] any chance someone could ack the postgresql SRUs for all stables? (bug 1294006) [13:17] Launchpad bug 1294006 in postgresql-9.1 (Ubuntu Saucy) "New upstream microreleases 9.3.4, 9.1.13, 8.4.21" [Undecided,In progress] https://launchpad.net/bugs/1294006 [13:18] it's just a formality, it's got a MRE and has been done countless times already [13:18] I'm happy to process them myself if the SRU team is okay with that [13:26] * cjwatson finally disentangles the ruby-multi-xml build failure === psivaa is now known as psivaa-afk [14:02] Daviey, around? could you take a look at #1 on bug 1287147 [14:02] Launchpad bug 1287147 in juju-core (Ubuntu Trusty) "[FFe] juju-core 1.18/2.0" [High,New] https://launchpad.net/bugs/1287147 [14:04] jamespage: ok [14:04] Daviey, thanks :-) === psivaa-afk is now known as psivaa [14:31] hey, so yesterday apparmor migrated even though click-apparmor and apparmor-easyprof-ubuntu autopkgtests failed (apparmor didn't declare a new (but common) python3-pkg-resources Depends which cause imports to fail in the autopkgtests) === lderan_ is now known as lderan [14:31] I fixed the issue, but wondered why apparmor migrated [14:40] jdstrand: inspecting the logs http://paste.ubuntu.com/7130902/ [14:40] jdstrand: click-apparmor, lxc, apparmor-easyprof-ubuntu autopackage tests did run and finish successfully. [14:40] jdstrand: from britney's point of view. [14:40] jdstrand: from logs at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses/2014-03-20/ [14:41] xnox: that is probably for ubuntu2, which was the fix I uploaded [14:41] xnox: ubuntu1 is what had the issue [14:41] https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-apparmor-easyprof-ubuntu/ [14:41] #11 in the build history [14:41] jdstrand: the logs i pasted to you are 2.8.0-0ubuntu38 -> 2.8.95~2430-0ubuntu1 from britney [14:41] hmm [14:42] that is weird cause jenkins gave me failure emails, is in red, says fail all over [14:42] from yesterday 22:45:10 UTC -> 23:28:17 UTC [14:42] Test Result (4 failures / +4) [14:42] jdstrand: hm, chase up with jibel probably -> Do you have any other logs for above post-mortem? [14:43] all the jenkins ones seem to be there [14:44] jibel: hi! https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-apparmor-easyprof-ubuntu/ #11 corresponded with the 2.8.95~2430-0ubuntu1 aparmor upload yesterday. the autopkgtest failures didn't block migration (also see backscroll) [14:44] jibel: I was curious why [14:45] jibel: also note, click-apparmor autopkgtest failed in the same way [14:45] jdstrand: jenkins failed ~ 22:52 UTC it seems, which well in time for 23:05 & 23:28 britney runs to say they FAILED. [14:46] jibel: here is the click apparmor one: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-click-apparmor/ (#22 corresponds to the 2.8.95~2430-0ubuntu1 apparmor upload) [14:47] jibel: not, from my end, this isn't critical-- I've resolved the issue, but want to know if I need to be doing something else or alert you to the issue [14:48] xnox: thanks for looking at the logs [15:00] jdstrand, xnox looking [16:17] Daviey, responded on that bug to your questions === SpamapS is now known as Spam === Spam is now known as Maps === Maps is now known as CannedMeat === CannedMeat is now known as SpamapS [19:25] slangasek: fyi arges and I are working on the SRU queues since he missed yesterday [19:26] bdmurray: ah, ok [19:26] in case you start in... [19:31] oops, forgot queuebot [19:32] queuebot: Hi, we've missed you. [19:43] slangasek: there is something that looks like a MRE for juju-core in the saucy queue. Has the tech board talked about this at all? [19:43] bdmurray: no; https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions has been kept up-to-date [19:44] slangasek: okay [19:46] and the principle of MREs is that we don't need to do per-change SRU validation because upstream already QAs for us... I'm not sure I see why, for a project Canonical is upstream for, we wouldn't just do the QAing directly in the SRU process [19:47] What does an MRE for juju-core even mean, when most of it isn't even in the archive? :/