[00:00] -queuebot:#ubuntu-release- Unapproved: gnome-devel-docs (yakkety-proposed/universe) [3.22.0-1 => 3.22.1-0ubuntu1] (desktop-extra)
[00:02] <tsimonq2> sarnold: around? I'd like to get bug 1630700 fast-tracked through
[00:03] -queuebot:#ubuntu-release- Unapproved: ansible (xenial-proposed/universe) [2.0.0.2-2 => 2.0.0.2-2ubuntu1] (no packageset)
[01:15] <infinity> wgrant: If a custom kernel will get us over the hump Right Now, let's do it.
[01:15] <infinity> wgrant: Agreed it's a terrible long-term solution, but not being able to build things we want on images today is also pretty ungood.
[01:17] <wgrant> infinity: Absolutely.
[01:17] <infinity> wgrant: Other than kernel build time, which I'm intimately familiar with, what kind of turnaround could we get on that?
[01:18] <wgrant> infinity: Soon™
[01:18] <infinity> (And said kernel could be neutered in debian/rules to exit 1 on DPKG_BUILD_ARCH != arm64, arm64 actually builds pretty fast compared to most)
[01:18] <infinity> Err, HOST_ARCH.
[01:18] <infinity> Though either would work in a non-cross env. :P
[01:20] <wgrant> infinity: We can get new images out in less than half an hour one the packages are available.
[01:20] <wgrant> Usually well less than half an hour, now that arm64 VMs aren't silly :)
[01:21] -queuebot:#ubuntu-release- Unapproved: linux-meta-snapdragon (xenial-security/universe) [4.4.0.1030.22 => 4.4.0.1030.22] (kernel) (sync)
[01:22] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta-snapdragon [sync] (xenial-security) [4.4.0.1030.22]
[01:23] <infinity> wgrant: Need any help wrangling kernel packaging, or are you good there?
[01:23] <wgrant> infinity: I'm reasonably competent, particularly when not changing ABI :)
[01:23] -queuebot:#ubuntu-release- Unapproved: rejected linux-meta-snapdragon [sync] (xenial-security) [4.4.0.1030.22]
[01:23] <infinity> wgrant: Heh.  When not changing ABI, the best trick is to append to the current changelog entry and NOT MAKE A NEW ONE.
[01:23] <infinity> Then no ABI checker invoked, and magic.
[01:24] <wgrant> Precisely.
[01:24] <infinity> wgrant: Right, then I'll keep out of your hair.
[01:24] <wgrant> It took me a couple of years to work that hack out.
[01:24] <infinity> wgrant: Lemme know when you think it's ready for a spin, and I'll lob things at it.
[01:25] <infinity> I should be up for a Very Long While still.
[01:25] <infinity> In the process of reversing my clock.
[01:25] <infinity> Well, inverting, not reversing.
[01:25] <wgrant> infinity: It'll be a good while, currently in a couple of meetings.
[01:25] <wgrant> Though hopefully wrapping up now, then will get onto it properly.
[01:25] <infinity> wgrant: All good.  I intend to be awake all through London work day.
[01:25] <infinity> wgrant: TO set a trend for the rest of the week.
[01:26] <infinity> How I plan to do this, given that I woke up at 7am Calgary time, I'm not yet sure.
[01:26] <infinity> But I suspect caffeine might come into play.
[01:29] -queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu481 => 20101020ubuntu482] (core)
[01:30] <tsimonq2> infinity: Staying on UK time zones are fun, I did that over my summer vacation for a few weeks. :P
[01:30] <infinity> tsimonq2: I do it all the time, but it's always harder to shift one's clock on purpose rather than by accident. :P
[01:31] <tsimonq2> infinity: I can agree with that.
[01:31] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (yakkety-proposed) [20101020ubuntu482]
[01:31] -queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (yakkety-proposed) [1:45.3.0+build1-0ubuntu2]
[01:32] -queuebot:#ubuntu-release- Unapproved: accepted gnome-devel-docs [source] (yakkety-proposed) [3.22.1-0ubuntu1]
[01:34] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-340 [source] (yakkety-proposed) [340.98-0ubuntu1]
[01:46] <cyphermox> infinity: logging off for some sleep. use ancient communication methods should you really need me for some reason.
[01:47] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Yakkety Final] has been updated (20161011)
[01:47] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Yakkety Final] has been updated (20161011)
[02:30] -queuebot:#ubuntu-release- Builds: Netboot amd64 [Yakkety Final] (20101020ubuntu482) has been added
[02:30] -queuebot:#ubuntu-release- Builds: Netboot arm64 [Yakkety Final] (20101020ubuntu482) has been added
[02:30] -queuebot:#ubuntu-release- Builds: Netboot armhf [Yakkety Final] (20101020ubuntu482) has been added
[02:30] -queuebot:#ubuntu-release- Builds: Netboot i386 [Yakkety Final] (20101020ubuntu482) has been added
[02:31] -queuebot:#ubuntu-release- Builds: Netboot powerpc [Yakkety Final] (20101020ubuntu482) has been added
[02:31] -queuebot:#ubuntu-release- Builds: Netboot ppc64el [Yakkety Final] (20101020ubuntu482) has been added
[02:31] -queuebot:#ubuntu-release- Builds: Netboot s390x [Yakkety Final] (20101020ubuntu482) has been added
[03:47] <apw> cjwatson, normally in 64bit all of physical memory is "direct mapped" so if the h/w is using a large physical space then we will chew a large chunk of KVA for the direct map
[03:50] <apw> still not clear as to why that is visible in userspace in any sense
[06:01] -queuebot:#ubuntu-release- New sync: openfoam (yakkety-proposed/primary) [4.0+dfsg1-3]
[06:12] -queuebot:#ubuntu-release- Unapproved: python3.6 (yakkety-proposed/universe) [3.6.0~b1-1ubuntu2 => 3.6.0~b2-1] (no packageset)
[06:13] -queuebot:#ubuntu-release- Unapproved: accepted python3.6 [source] (yakkety-proposed) [3.6.0~b2-1]
[06:18] -queuebot:#ubuntu-release- New: accepted linbox [arm64] (yakkety-proposed) [1.4.2-1~build1]
[06:18] -queuebot:#ubuntu-release- New: accepted linbox [i386] (yakkety-proposed) [1.4.2-1~build1]
[06:19] -queuebot:#ubuntu-release- New: accepted linbox [armhf] (yakkety-proposed) [1.4.2-1~build1]
[06:19] -queuebot:#ubuntu-release- New: accepted linbox [ppc64el] (yakkety-proposed) [1.4.2-1~build1]
[08:19] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-304 (yakkety-proposed/restricted) [304.131-0ubuntu5 => 304.132-0ubuntu1] (ubuntu-desktop)
[09:15] <pitti> infinity, apw: I'm going to kill the currently running linux tests again, as they still keep breaking the testbed and are stuck in an eternal retry loop;  but I'll try to collect the console-log this time
[09:27] <pitti> apw: filed bug 1632252 with some logs/details
[09:27] <pitti> apw: sounds like sshd gets OOM-killed
[09:52] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Yakkety Final] has been updated (20161011)
[09:52] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop i386 [Yakkety Final] has been updated (20161011)
[09:52] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop powerpc [Yakkety Final] has been updated (20161011)
[09:55] -queuebot:#ubuntu-release- Unapproved: update-manager (yakkety-proposed/main) [1:16.10.6 => 1:16.10.7] (core)
[09:56] <pitti> infinity, slangasek: ^ this drops the hard python3-launchpadlib dependency again (from http://launchpadlibrarian.net/275354292/update-manager_1%3A16.10.2_1%3A16.10.3.diff.gz) and adds a graceful fallback
[09:56] <pitti> this should clean up most of http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
[10:03] <cjwatson> which will mean that the PPA changelog handling randomly doesn't work for users depending on whether they happen to have python3-launchpadlib installed?
[10:04] <cjwatson> I mean, I guess I see why you're doing it, but avoiding this was why I asked in review of that feature for it to be just made a dependency rather than conditional
[10:04] <pitti> cjwatson: I'd rather seed python3-launchpadlib on desktop then, TBH
[10:05] <pitti>  maybe the feature can also be reworked to do a single REST call via urllib, but I don't want to do this "under the gun"
[10:05] <cjwatson> pitti: seeding in desktop seems like a reasonable compromise, if people are OK with that
[10:05] <pitti> it doesn't do anything authenticated, so I guess getting a changelog with plain urllib should be fairly easy
[10:05] <cjwatson> maybe as a Recommends
[10:05] <pitti> *nod*
[10:06] <pitti> not sure who has the last word on that, but I'm happy to make the seed changes and update ubuntu-meta if we want to go ahead with this
[10:06] <cjwatson> It should be relatively easy to redo by-hand without lplib, indeed
[10:06] <cjwatson> One problem with seeding in desktop is, which desktops
[10:08] <pitti> hm -- how about we move the Depends: to update-manager?
[10:08] <pitti> (it previously was on python3-update-manager which is in standard)
[10:08] <pitti> update-manager is optional
[10:09] <pitti> then we don't need seed changes, and this conceptually sounds "more correct"
[10:09] <pitti> and to u-m-kde
[10:10]  * pitti self-rejects and reuploads, that's better than fiddling with seeds
[10:10] <cjwatson> Seems reasonable if you retain the optionality in the code
[10:11] <cjwatson> This is how to do what u-m does by hand:
[10:11] <cjwatson> $ curl -s 'https://api.launchpad.net/devel/archives?ws.op=getByReference&reference=%7Ecjwatson/ubuntu/ppa' | jq .self_link
[10:11] <cjwatson> "https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa"
[10:11] <cjwatson> $ curl -s 'https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa?ws.op=getPublishedSources&source_name=ant&exact_match=true&version=1.9.7-3ppa1' | jq '.entries[0].self_link'
[10:11] -queuebot:#ubuntu-release- Unapproved: rejected update-manager [source] (yakkety-proposed) [1:16.10.7]
[10:11] <cjwatson> "https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa/+sourcepub/6712285"
[10:11] <cjwatson> $ curl -s 'https://api.launchpad.net/devel/~cjwatson/+archive/ubuntu/ppa/+sourcepub/6712285?ws.op=changelogUrl' | jq
[10:11] <cjwatson> "https://launchpad.net/~cjwatson/+archive/ubuntu/ppa/+sourcepub/6712285/+files/changelog"
[10:11] <cjwatson> but you do have to make sure that all the quoting is correct
[10:12] <pitti> yeah, TBH that sounds more like a z thing
[10:12] <cjwatson> https://api.launchpad.net/devel/archives is a hardcoded base, and all of reference, source_name, and version are inputs that must be URL-escaped
[10:13] <cjwatson> Easy enough, but yeah, can be done in z
[10:14] <cjwatson> (Do we have a name yet?)
[10:15] <pitti> for the Zealous Zombie?
[10:16] <Odd_Bloke> Zenial Zebra.
[10:16] -queuebot:#ubuntu-release- Unapproved: update-manager (yakkety-proposed/main) [1:16.10.6 => 1:16.10.7] (core)
[10:17] <acheronuk> some have been guessing at Zazzy Zorilla
[10:17] <pitti> infinity, slangasek: ^ updated update-manager as per discussion with cjwatson; this is now self-contained (does not need seed changes)
[10:18] <pitti> I think we can drop xml-core's Depends: perl, to clean up that from "standard" as well (only using modules from perl-base); will confirm and then upload/file Debian bug
[10:19] <pitti> with these two, the remaining priority-mismatch items should be valid
[10:20] <cjwatson> acheronuk: Yeah, I'm ignoring guesses because they're ~never right
[10:21] <cjwatson> pitti: the changelog seems a bit wrong now?
[10:21] <cjwatson> pitti: wait, maybe I'm suffering from caching
[10:21] <pitti> cjwatson: ah, it should probably say "lower .. from python3-update-manager's Depends"?
[10:22] <pitti> cjwatson: http://launchpadlibrarian.net/289188605/update-manager_16.10.7_source.changes is the current version that I uploaded
[10:22] <cjwatson> no, I'm OK with it once I avoid looking at the old cached version
[10:22] <cjwatson> (but am no longer release team, so not accepting)
[10:24] <acheronuk> cjwatson: yep, my guess always seems wrong
[10:54] -queuebot:#ubuntu-release- Unapproved: xml-core (yakkety-proposed/main) [0.15 => 0.15ubuntu1] (core)
[10:55] <pitti> ^ will fix the perl priority-mismatches. This was a recent regression from https://anonscm.debian.org/git/debian-xml-sgml/xml-core.git/commit/?id=fed34e0
[10:56] <pitti> i. e. accidentally dropping the dh_perl -d option
[10:56] <pitti> (also filed as Debian bug 840410)
[10:56] <pitti> Laney: ^ as this is quite straightforward, mind reviewing/accepting this?
[10:57] <pitti> reviewing u-m is also appreciated of course, to clean up most of priority-mismatches so that we can get it release-ready
[11:06] <Laney> pitti: sure
[11:13] <tsimonq2> cjwatson: I'm still voting for Zealous Zebu :P
[11:13] <tsimonq2> s/voting/hoping/
[11:16] <acheronuk> tsimonq2: lol. you changed your mind AGAIN?
[11:17] <tsimonq2> acheronuk: no I only said Zazzy Zorilla because I thought Barry Warsaw leaked the codename, turns out he made it up... :P
[11:18] <acheronuk> tsimonq2: I swear there is a subtle disinformation plot by canonical each year to keep the real one under wraps
[11:19] -queuebot:#ubuntu-release- Unapproved: accepted xml-core [source] (yakkety-proposed) [0.15ubuntu1]
[11:19] <tsimonq2> acheronuk: cjwatson linked me to a graph yesterday...
[11:20]  * tsimonq2 finds it
[11:20] <tsimonq2> acheronuk: http://people.canonical.com/~cjwatson/tmp/release-name-notice.png
[11:22] <acheronuk> interesting
[11:32] <Laney> pitti: unorthodox syntax on Suggests there
[11:32]  * Laney built it to check it works (it does)
[11:33]  * rbasak believes he predicted Yakkety Yak before it was named
[11:33] <rbasak> Though in hindsight it was obvious I guess
[11:33] <Laney> and argh at all the trailing spaces in update-manager/d/control
[11:34] <Laney> (not new)
[11:35] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (yakkety-proposed) [1:16.10.7]
[11:44] -queuebot:#ubuntu-release- Unapproved: budgie-desktop (yakkety-proposed/universe) [10.2.7-2 => 10.2.7-3] (no packageset) (sync)
[11:44] -queuebot:#ubuntu-release- Unapproved: accepted budgie-desktop [sync] (yakkety-proposed) [10.2.7-3]
[11:46] <pitti> Laney: you mean trailling commas?
[11:47] <pitti> Laney: trailing spaces> yeah, my vim loudly complains too, but minimal diff for review, etc.
[11:49] <Laney> pitti: It's like
[11:49] <Laney> Suggests:
[11:49] <Laney>           python3-...
[11:57] -queuebot:#ubuntu-release- Unapproved: congress (yakkety-proposed/universe) [4.0.0~rc1+dfsg1-1 => 4.0.0+dfsg1-2] (no packageset) (sync)
[11:57] -queuebot:#ubuntu-release- Unapproved: accepted congress [sync] (yakkety-proposed) [4.0.0+dfsg1-2]
[12:31] -queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0~rc3-0ubuntu2.16.10.1 => 2.0~rc3-0ubuntu3.16.10.1] (ubuntu-server)
[12:32] <cyphermox> good morning
[12:33] <pitti> Laney: oh, oops
[12:33] <pitti> Laney: fixed in bzr
[12:33] <pitti> hey cyphermox
[12:34] -queuebot:#ubuntu-release- Unapproved: designate-dashboard (yakkety-proposed/universe) [3.0.0~rc1-1 => 3.0.0-2] (no packageset) (sync)
[12:35] -queuebot:#ubuntu-release- Unapproved: accepted designate-dashboard [sync] (yakkety-proposed) [3.0.0-2]
[12:36] -queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (yakkety-proposed) [2.0~rc3-0ubuntu3.16.10.1]
[12:37] <pitti> apw: do you know about the fate of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux ?
[12:37] <pitti> I suppose we should release that RSN so that we can rebuild images?
[12:41] <apw> pitti as far as i can tell it is as good as the previous one, so i guess as those tests are not going to ever come in we'll need to hint it
[12:43] <pitti> apw: oh right -- I was blindly assuming they would use a tracking bug
[12:43] <pitti> apw: hinting
[12:45] <pitti> seb128, jbicha: do we want to let bug 1631955 into yakkety, or remain as an SRU?
[12:46] <pitti> (seb128, jbicha: we still have a kernel and two other packages to land before respinning images)
[12:46] <seb128> pitti, letting jbicha comment, I didn't look at this update
[12:46] <seb128> pitti, we don't plan respins after that?
[12:47] <pitti> seb128: I don't know; just saying that the current images can't possibly be final
[12:47] <seb128> pitti, it's a bit suboptimal that we have the current firefox blocked in proposed but I guess it is what it is now?
[12:47] <seb128> k
[12:47] <pitti> seb128: well, firefox is FTBFS, not much that we can do other than fixing it
[12:48] <pitti> but that's fine as an SRU
[12:48] <seb128> not optimal though
[12:49] <seb128> there might be some security issues in the previous verison
[12:49] <seb128> oh, also that's using an google api key that we revocated
[12:49] <seb128> the new key was added in https://launchpad.net/ubuntu/+source/firefox/49.0+build4-0ubuntu1
[12:49] <pitti> well, if we have a fix now/today, I'm sure everyone would be happy to get it in :)
[12:49] <seb128> chrisccoulson, ^
[12:50] <seb128> pitti, or we could declared firefox unsupported on ppc64el like it is on powerpc and s390x and delete the binaries like we did for those...
[12:51] <chrisccoulson> I don't think I'll be able to spend time investigating a ppc64el-specific startup crash in Firefox tbh
[12:51] <jbicha> pitti: I'm ok with letting e-d-s in now, it worked fine for me
[12:51] <chrisccoulson> (which is what the build failure is)
[12:51] <jbicha> the new e-d-s apparently doesn't actually fix the google authentication problem
[12:54] <jbicha> I guess we can point ppc users to epiphany? since chromium isn't supported there either
[12:58] -queuebot:#ubuntu-release- Unapproved: python-pycadf (yakkety-proposed/main) [2.2.0-2 => 2.4.0-1] (ubuntu-server) (sync)
[13:11] <chrisccoulson> seb128, have you used firefox in proposed btw?
[13:11] <seb128> chrisccoulson, not really, but I can give it a try if you want ... anything in particular?
[13:11] <seb128> chrisccoulson, did you see the ping from rico early on ubuntu-devel btw?
[13:12] <chrisccoulson> seb128, well, I just thought - the build in the release pocket is now so ancient that it was built with the old compiler
[13:12] <chrisccoulson> I didn't see a ping earlier, let me check
[13:13] <seb128> chrisccoulson, it was at 8:25 u.k
[13:13] <chrisccoulson> ahh
[13:13] <chrisccoulson> so, firefox has the same issue as https://bugs.chromium.org/p/v8/issues/detail?id=3782 which already affected chromium and oxide
[13:14] <chrisccoulson> Firefox really needs a maintainer that cares about it ;)
[13:17] <chrisccoulson> oh, apparently firefox doesn't have this problem, and the bug ricotz linked is thunderbird specific
[13:22] <jbicha> chrisccoulson: I've been using firefox from y/proposed for several days and it seems ok
[13:35] <apw> and the one from release is dire :/
[13:42] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-3.5 (yakkety-proposed/universe) [1:3.5.2-3ubuntu1 => 1:3.5.2-5] (no packageset) (sync)
[13:43] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-3.5 [sync] (yakkety-proposed) [1:3.5.2-5]
[14:02] <balloons> pitti, nothing is running in autopkgtest?
[14:07] -queuebot:#ubuntu-release- Unapproved: xfsprogs (yakkety-proposed/main) [4.3.0+nmu1ubuntu2 => 4.3.0+nmu1ubuntu3] (core)
[14:07] <apw> ^ fixes fallout from v4.8 kernel headers ...
[14:14] <davmor2> cyphermox: how are we looking for the new shim do you know anything yet?
[14:30] -queuebot:#ubuntu-release- Unapproved: openorienteering-mapper (yakkety-proposed/universe) [0.6.3-2build1 => 0.6.5-1] (no packageset) (sync)
[14:31] -queuebot:#ubuntu-release- Unapproved: accepted openorienteering-mapper [sync] (yakkety-proposed) [0.6.5-1]
[14:36] <pitti> balloons: no, we are in freeze :)
[14:37] <pitti> balloons: juju is, actually (i386 and amd64 failed already)
[14:37] -queuebot:#ubuntu-release- Unapproved: gdb (yakkety-proposed/main) [7.11.90.20161005-0ubuntu1 => 7.12-0ubuntu1] (core)
[14:37] <balloons> pitti, right it was of course what I was looking for. I saw amd64 failed, but I can't see the log proper until it finishes -- unless there's something I don't know
[14:38] -queuebot:#ubuntu-release- New: accepted openfoam [sync] (yakkety-proposed) [4.0+dfsg1-3]
[14:39] <cyphermox> davmor2: sorry, no news to be given
[14:40] <pitti> apw: xfsprogs> cheers! is that an upstream backport?
[14:41] -queuebot:#ubuntu-release- Unapproved: accepted xfsprogs [source] (yakkety-proposed) [4.3.0+nmu1ubuntu3]
[14:41] <apw> pitti, no that is allll me
[15:04] -queuebot:#ubuntu-release- Unapproved: accepted gdb [source] (yakkety-proposed) [7.12-0ubuntu1]
[15:04] -queuebot:#ubuntu-release- Unapproved: vlan (xenial-proposed/main) [1.9-3.2ubuntu1 => 1.9-3.2ubuntu1.16.04.1] (core)
[15:05] -queuebot:#ubuntu-release- Unapproved: vlan (precise-proposed/main) [1.9-3ubuntu6 => 1.9-3ubuntu6.1] (kubuntu, netbook, ubuntu-desktop, ubuntu-server, unr)
[15:05] -queuebot:#ubuntu-release- Unapproved: vlan (trusty-proposed/main) [1.9-3ubuntu10 => 1.9-3ubuntu10.1] (core)
[15:16] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (yakkety-proposed/partner) [1:20160913.1-0ubuntu1 => 1:20161011.1-0ubuntu1] (no packageset)
[15:21] <pitti> chrisccoulson, seb128: removing current ppc64el firefox binaries seems reasonable to me; Laney, infinity, opinions?
[15:22] <chrisccoulson> pitti, I should point out, we don't block firefox security updates for build failures on those 3 architectures anyway
[15:22] <chrisccoulson> And the updates are never tested on those architectures in any case
[15:23] <seb128> pitti, +1 from me, it might require to delete/tweak a bit more due to rdepends, whoever handled the drop of powerpc earlier in the cycle should know the details of what is needed though
[15:23] <pitti>  firefox | 49.0+build4-0ubuntu0.16.04.1   | xenial-security  | source, amd64, arm64, armhf, i386, ppc64el
[15:24] <pitti>  chrisccoulson: I was wondering because it apparently did build for xenial still -- gcc 6, presumably?
[15:24] <chrisccoulson> pitti, I uploaded thunderbird with a build failure fix, but I've since been made aware of https://bugzilla.mozilla.org/show_bug.cgi?id=1251576, so it won't run anyway (it's a similar issue to https://bugs.chromium.org/p/v8/issues/detail?id=3782, which we already worked around in chromium and oxide)
[15:24] <chrisccoulson> pitti, yeah, most likely
[15:25] -queuebot:#ubuntu-release- Unapproved: libreoffice (yakkety-proposed/main) [1:5.2.2-0ubuntu1 => 1:5.2.2-0ubuntu2] (kubuntu, ubuntu-desktop)
[15:25] <Laney> pitti: We forced it last time
[15:26] <pitti> Laney: you mean with a britney hint, not removing packages?
[15:26] <Laney> yep
[15:26] <pitti> that seems a bit awkward
[15:26] <Laney> why?
[15:26] <pitti> Laney: hm, does that still turn up at NBS?
[15:27] <pitti> our report doesn't show that, AFAIK it only runs for amd64
[15:28] <jbicha> Firefox shows up at the bottom of /update_output.txt
[15:28] <pitti> List of old libraries in testing (2):
[15:28] <pitti>   firefox: s390x powerpc
[15:28] <pitti> oh, this?
[15:28] <pitti> well, we really should remove the old binaries properly
[15:29]  * pitti → meeting, bbl
[15:49] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (yakkety-proposed/main) [0.92 => 0.92ubuntu1] (desktop-core, ubuntu-server)
[16:00] -queuebot:#ubuntu-release- Unapproved: python-tornado (yakkety-proposed/universe) [4.4.1-2ubuntu1 => 4.4.2-1ubuntu1] (ubuntu-desktop)
[16:01] <slangasek> pitti, balloons, stokachu: seems that juju-core is still failing autopkgtests, has this been analyzed?
[16:01] <pitti> slangasek: yes, balloons and I just debugged it
[16:01] <pitti> slangasek: ballons is preparing a new .dsc, I'll sponsor
[16:01] <balloons> slangasek, yes it's sorted. ^^
[16:01] -queuebot:#ubuntu-release- Unapproved: accepted python-pycadf [sync] (yakkety-proposed) [2.4.0-1]
[16:01] <pitti> building from bzr doesn't work (source and pristine-tar disagree), so I'll let him sort out the source build
[16:01] <balloons> and sorry pitti, re-setting up vpn to upload dsc
[16:02] <pitti> balloons: that or pastebin a debdiff if that's easier
[16:18] <lunaphyte> hi.  i'm trying to upgrade an eol install [15.04] to 15.10 [this is all just to upgrade to 16.04].  but if i'm not mistaken, the old-releases repo doesn't have packages/indexes for 15.10 published, so i'm stuck, it seems.
[16:18] <lunaphyte> however, us.archive.ubuntu.com still does.  so i'm a little confused as to how to go about upgrading.
[16:18] <wxl> lunaphyte: #ubuntu for support.
[16:19] <lunaphyte> [and, if this is the wrong channel, apologies]
[16:19] <lunaphyte> wxl: i actually came here from #ubuntu-server
[16:20] <wxl> lunaphyte: they suggested to come here? because that's strange. this channel exists to coordinate upcoming releases.
[16:20] <lunaphyte> it seems though that vivid package indexes aren't listed at old-releases, yet they should be, hence my question here
[16:20] <lunaphyte> wxl: no, they didn't suggest.  i spent time there troubleshooting, that's all.
[16:20] <wxl> lunaphyte: i'd personally advice you grab /home and maybe /etc and do a fresh install re-using those
[16:21] <lunaphyte> honestly, i'd just like to know who i can ask about 15.04 missing from old-releases
[16:24] <wxl> lunaphyte: vivid and wily are both at archive.ubuntu.com
[16:25] -queuebot:#ubuntu-release- Unapproved: accepted maas [source] (yakkety-proposed) [2.1.0~beta2+bzr5454-0ubuntu1]
[16:26] -queuebot:#ubuntu-release- Unapproved: networking-hyperv (yakkety-proposed/universe) [2.0.0-0ubuntu1 => 3.0.0-0ubuntu1] (no packageset)
[16:26] <lunaphyte> i thought since vivid is eol, it would be at old-releases.
[16:26] <wxl> it will get there eventually, i'm sure
[16:26] -queuebot:#ubuntu-release- Unapproved: accepted networking-hyperv [source] (yakkety-proposed) [3.0.0-0ubuntu1]
[16:27] <lunaphyte> inex retrieval at archive.ubuntu.com does work for vivid, yes, but upgrading fails, because it tries to upgrade to 16.04, but do-release-upgrade doesn't support it, of course.
[16:27] <wxl> so like i said, fresh install
[16:27] <lunaphyte> wxl: thanks, yeah, i guess that's my question, is what typically defines when that happens?
[16:28] <chrisccoulson> pitti, are you able to approve partner uploads?
[16:28] <lunaphyte> wxl: it's ok, i'll let the channel get back to the /topic
[16:28] <wxl> infinity: could you answer lunaphyte's question as to why vivid and wily are not in old-releases but are instead still on archive?
[16:29] <lunaphyte> hopefully my question isn't interpreted as "when will this be" - just would like to understand what the transition is based on
[16:30] <wxl> many activities in release require manual activity (for example, turning dailies on and off in response to milestone testing)
[16:30] <cjwatson> lunaphyte: Can't give you an accurate answer as to why it's not done yet (I suspect not-got-round-to-it for wily, and complicated stuff involving the Ubuntu phone codebase for vivid), but the process doc is https://wiki.ubuntu.com/EndOfLifeProcess
[16:30] <wxl> that said, sometimes they just get temporarily forgotten or put off
[16:31] <rbasak> There is no definite schedule. The EOL date is one bound.
[16:31] <wxl> tl;dr lesson learned: upgrade BEFORE EoL :)
[16:31] <lunaphyte> cjwatson: ah, thanks, that's informative
[16:31] <lunaphyte> wxl: yeah, for sure.  life sometimes has other plans, unfortunately. :)
[16:31] <lunaphyte> it's all good though.
[16:32] <apw> well before EOL of the release which follows :)
[16:32] <cjwatson> I'd probably just upgrade by frobbing sources.list and doing a dist-upgrade.
[16:32] <wxl> apw: hahahah indeed
[16:32] <cjwatson> Sure, do-release-upgrade helps, but it isn't mandatory.
[16:32] <lunaphyte> if the end result is that eventually it will make it's way to old-releases, and then the nominal eol upgrade path will work as expected, that's fine
[16:32] <rbasak> Somebody should figure out and document how to handle this better on the existing wiki page.
[16:33] <pitti> chrisccoulson: technically, yes; procedurally I have no idea what to do with them/what to check, etc.
[16:33] <lunaphyte> cjwatson: does frobbing sources.list mean switching from vivid to wily, in my case?
[16:33] <rbasak> https://help.ubuntu.com/community/EOLUpgrades
[16:36] <lunaphyte> i'm but a visitor here, but would a note somewhere there along the lines of "if you are doing an eol upgrade of a relatively recent release, it's possible that it may not work, until various transitions have fully occured - please try again later" be of any value?
[16:36] <chrisccoulson> pitti, ah. I need adobe-flashplugin approving (I've uploaded yakkety so far, I normally wait until that's approved before uploading the other releases)
[16:37] <chrisccoulson> pitti, the procedure is basically 1) approve, 2) I verify they're ok, 3) Copy to release pocket. Not sure if that helps you though :)
[16:38] -queuebot:#ubuntu-release- Unapproved: casper (xenial-proposed/main) [1.376.1 => 1.376.2] (desktop-core, ubuntu-server)
[16:38] -queuebot:#ubuntu-release- Unapproved: juju-core (yakkety-proposed/main) [2.0~rc3-0ubuntu3.16.10.1 => 2.0~rc3-0ubuntu4.16.10.1] (ubuntu-server)
[16:39] <pitti> slangasek, balloons ^ now with 10% more testing love!
[16:39] -queuebot:#ubuntu-release- Unapproved: accepted juju-core [source] (yakkety-proposed) [2.0~rc3-0ubuntu4.16.10.1]
[16:41] -queuebot:#ubuntu-release- New binary: openfoam [s390x] (yakkety-proposed/universe) [4.0+dfsg1-3] (no packageset)
[16:41] -queuebot:#ubuntu-release- Unapproved: indicator-network (yakkety-proposed/main) [0.8.0+16.10.20160930.5-0ubuntu1 => 0.8.0+16.10.20160930.5-0ubuntu2] (no packageset)
[16:41] <cjwatson> lunaphyte: Yeah
[16:41] <Laney> ^- fix for the live session
[16:45] -queuebot:#ubuntu-release- New binary: openfoam [ppc64el] (yakkety-proposed/universe) [4.0+dfsg1-3] (no packageset)
[16:45] <pitti> chrisccoulson, Laney: I removed firefox ppc64el binaries; there are also some orphaned powerpc/s390x ones from 46.0.1+build1-0ubuntu1 and 47.0+build3-0ubuntu1, cleaning those too (this is why I don't like forcing without binary removal)
[16:46] <chrisccoulson> pitti, thanks
[16:48] <lunaphyte> cjwatson: thanks.  i suppose it's not necessarily kosher/supported, but your experience has been largely successful doing that?
[16:50] <rbasak> lunaphyte: please do edit https://help.ubuntu.com/community/EOLUpgrades to make it better.
[16:50] <rbasak> (you asked about adding a note?)
[16:51] <lunaphyte> rbasak: oh, ok, will do
[16:51] <rbasak> Looks like you have to ask to join the team, but contributors are welcome
[16:51] <rbasak> https://help.ubuntu.com/community/WikiGuide
[16:51] <rbasak> That's presumably to avoid spam.
[16:51] <lunaphyte> sure, understood
[16:52] <wxl> lunaphyte: or you could just become an ubuntu member and then you don't have to worry about that at all :)
[16:52] <lunaphyte> wxl: hah!  that sounds like more responsibility :)
[16:53] <wxl> lunaphyte: not necessarily. just need to sustain relevant contributions to the project
[16:53] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (yakkety-proposed) [0.92ubuntu1]
[16:53] <rbasak> Fixing the doc sounds like a relevant but circular contribution :-)
[16:53] <wxl> !membership | lunaphyte
[16:53] <pitti> Laney: indicator-network> eek
[16:54] <lunaphyte> wxl: thanks
[16:54] <pitti> Laney: do any of the other unity8 upstart jobs now unexpectedly start in the unity7 session? it appears to me that this chagne needs to be replicated to all of those?
[16:54] <wxl> lunaphyte: i'm on the membership board if you have other questions about it
[16:54] -queuebot:#ubuntu-release- Unapproved: accepted indicator-network [source] (yakkety-proposed) [0.8.0+16.10.20160930.5-0ubuntu2]
[16:55] <cjwatson> lunaphyte: Yes, but I've been doing the general equivalent since well before Ubuntu existed so I'm not a good sample case.
[16:55] <pitti> Laney: I thought upstart had a less ugly way to do that, like start on starting DESKTOP_SESSION="unity8" or so?
[16:55] <pitti> unity-panel-service.conf:start on desktop-start DESKTOP_SESSION=ubuntu
[16:56] <pitti> Laney: ^ like this?
[16:56] <pitti> Laney: (accepted, as this is just bikeshedding, but I wonder if that affects other services too0
[16:56] <Laney> I copied it from the other job in the same source package which definitely works
[16:56] <pitti> unity-panel-service.conf:# start on started unity7
[16:56] <pitti> or even just that
[16:56] <lunaphyte> wxl: well, i really do appreciate all of the info, but if i'm honest, it's probably not in the cards for me these days.  hopefully that doesn't come across as dismissive!
[16:56] <Laney> I don't want to mess around at this point
[16:56] <lunaphyte> cjwatson: understood, thanks
[16:57] <wxl> lunaphyte: np. it will be there in the future.
[16:57] <lunaphyte> gracias
[16:57] <wxl> de nada
[16:57] <Laney> maybe you could do desktop-start DESKTOP_SESSION=... and indicator-services-start
[16:57] <Laney> Seems risky to me to experiment now
[16:58] <pitti> Laney: "start on started unity7" (like unity-panel-service.conf) seems like the equivalent of WantedBy=unity7-session.target
[16:58] <pitti> Laney: but yes, if it works, it's ok; as I said I mostly just wondered if that affects other unity8 services too
[16:59] <Laney> It's waiting for some event, not just that unity8 is started
[16:59] <Laney> and I don't know - at least I haven't heard that any of those actually crash like this one does ...
[17:00] -queuebot:#ubuntu-release- Unapproved: thunderbird (yakkety-proposed/main) [1:45.3.0+build1-0ubuntu2 => 1:45.3.0+build1-0ubuntu3] (mozilla, ubuntu-desktop)
[17:00] <Laney> I have something called indicator-transfer-service running, not sure if that's necessary or not
[17:06] <Laney> seb128 / tedg: do you know if indicator-transfer is used or useful on unity 7?
[17:06] <seb128> Laney, it's not used and probably not going to be useful
[17:06] <seb128> it's supposed to indicate ongoing downloads
[17:07] <seb128> but classic apps don't use the api to talk to it
[17:07] <seb128> so probably not that useful
[17:10] <Laney> thanks
[17:10] <Laney> I'll give it the same love, but this is lower priority
[17:14] <tumbleweed> I'm being arm twisted with beer, for some last minute universe FFes :)
[17:23] -queuebot:#ubuntu-release- Unapproved: ubiquity-slideshow-ubuntu (yakkety-proposed/main) [117 => 118] (kubuntu, ubuntu-desktop)
[17:25] -queuebot:#ubuntu-release- Unapproved: accepted thunderbird [source] (yakkety-proposed) [1:45.3.0+build1-0ubuntu3]
[17:26] -queuebot:#ubuntu-release- Unapproved: indicator-transfer (yakkety-proposed/main) [0.2+16.10.20160808.1-0ubuntu1 => 0.2+16.10.20160808.1-0ubuntu2] (no packageset)
[17:29] <slangasek> infinity, pitti: do we have a target time for the start of image respins, to guide evaluating the uploads in the queue?
[17:29] <Laney> pitti: ^- same fix - this one is "just" a waste of resources
[17:30] <slangasek> I'm a waste of resources ;(
[17:30] <Laney> urgh, there's a waste of resources in my changelog
[17:30] <infinity> slangasek: I was shooting for "very soon".  But will take another round of fixes if they don't need 4h to get through the sausage factory.
[17:31] <infinity> slangasek: I was personally waiting on the arm64 buildd kernel hack (done), and ubuntu-system-settings building successfully (in progress) and migrating.
[17:31] <infinity> I'm also curious to see what the fallout is from the firefox and thunderbird removals.
[17:32] <infinity> I bet component-mismatches explodes.
[17:32] <slangasek> infinity: what is "soon", realistically? we have maas which is currently publishing
[17:32] -queuebot:#ubuntu-release- Unapproved: indicator-transfer (yakkety-proposed/main) [0.2+16.10.20160808.1-0ubuntu1 => 0.2+16.10.20160808.1-0ubuntu2] (no packageset)
[17:32] <infinity> slangasek: After that maas, since it'll beat u-s-s to the release pocket.
[17:32] <slangasek> ok
[17:33] <infinity> slangasek: I dunno.  More than an hour, less than several.
[17:33] <infinity> I hope.
[17:34] <slangasek> infinity: it seems for some reason a gdb was accepted, which is seeded everywhere and needs 4 more hours to build on armhf
[17:34] <slangasek> (appx)
[17:34] -queuebot:#ubuntu-release- Unapproved: rejected indicator-transfer [source] (yakkety-proposed) [0.2+16.10.20160808.1-0ubuntu2]
[17:34] <infinity> slangasek: Whee.
[17:34] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-304 [source] (yakkety-proposed) [304.132-0ubuntu1]
[17:34] <slangasek> so maybe someone wants to speak up and explain why that was accepted
[17:34] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity-slideshow-ubuntu [source] (yakkety-proposed) [118]
[17:35] <slangasek> pitti: ?
[17:35] <slangasek> or Laney or apw or tumbleweed or stgraber ?
[17:36] <Laney> nope
[17:36] <slangasek> doko: or did you happen to accept this gdb yourself?
[17:36] <Laney> I accepted thunderbird though, which needs quite a while on armhf
[17:36] <Laney> Apparently the current one fails to start
[17:37] <slangasek> Laney: ah, well, thunderbird is seeded in only half the places that gdb is
[17:37] <infinity> Which is still many places. :P
[17:37] <Laney> block-all source time?
[17:37] <infinity> Not all.
[17:37] <slangasek> only ubuntu-mate, ubuntu desktop, ubuntukylin FWIW
[17:37] <infinity> But getting close to block all seeded.
[17:38] <slangasek> oh. but also ubuntustudio + xubuntu, so that's fine
[17:39] <slangasek> infinity, Laney: I suggest forcing thunderbird in before armhf is built, to unblock the image builds / tests on other archs and let armhf binaries catch up on their own time
[17:40] <infinity> We'll see how the other arches fare.
[17:40] <slangasek> (since I don't think any of those projects are building armhf images currently)
[17:40] <Laney> ubuntu2/armhf actually FTBFSed
[17:40] <Laney> So we'll see how this one does
[17:42] <Laney> It'll need some forcing or removals in any event since arm64/ppc64el have regressed
[17:42] <Laney> Might be one to punt
[17:42] <Laney> Dunno how crap 38 is
[17:42] <infinity> Has anyone looked into *why* they regressed?
[17:43] <infinity> They build fine in xenial with the same upstream version.
[17:45] <Laney> chrisccoulson: ^- (I'm guessing "no")
[17:45] <Laney> u-s-s worked
[17:47] <chrisccoulson> i didn't notice that ubuntu2 had been approved actually
[17:48] <chrisccoulson> the armhf is a race condition that we keep seeing in the build. It'll probably work fine if it's retried
[17:48] <chrisccoulson> the arm64 build failure is a crash when compiling the startup cache
[17:49] <chrisccoulson> it most likely builds fine on xenial because it's not using gcc6
[17:52]  * infinity notes that gcc-5 is still in yakkety.
[17:52] <infinity> Not that that fixes the bugs, but it would defer the issue.
[17:54] -queuebot:#ubuntu-release- Unapproved: gcr (yakkety-proposed/main) [3.20.0-2ubuntu1 => 3.20.0-2ubuntu2] (kubuntu, ubuntu-desktop)
[18:03] <infinity> pitti: Are you on top of this indicator-transfer thing?
[18:03]  * infinity eyes libreoffice suspiciously in the queue.
[18:03] -queuebot:#ubuntu-release- Unapproved: accepted gcr [source] (yakkety-proposed) [3.20.0-2ubuntu2]
[18:04] -queuebot:#ubuntu-release- Unapproved: accepted python-tornado [source] (yakkety-proposed) [4.4.2-1ubuntu1]
[18:06] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (yakkety-proposed) [1:20161011.1-0ubuntu1]
[18:10] <chrisccoulson> oh, who just approved flash?
[18:12] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (precise-proposed/partner) [1:20160913.1-0ubuntu0.12.04.1 => 1:20161011.1-0ubuntu0.12.04.1] (no packageset)
[18:12] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20160913.1-0ubuntu0.16.04.1 => 1:20161011.1-0ubuntu0.16.04.1] (no packageset)
[18:12] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20160913.1-0ubuntu0.14.04.1 => 1:20161011.1-0ubuntu0.14.04.1] (no packageset)
[18:12] <infinity> chrisccoulson: Moi.
[18:12] <chrisccoulson> infinity, ah, thanks. I've just uploaded the rest of them now :)
[18:34] -queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (yakkety-proposed/main) [3.22.0-1ubuntu1 => 3.22.1-0ubuntu1] (ubuntu-desktop)
[18:35] <slangasek> jbicha: ^^ this impacts images across 4 flavors, for which image spins are supposed to start imminently; why is it uploaded now?
[18:36] <jbicha> slangasek: it can be an SRU right?
[18:37] <slangasek> jbicha: if it meets SRU requirements; ok I see the SRU template in the one bug, thanks
[18:38] <jbicha> it's not needed in the release images
[18:38] <slangasek> jbicha: I'm asking because it's hard to coordinate across all the release team working the queue in parallel, so it's important to have clarity about the target for these uploads
[18:38] <slangasek> ok
[19:00] <flexiondotorg> infinity, Is the release going to be delayed?
[19:01] <infinity> flexiondotorg: I shouldn't think so.
[19:01] <flexiondotorg> OK
[19:01] <flexiondotorg> The rumour mill is speculating. I'll pour water on that.
[19:01] <infinity> flexiondotorg: Rumour mills are special.
[19:02] <flexiondotorg> Indeed.
[19:03] <infinity> flexiondotorg: Perhaps the rumour mill should be harder at work on testing, reporting, and fixing. :P
[19:03] <flexiondotorg> That too.
[19:19] <lunaphyte> thanks everyone for entertaining my questions, etc.
[19:21] <slangasek> does a binary removal of an arch: all package on a specific arch DTRT? :P
[19:22] <infinity> slangasek: no.
[19:22] <slangasek> ok cool
[19:22] <slangasek> so how do we get juju in?
[19:22] <slangasek> I guess I can 'force' it
[19:23] <infinity> No.
[19:24] <slangasek> infinity: I hope you're planning on elaborating / presenting an alternative :)
[19:24] <infinity> I'm looking at the situation first.
[19:24] <slangasek> ok
[19:25] <slangasek> summary from my side: juju dropped 32-bit arch supports, with my sign-off; no transitional packages for this in yakkety because the drop is retroactive to xenial so for 16.10 we just want the packages gone; in the process that means juju is migrating from an (uninstallable) arch: all package to an arch: some package; and britney doesn't want to let it in
[19:25] <infinity> Check, and rmadison confirms.
[19:26] <slangasek> and I guess, from the output, that the arch: all-> arch: some change was made only in the latest release, since previous release was getting autopkgtest results
[19:26] <infinity> Okay, in that case, your propose arch-some removal might work.
[19:26] <slangasek> ok
[19:26] <infinity> The reason I said it doesn't is because all copies in LP are source-based, so binary removals always come back.
[19:26] <slangasek> did that, let's see what happens - thanks
[19:26] <infinity> And, thus, should be avoided.
[19:26] <infinity> (And definitely avoided for arch:all, which is just confusing)
[19:27] <infinity> But as a temp solution, it might DTRT.
[19:27] <infinity> If it doesn't, just remove juju from the release pocket entirely.
[19:27] <infinity> Still beats a force.
[19:32] <infinity> Okay, and juju's not in any metapackages, so don't need a refresh.
[19:32] <infinity> Though after the current things all settle, I'll do a world refresh of meta locally to see if any changes got missed.
[19:37] <pitti> slangasek: I didn't accept it; it seemed a bit dubious/too intrusive to me
[19:37] -queuebot:#ubuntu-release- Unapproved: wine-development (yakkety-proposed/universe) [1.9.19-1ubuntu1 => 1.9.20-1ubuntu1] (no packageset)
[19:37] -queuebot:#ubuntu-release- Unapproved: accepted wine-development [source] (yakkety-proposed) [1.9.20-1ubuntu1]
[19:38] <pitti> infinity: do you want everyone else to stay away from unapproved now?
[19:38] <pitti> or still want me to review the indicator-transfer thing?
[19:38] <pitti> (I have a hunch that's going to be needed for the ubuntu desktops at least, but not blocking all other flavors)
[19:39] <pitti> urgh, a LibO upload?
[19:39] <pitti> dear http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt, pretty please update
[19:39] <infinity> pitti: GO ahead and sort that, please.
[19:40] <pitti> Laney: running these shell scripts is a nice waste of resources too, but hopefully a bit less :)
[19:41] -queuebot:#ubuntu-release- Unapproved: accepted indicator-transfer [source] (yakkety-proposed) [0.2+16.10.20160808.1-0ubuntu2]
[19:42] <pitti> jbicha: do you want that g-s-d on the images? diff looks sane enough to me, but at this point there's little margin for errors
[19:43] <pitti> jbicha: did you test this on real hw with a battery? screen saver works ok?
[19:43] <jbicha> pitti: did you see s_langasek's comment above about it ^
[19:43] <pitti> no, /me reads backscroll
[19:44] <pitti> meh, somehow my firefox/ppc64el removal didn't work?
[19:45] <jbicha> I'd rather g-s-d just be an SRU actually; the bug fixes in it are fairly minor
[19:45] <pitti> ack, they don't seem image-critical, unlike the indicator thing
[19:45] <pitti> (relevant for live image)
[19:46] <pitti> infinity: I guess you should put a propagation block in place now, so that we have more control over this?
[19:46] <infinity> pitti: Yeahp.  Doing that now.
[19:46] <pitti> infinity, slangasek: are you on top of the juju 32 bit removals so that this can land, or want me to?
[19:46] <infinity> pitti: Steve's on the juju case.
[19:46] <pitti> the transitional moved from arch: all to arch: [list]
[19:46] <pitti> ack
[19:47] <pitti> infinity: so I can deal with firefox; 46.x and 47.x are gone, but 48.x ppc binaries still exist
[19:47] <infinity> pitti: The easier way to do that is just to remove source package by version.
[19:47] <infinity> pitti: remove-package -e 48.blah firefox
[19:48] <infinity> pitti: Way simpler than trying to hunt down the mismatched bits.
[19:48] <pitti> infinity: that would entirely remove it from yakkety for a short blip of time, though?
[19:48] <infinity> pitti: Do you care?
[19:48] <pitti> I ran http://paste.ubuntu.com/23309737/ earlier, apparently that didn't work
[19:48] <infinity> If the goal is to get 49 in ASAP.
[19:48] <pitti> ok
[19:49] <pitti> infinity: done
[19:49] <infinity> pitti: I'm more worried about c-m exploding due to this.
[19:49] <pitti> seems a bit awkward to remove "good" binaries temporarily from the release, but indeed, better than screwing it up for another publisher
[19:50] <infinity> pitti: But maybe with archive-reorg, it won't.  The old "if we have no firefox, other browsers get yanked into main" thing *might* have been a build-dep issue.
[19:50] <infinity> Here's hoping.
[19:50] <infinity> I honestly don't recall if it was build-dep or runtime.
[19:50] <infinity> Though, at the very least, we'll need a meta refresh.
[19:51] <infinity> Which is on my TODO in a publisher cycle or three.
[19:51] <pitti> infinity: after it updates, http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt will still have some remaining bits -- e. g. libnuma1 on s390x only
[19:51] <infinity> I'll hold off on the britney block for another cycle or two as well.
[19:51] <pitti> oh wait, libnuma1 will then be in "optional" everywhere
[19:51] <infinity> I thought I had a hint for numa.
[19:51] <pitti> I was going to ask whether it's ok to have a different priority on a particular arch only
[19:52] <pitti> but seems it's the other way round -- it currently differs, this will now make it equal to other arches
[19:52] <infinity> You can't have mismatched priorities on arches, LP doesn't allow it.
[19:52] <infinity> Unless something goofs up.
[19:52] <infinity> Does architecture-mismatches show an issue?
[19:52] <pitti> ah no - libnuma1 is in standard for other arches
[19:53] <pitti> python* and perl* should be gone now -- I figure we need to promote this silly pinentry-curses now
[19:53] <pitti> infinity: wow, I was completely ignorant of http://people.canonical.com/~ubuntu-archive/architecture-mismatches.txt
[19:53] <infinity> I'll clean up the mismatches.
[19:53] <infinity> So we don't stomp on each other.
[19:54] <pitti> ack -- i. e. promote unity on arm64?
[19:54] <infinity> And priority stuff as well.
[19:54] <pitti> infinity: wait
[19:55] <pitti> infinity: can you predict what it's going to look like? or were you just going to promote pinentry-curses?
[19:56] <infinity> pitti: I'm fixing libnuma with a hint.  pinentry probably will want to promote.  But also waiting for the perl stuff to fall out.
[19:56] <pitti> libnettle6 might be a transient dep of pinentry
[19:56] <infinity> pitti: numa fix committed.
[19:57] <infinity> And unity8 fixed.
[19:58] <infinity> Finishing my lunch while I way for some archive settle.
[20:02] <tyhicks> Hi
[20:02] <tyhicks> we've just discovered that some confined programs are being denied access to the system bus due to the resolved changes in yakkety
[20:03] <tyhicks> at least tcpdump and ntpd are affected
[20:03] <pitti> that sounds SRUable?
[20:03] <tyhicks> nss seems to be falling back to do traditional name lookups whenever apparmor denies access to the bus but I don't know if that's acceptable
[20:03] <tyhicks> pitti: you would know best if the fallback is "safe" ^
[20:04] <pitti> tyhicks: NSS in general does work; you mean for apparmor profiles of programs where NSS doesn't work?
[20:04] <pitti> tyhicks: it's "safe" in yakkety as we disabled DNSSEC (and thus enforcement), so ATM falling back to "dns" is only a convenience/longer timeout/no caching issue
[20:05] <pitti> tyhicks: and desktops use dnsmasq anyway (again), not resolved
[20:05] <tyhicks> pitti: ok, so it sounds like we can fix this in an SRU
[20:05] <pitti> tyhicks: so you mean tcpdump/ntpd do lookups via NSS and are being denied D-Bus access?
[20:05] <tyhicks> pitti: correct
[20:05] <pitti> ok
[20:06] <sarnold> .. and everything else that aa-status reports as confined
[20:06] <pitti> tyhicks: i_nfinity installed a propagation block now, so we should actaully be able to start SRU uploads now
[20:07] <pitti> or rather, "soon" (block not yet active)
[20:07] <tyhicks> pitti: do I need to explicitly upload to yakkety-updates or will they be automatically routed to -updates?
[20:07] <pitti> tyhicks: no, *don't* upload to -updates, we need to reject this (and make sure we actually spot it)
[20:07] <pitti> tyhicks: continue to upload to yakkety or yakkety-proposed
[20:08] <tyhicks> thanks
[20:08] <pitti> tyhicks: -proposed is the same for devel and SRUs, just the propagation changes from -release to -updates
[20:08] <tyhicks> ack
[20:08] <pitti> so, uploading is fine at all times, but I can only review it after we get a release block
[20:11] <infinity> pitti: Yeah, the block will be in a couple of cycles, I don't want to block just to unblock everything in there right now.
[20:13]  * pitti waves good night
[20:15] -queuebot:#ubuntu-release- Unapproved: strongswan (trusty-proposed/main) [5.1.2-0ubuntu2.4 => 5.1.2-0ubuntu2.5] (no packageset)
[20:17] -queuebot:#ubuntu-release- Unapproved: multipath-tools (trusty-proposed/main) [0.4.9-3ubuntu7.14 => 0.4.9-3ubuntu7.15] (core)
[20:17] -queuebot:#ubuntu-release- Unapproved: unattended-upgrades (xenial-proposed/main) [0.90 => 0.90ubuntu0.1] (desktop-core, ubuntu-server)
[20:32] <brendand> who do i need to nudge to get cloud-init moving along from -proposed (in xenial)?
[20:32] -queuebot:#ubuntu-release- Unapproved: flashplugin-nonfree (yakkety-proposed/multiverse) [11.2.202.635ubuntu1 => 11.2.202.637ubuntu1] (no packageset)
[20:34] -queuebot:#ubuntu-release- Unapproved: accepted flashplugin-nonfree [source] (yakkety-proposed) [11.2.202.637ubuntu1]
[20:35] -queuebot:#ubuntu-release- Unapproved: icinga (xenial-proposed/universe) [1.13.3-2 => 1.13.3-2ubuntu0.1] (no packageset)
[20:35] <wxl> we having a respin at some point?
[20:36] <valorie> I heard "More than an hour, less than several"
[20:36] <wxl> jj
[20:36] <wxl> er
[20:36] <wxl> s/j/k/g
[20:36] <valorie> lol
[20:42] <brendand> infinity, any chance of nudging the cloud-init (xenial) sru along? bugs are verified, it's aged a week, and it's hurting us badly. understand if you're busy though
[20:47] <slangasek> valorie, wxl: right, and that was 3 hours ago
[20:47] <slangasek> infinity: what's the long pole now?
[20:48] <acheronuk> waiting until migration blocks are in place so I thought I read?
[20:52] <infinity> slangasek: Waiting on firefox migration, at least.
[20:53] <infinity> Less convinced about what to do with thunderbird.
[20:53] <infinity> Oh, but it looks like it's built/failed everywhere it's going to.
[20:53] <infinity> So maybe we can nudge that along too.
[20:55] <infinity> But yeah, probably time for the block and unblocks.
[20:55] <infinity> Doing that now.
[20:56]  * valorie sends a thousand {{{{{{{{{{{{{{{{{{{{{{hugs}}}}}}}}}}}}}}}}}}}}}}}}}} to the release team
[20:56] <infinity> I only deal in pie.
[20:57]  * valorie adds pie
[20:57] <valorie> and beer
[20:58] <valorie> and whisky for those who want it
[20:58]  * wxl wants maté
[20:58] <valorie> some nice cider for those who don't
[20:58] <cjwatson> infinity: priorities> LP allows it, we just try to avoid it because it's a pain to keep track of.  Maybe you're thinking of dak.
[20:59] <infinity> cjwatson: Perhaps.
[20:59] <acheronuk> valorie: I suspect strong coffee is also required
[20:59] <infinity> cjwatson: The archive doesn't allow it, then. :P
[21:00] <valorie> I'm willing to bet the team has laid in stores of coffee AND tea
[21:09] <dannf> infinity: i'm not sure how to report this via the QA tracker (is that setup yet?), but arm64 ISOs need a fix - LP: #1632473
[21:14] <infinity> dannf: Is this already correct in the mini.iso?
[21:15] <infinity> dannf: Cause I see no mention of gzio in d-i...
[21:17] <dannf> infinity: checking
[21:17] <dannf> infinity: mini iso boots - seeing if i can figure out why - side-effect perhaps?
[21:18] <infinity> Side effect of what? :P
[21:18] <dannf> some other preloaded module perhaps
[21:21] <infinity> The grub.cfg on mini.iso is pretty sparse.
[21:21] <dannf> hrm.. w/ debug=all, i don't see gzio ever load.
[21:24] <dannf> infinity: ah - looks like the kernel on the iso is a gzip'd file w/ no UEFI stub
[21:24] <dannf> whereas on the mini.iso, it's a gzip's kernel w/ a UEFI stub prefix like it should be
[21:26] <infinity> *raise brow*
[21:27] <infinity> That seems suboptimal.
[21:28] <infinity> So, I get vmlinuz straight out of d-i.
[21:28] <infinity> Why are you giving me two different kernels? :P
[21:30] <dannf> indeed...
[21:34] <dannf> oh - i'm not. i was just apparently testing the wrong mini.iso! egg/face
[21:34] <infinity> Ahh, so d-i is also broken?  That's less confusing.
[21:35] <dannf> yes. fixing.
[21:35] <infinity> Right, do some test runs there to get something that works, and I can mirror it in debian-cd, if it's not just carried over in cd-info.tar.gz.
[21:36] <infinity> dannf: A little late for grub uploads now, but I'd suggest that, perhaps, if gzio is required for arm64 now, it should probably be built-in. :P
[21:37] <infinity> (I assume it is for x86?)
[21:37] <infinity> Oh, hrm.  Won't this also break the installed system on reboot?
[21:38] <infinity> Oh, no, looks like the installed grub.cfg has gzio just in case.
[21:59] <dannf> yeah - i've been booting compressed kernels for a while  on EFI systems w/ no problem
[22:15] <cyphermox> dannf: infinity: it's already builtin to the EFI images
[22:19] <dannf> infinity, cyphermox : https://code.launchpad.net/~dannf/debian-installer/lp1632473/+merge/308199
[22:20] <infinity> dannf: Please commit, tag, and upload.
[22:20] <dannf> infinity: ack
[22:29] -queuebot:#ubuntu-release- Unapproved: debian-installer (yakkety-proposed/main) [20101020ubuntu482 => 20101020ubuntu483] (core)
[22:35] <flexiondotorg> infinity, Just trying to organise some final MATE testing.
[22:35] <flexiondotorg> Is a world respin planned?
[22:36] <wxl> supposedly incoming soon flexiondotorg
[22:36] <flexiondotorg> wxl For world?
[22:37] <sarnold> flexiondotorg: perhaps define what you mean by "world respin"
[22:37] <flexiondotorg> All the flavours.
[22:37] <flexiondotorg> Having images recreated.
[22:41] <slangasek> the world is constantly spinning, no "re" required
[22:41] <slangasek> yes, all flavors need an updated image
[22:41] <slangasek> stokachu, balloons, cyphermox: so, juju-core autopkgtest failure on ppc64el due to manual provider? expected?
[22:43] <cyphermox> I hear it's expected, but needs to be fixed?
[22:44] <cyphermox> slangasek: also, what do you mean, the world is spinning? isn't it constantly accelerating upwards at 9.8m/s^2?
[22:56] <slangasek> cyphermox: what does "needs to be fixed" mean here?  Should I expect a new fixed package before release?
[22:57] <cyphermox> slangasek: we discussed changes to this test this morning, but I don't know if you should be expecting a fixed package now
[22:57] <cyphermox> balloons: ^
[22:59] -queuebot:#ubuntu-release- Unapproved: update-notifier (xenial-proposed/main) [3.168.1 => 3.168.2] (ubuntu-desktop, ubuntu-server)
[23:22]  * tsimonq2 buys the release team a virtual cup of coffee and/or Red Bull for whoever wants it 
[23:55] <cyphermox> tsimonq2: good plan. I took a short video games break ... and it ended in a game over :(, but now coffee seems in order
[23:55] <tsimonq2> cyphermox: cheers :)