[10:30] <Riddell> 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] <mlankhorst> port it ;-)
[10:38] <Riddell> wibble
[10:51] <cjwatson> Riddell: please can we stop building mplayerthumbs on arm64 if it's uninstallable, then
[10:51] <cjwatson> and actually not sure that port would be terribly hard ... I think it might just be configure nonsense?
[10:52] <cjwatson> 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] <Riddell> cjwatson: mm yes we could just not build it you're right
[11:10] <cjwatson> Riddell: I think it might not be hard to do a minimal port at this point, so please hold off a bit?
[11:10] <cjwatson> Riddell: I'll let you know if I give up :)
[11:11] <Riddell> cjwatson: gotcha
[11:46] <cjwatson> Riddell: uploaded mplayer
[11:46] <Riddell> oh nice, thanks cjwatson
[12:51] <jamespage> please could I get a release team ack on #1 of bug 1287147
[12:51] <ubot2> Launchpad bug 1287147 in juju-core (Ubuntu Trusty) "[FFe] juju-core 1.18/2.0" [High,New] https://launchpad.net/bugs/1287147
[12:51] <jamespage> its not a stable release but it does move the version we have in 14.04 forwards and fixes some key bugs.
[13:17] <pitti> hello
[13:17] <pitti> any chance someone could ack the postgresql SRUs for all stables? (bug 1294006)
[13:17] <ubot2> 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] <pitti> it's just a formality, it's got a MRE and has been done countless times already
[13:18] <pitti> 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
[14:02] <jamespage> Daviey, around? could you take a look at #1 on bug 1287147
[14:02] <ubot2> Launchpad bug 1287147 in juju-core (Ubuntu Trusty) "[FFe] juju-core 1.18/2.0" [High,New] https://launchpad.net/bugs/1287147
[14:04] <Daviey> jamespage: ok
[14:04] <jamespage> Daviey, thanks :-)
[14:31] <jdstrand> 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)
[14:31] <jdstrand> I fixed the issue, but wondered why apparmor migrated
[14:40] <xnox> jdstrand: inspecting the logs http://paste.ubuntu.com/7130902/
[14:40] <xnox> jdstrand: click-apparmor, lxc, apparmor-easyprof-ubuntu autopackage tests did run and finish successfully.
[14:40] <xnox> jdstrand: from britney's point of view.
[14:40] <xnox> jdstrand: from logs at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses/2014-03-20/
[14:41] <jdstrand> xnox: that is probably for ubuntu2, which was the fix I uploaded
[14:41] <jdstrand> xnox: ubuntu1 is what had the issue
[14:41] <jdstrand> https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-apparmor-easyprof-ubuntu/
[14:41] <jdstrand> #11 in the build history
[14:41] <xnox> jdstrand: the logs i pasted to you are 2.8.0-0ubuntu38 -> 2.8.95~2430-0ubuntu1 from britney
[14:41] <jdstrand> hmm
[14:42] <jdstrand> that is weird cause jenkins gave me failure emails, is in red, says fail all over
[14:42] <xnox> from yesterday 22:45:10 UTC -> 23:28:17 UTC
[14:42] <jdstrand> Test Result (4 failures / +4)
[14:42] <xnox> jdstrand: hm, chase up with jibel probably -> Do you have any other logs for above post-mortem?
[14:43] <jdstrand> all the jenkins ones seem to be there
[14:44] <jdstrand> 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] <jdstrand> jibel: I was curious why
[14:45] <jdstrand> jibel: also note, click-apparmor autopkgtest failed in the same way
[14:45] <xnox> 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] <jdstrand> 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] <jdstrand> 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] <jdstrand> xnox: thanks for looking at the logs
[15:00] <jibel> jdstrand, xnox looking
[16:17] <jamespage> Daviey, responded on that bug to your questions
[19:25] <bdmurray> slangasek: fyi arges and I are working on the SRU queues since he missed yesterday
[19:26] <slangasek> bdmurray: ah, ok
[19:26] <bdmurray> in case you start in...
[19:31] <stgraber> oops, forgot queuebot
[19:32] <infinity> queuebot: Hi, we've missed you.
[19:43] <bdmurray> 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] <slangasek> bdmurray: no;  https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions has been kept up-to-date
[19:44] <bdmurray> slangasek: okay
[19:46] <slangasek> 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] <infinity> What does an MRE for juju-core even mean, when most of it isn't even in the archive? :/