[06:11] -queuebot:#ubuntu-release- New: accepted libbluray [amd64] (zesty-proposed) [1:1.0.0-2]
[06:11] -queuebot:#ubuntu-release- New: accepted libbluray [armhf] (zesty-proposed) [1:1.0.0-2]
[06:11] -queuebot:#ubuntu-release- New: accepted libbluray [powerpc] (zesty-proposed) [1:1.0.0-2]
[06:11] -queuebot:#ubuntu-release- New: accepted libbluray [s390x] (zesty-proposed) [1:1.0.0-2]
[06:11] -queuebot:#ubuntu-release- New: accepted libbluray [arm64] (zesty-proposed) [1:1.0.0-2]
[06:11] -queuebot:#ubuntu-release- New: accepted libbluray [ppc64el] (zesty-proposed) [1:1.0.0-2]
[06:11] -queuebot:#ubuntu-release- New: accepted libbluray [i386] (zesty-proposed) [1:1.0.0-2]
=== maclin1 is now known as maclin
[09:16] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90ubuntu0.3 => 0.90ubuntu0.4] (desktop-core, ubuntu-server)
[09:18] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (yakkety-proposed/main) [0.92ubuntu1.2 => 0.92ubuntu1.3] (desktop-core, ubuntu-server)
=== shadeslayer_ is now known as shadeslayer
[11:37] <Laney> soooooooooooo
[11:37] <Laney> thoughts on uploading a huge packaging overhaul for glib2.0 to zesty? https://ftp-master.debian.org/new/glib2.0_2.51.4-1.html
[11:41] <apw> Laney, uggg, i guess it is at least a bit verifyable, could we throw that source in a PPA ?
[11:42] <Laney> yeh
[11:43] <apw> Laney, that page is rather nice
[11:44] <Laney> apw: you mean debian's NEW output?
[11:44] <apw> Laney, yeah
[11:45] <Laney> nod
[11:45]  * Laney gets a silo to have a handy devirt ppa
[11:45] <Laney> is devirt a thing any more?
[11:46] <Laney> I mean 'restricted arches' I think :)
[11:47] <xnox> Laney, one needs devirt for power and s390x i think
[11:47] <Laney> xnox: I just mean that 'devirt' isn't the right term, since there's no 'virt' any more
[11:47] <cjwatson> uh
[11:47] <apw> Laney, i don't think devirt is really a thing.  yes power and s390x are non-virtualised
[11:47] <apw> but from a PPA point of view you just find it hard to turn them on
[11:47] <cjwatson> devirt is a thing, but it's only relevant for the arches that don't have virt
[11:48]  * xnox likes cdbs -> dh
[11:48] <cjwatson> we don't at present have arches with both virt and non-virt builders
[11:48] <Laney> right
[11:48] <cjwatson> but one of the knobs you need to get powerpc and s390x builds is to disable "Require virtualized builders"
[11:48] <apw> cjwatson, so i can in theory flip a PPA from "virt amd64" to "de-virt amd64" ?
[11:49] <cjwatson> apw: I doubt you can, but one can; however it does nothing
[11:49] <apw> cjwatson, i stand corrected :)
[11:49] <cjwatson> the technical effect of devirt (i.e. disabling "Require virtualized builders") is that builds can be dispatched to either virt or non-virt builders, rather than just virt builders
[11:50] <cjwatson> this obviously does nothing if there are no non-virt builders :)
[11:50] <apw> shows how the UI can misslead you :)  given we now only have "on/off" for every arch
[11:50] <cjwatson> but a PPA with powerpc and s390x enabled won't have anywhere to dispatch builds to unless "Require virtualized builders" is also disabled
[11:50] <apw> (we == not you :)
[11:51] <cjwatson> well, the powerpc and s390x checkboxes are greyed out if you don't have access to enable them, too
[11:51] <apw> right indeed, which is how we've fallen into calling them "restricted arches"
[11:51] <apw> (incorrectly)
[11:51] <cjwatson> no, that's correct too
[11:52] <cjwatson> slightly different from "requires devirt" mind
[11:52] <cjwatson> it's possible for an architecture to have only virt builders but still be restricted (which we do if we're not yet confident enough in how well it will behave at scale)
[11:52] <cjwatson> that was the case for arm64 and armhf for a while I believe
[11:53] <cjwatson> it does confuse webops from time to time though - they frequently get asked to enable s390x or whatever, flip the arch switch, and forget / don't know that they need to devirt as well
[11:54] <Laney> apw: xnox: building https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2537/+packages
[12:01] <apw> Laney, in theory we now have that i386 linux regression test disabled correctly, so i am going to un-blacklist it
[12:01] <Laney> apw: have you done a test run? :-)
[12:02] <Laney> not required, but if not then please keep an eye on the first real one
[12:09] <apw> Laney, i have not, will do
[12:33] <jbicha> good morning, could the chrome-gnome-shell/trusty, ubuntu-gnome-meta/trusty SRUs be reviewed today?
[12:47] -queuebot:#ubuntu-release- Unapproved: accepted chrome-gnome-shell [source] (trusty-proposed) [8-2ubuntu4~ubuntu14.04.2]
[12:57] <jbicha> thanks!
[12:57] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (trusty-proposed) [0.32.1]
[12:57] <apw> jbicha, ^
[12:59] -queuebot:#ubuntu-release- Unapproved: accepted cifs-utils [source] (yakkety-proposed) [2:6.5-2ubuntu2]
[13:00] -queuebot:#ubuntu-release- Unapproved: accepted cifs-utils [source] (xenial-proposed) [2:6.4-1ubuntu1.1]
=== maclin1 is now known as maclin
[14:02] <jbicha> rbasak: so if the final decision is not to accept bug 1337898 into trusty-updates, how does that work? is the update deleted from trusty-proposed or does it stay there indefinitely?
[14:02] <ubot5> bug 1337898 in giflib (Ubuntu Trusty) "Invalid symlinks for libungif.so and libungif.a" [Low,Fix committed] https://launchpad.net/bugs/1337898
[14:03] <rbasak> jbicha: we'll mark it verification-failed, and an AA will delete it from trusty-proposed eventually.
[14:03] <apw> if nothing else is done it will get deleted at 105 days
[14:04] <apw> if we know it is definatly going to be rejected, then a heads up here seems reasonable if you need an AA for that
[14:04] <jbicha> I'm asking because I think the tracker/yakkety SRU just has too much regression risk
[14:04] <apw> risk makes us nurvous
[14:05] <jbicha> the tracker update is in stretch and zesty and it's a "security" update but I think the sandbox still blocks and breaks some things that worked before
[14:06] <jbicha> given yakkety's short life, it doesn't seem worth the trouble there
[15:24] <jbicha> apw: since you're an AA, do you want to remove tracker from yakkety-proposed now?
[15:37] <apw> jbicha, if you are never going to fix the regression that that had, sure
[15:43] <apw> jbicha, gone
[15:46] <acheronuk> apw: now a calligra KF5 version with localisation in the main source is through, could the old defunct localisation binaries and their source be removed from zesty please?
[15:47] <acheronuk> http://packages.ubuntu.com/source/zesty/calligra-l10n
[15:47] <acheronuk> can do a bug if required
[15:48] <apw> acheronuk, is there a removal request filed for that with the details ?
[15:48] <acheronuk> I will make one :)
[15:50] -queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.9 => 1:2.5+dfsg-5ubuntu10.10] (ubuntu-server, virt) (sync)
[16:36] <powersj> slangasek: infinity: do either of you know if the ppc64el server ISO tests ever got enabled to block release on failure like amd64/i386?
[16:49] -queuebot:#ubuntu-release- New source: ukui-session-manager (zesty-proposed/primary) [1.0.0]
[17:05] <acheronuk> apw: if you are still about: https://bugs.launchpad.net/ubuntu/+source/calligra-l10n/+bug/1670426
[17:05] <ubot5> Ubuntu bug 1670426 in calligra-l10n (Ubuntu) "Please remove calligra-l10n from zesty" [Undecided,New]
=== maclin1 is now known as maclin
[17:28] -queuebot:#ubuntu-release- Unapproved: rejected neutron [source] (yakkety-proposed) [2:9.2.0-0ubuntu1]
[17:28] <rbasak> coreycb: ^
[17:29] <coreycb> rbasak, thanks
[18:03] <apw> acheronuk, it seems some of that is still seeded in "kbuntu: supported"
[18:03] <apw> acheronuk, so i think your images will implode if i remove it
[18:05] <acheronuk> apw: that probably needs to come off then
[18:05] <acheronuk> apw: no, nothing calligra at all goes on our iso
[18:08] <apw> acheronuk, seeded-in-ubuntu say it is in your supported seed.
[18:08] <apw> whatever you use that for
[18:10] <acheronuk> apw: that supported seed it not what goes on our iso. the desktop one is
[18:11] <apw> acheronuk, right i am not communicating clearly.  can you check your seeds do not need these removing
[18:11] <apw> before i rip them out of the archive
[18:13] <acheronuk> apw: it only exists in our supported seed - where it can be removed from once it no longer exists in the archive
[18:13] <apw> acheronuk, ack thanks
[18:13] <acheronuk> or before. won't break anything wither way
[18:19] <apw> acheronuk, done
[18:19] <acheronuk> apw: thx :)
[19:29] -queuebot:#ubuntu-release- Unapproved: neutron (yakkety-proposed/main) [2:9.1.1-0ubuntu1 => 2:9.2.0-0ubuntu1] (openstack, ubuntu-server)
[21:37] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-0ubuntu1~16.04.2 => 0.7.9-48-g1c795b9-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[21:41] -queuebot:#ubuntu-release- Unapproved: cloud-init (yakkety-proposed/main) [0.7.9-0ubuntu1~16.10.1 => 0.7.9-48-g1c795b9-0ubuntu1~16.10.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[22:08] -queuebot:#ubuntu-release- Unapproved: software-properties (xenial-proposed/main) [0.96.20.5 => 0.96.20.6] (desktop-core, ubuntu-server)
[22:17] -queuebot:#ubuntu-release- Unapproved: software-properties (yakkety-proposed/main) [0.96.24.7 => 0.96.24.7.1] (desktop-core, ubuntu-server)