[05:27] <pitti> slangasek, xnox: I don't think nova is an xnox problem; this is just a timing issue, the test has been racy forever (also on other arches, but a retry has a good chance there)
[05:28] <pitti> so there was no reason to block glibc etc. on that, but yes, I'll file a bug
[05:30] <pitti> slangasek: bug 1602103
[05:45] <slangasek> pitti: you didn't mark it as flaky on all archs, only on s390x; and you marked it a badtest which means it would always be skipped going forward, hiding any possible regressions...
[05:46] <pitti> slangasek: right, I should version it at least, so that it stops blocking other packaes, but won't apply to newer nova versions
[05:46] <pitti> (then again we just keep bumping those too..)
[05:47] <slangasek> well, I think it shouldn't be badtest at all under such circumstances... we don't want dependencies of nova to let it regress either :/
[05:47] <slangasek> anyway, yay for the bug report, thanks
[05:47] <pitti> so you'd rather use force-skiptest on the packages that get blocked by it?
[05:47] <slangasek> yes
[05:47] <pitti> ok
[05:48] <pitti> dropped
[06:16] <pitti> infinity, apw: any idea what these are? https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1
[06:16] <pitti> the one for linux 28.47 has been sitting there for three weeks, so clearly not mission-critical
[06:17] <pitti> but nobody reguarly looks at devel/unapproved outside of freezes
[06:27] <slangasek> pitti: not sure why they went to yakkety instead of yakkety-proposed, I suppose at this point those should be rejected... Every linux amd64 upload is accompanied by a uefi tarball that is supposed to get signed off by an archive admin in the unapproved queue before it's signed and published to the archive
[06:28] <pitti> -30.49 has one for both proposed and release
[06:28] <slangasek> pitti: hmm, looks like they should have been accepted instead of rejected... troubling
[06:28] <slangasek> they're not shown at http://archive.ubuntu.com/ubuntu/dists/yakkety/main/uefi/linux-amd64/
[06:28] <pitti> so that big tar.gz is a signature-y thing?
[06:28] <slangasek> and the linux source shouldn't migrate to devel without linux-signed
[06:29] <slangasek> the tar.gz is the kernel to be signed
[06:29] <slangasek> so, I think this needs launchpad guidance
[06:29] <slangasek> oh
[06:29] <slangasek> was this kernel forward-copied from xenial-proposed to yakkety?
[06:29] <slangasek> it was
[06:29] <slangasek> so that's why those managed to be in unapproved, yet the linux-signed is current
[06:30] <pitti> they all are, yes
[06:30] <slangasek> so yeah, we don't need those signed /again/, they can all be rejected
[06:31] <pitti> thanks for clarifying
[06:31] <pitti> (done)
[06:37] <pitti> FTR, doing SRUs, but I don't have the guts/enough knowledge about bug 1574727 to release that
[06:37] <pitti> (given how often this changed)
[10:29] <caribou> I would like to SRU the latest major release of sosreport now that it has proper DEP8 tests
[10:30] <caribou> should I just upload to the queue & open a bug to have it SRUed properly  or there is another process for such a situation (former MRE) ?
[10:54] <cjwatson> jbicha: maitreya> *eyebrows* really?
[10:56] <cjwatson> slangasek: ^- would you care to double-check that maitreya is now OK to have in our archive?
[10:56] <cjwatson> (given that the last time it was removed was because of legal papers)
[11:26] <rbasak> caribou: for MREs, the previous process was to have an SRU tracking bug anyway. So I presume that just carries on now.
[11:26] <rbasak> We'll need one for the SRU verification process in any case.
[12:11] <jamiebennett> Can someone help with the snap-confine SRU: https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-launcher/+bug/1593396
[12:11] <apw> caribou, yeah an SRU bug but do include a reference to the MRE (i believe they are all meant to be recorded in the wiki) so a reviewer knows easily what the conditions were on it
[12:11] <jamiebennett> This will unblock a much needed feature that a lot of the teams are waiting on
[12:16] <LocutusOfBorg> slangasek, hi, did you change your opinion about singular and armhf? I have a strong feeling that this is the last blocker for ntl migration
[12:16] <LocutusOfBorg> :)
[12:44] <caribou> apw: there was never any MRE done for this one; it's a new request
[12:46] <apw> caribou, i read "former MRE" to say that we had had an MRE for it before, and mostly those are ongoing in scope (this may not have been)
[12:47] <caribou> apw: yes, wrong wording; I meant to do an MRE for it then the rules changed
[13:03] <jbicha> cjwatson: yeah, maitreya says it fixed the font in 7.0.4; maybe it would have been better to just update the version back then but it's an odd app
[14:17] <LocutusOfBorg> bdmurray,, I got a mail about a vbox regression http://people.canonical.com/~ubuntu-archive/phased-updates.html
[14:17] <LocutusOfBorg> please kill it
[14:18] <LocutusOfBorg> it has been reproduced with kernel 4.7 and obviously the kernel module build failed
[14:18] <LocutusOfBorg> and BTW the current proposed package should be right
[15:29] <slangasek> cjwatson: I recall there was discussion about upstream fixes for the maitreya problems, which is why I approved it in NEW without further thought; but I see that the package that got synced is from 2014, so hmm
[15:44] <bdmurray> LocutusOfBorg: noted
[15:44] <LocutusOfBorg> thanks
[16:01] <infinity_> slangasek: For the sake of archive consistency, those tarballs should have been accepted, not rejected, but as nothing will rebuild linux-signed in the release pocket, it's not really a big deal.
[16:02]  * infinity plucks them out of the rejected queue.
[16:04] <infinity> slangasek: To be fair, it's also an irksome misfeature/bug that they get stuck there at all.
[16:04] <apw> infinity, because they have been accepted before, or in general
[16:05] <infinity> slangasek: There's code in LP that checks if source==target when doing a copy and will only stick a tarball in unapproved if they mismatch, *but* the "source" is absolute, so if the tarball orginiated in a PPA (which all kernel SRUs do), the future copies are all doomed to get stuck by that check.
[16:05] <infinity> apw: ^
[16:06] <apw> ahh
[16:06] <infinity> apw: If you want to find and fix that, it would be great.  Instead of checking source==target, it should check if the SPR already exists in the target archive.
[16:06] <slangasek> infinity: doesn't the EFI signing happen only after it's been released from unapproved?
[16:06] <slangasek> in which case, signing the same object multiple times with different timestamps is not desirable
[16:06] <infinity> slangasek: Yes, which means that dists/$suite/signed/$package/$version will be empty if we don't accept it.
[16:06] <apw> slangasek, yes, the bits will get signed and published again
[16:07] <apw> though the signed objects should be identicle in this case
[16:07] <infinity> slangasek: All the kernel stuff is detached sigs, so I'm not sure how much that matters.  I mean, yes, the sigs will be different, but...
[16:07] <infinity> (Actually, they might not be, if a timestamp isn't baked in)
[16:07] <slangasek> I believe there is a timestamp
[16:07]  * infinity shrugs.
[16:07] <slangasek> at least for EFI
[16:07] <apw> infinity, they will actually be the same in my testing
[16:07] <apw> but new times indeed in dists
[16:07] <slangasek> signature proliferation makes me anxious
[16:08] <infinity> slangasek: Either way, the archive should, in theory, be rebuildable against itself, which it isn't if we don't have those bits in the right suites.
[16:08] <slangasek> mmk
[16:08] <infinity> Smarter custom upload handling that actually copied the directories around instead of republishing the tarballs would be nice, but a lot more complicated to fix.
[16:09] <apw> it would be nice if LP really knew the dist bits even existed
[16:09] <infinity> Exactly.
[16:09] <infinity> Hence "harder to fix". :P
[16:09] <apw> :)
[17:06] <slangasek> cjwatson, jbicha: double-checked the history; as of version 7.0.5, maitreya is fine upstream
[17:10] <cjwatson> ok, good
[17:12] <jamiebennett> slangasek, any chance you could take a look at the snap-confine SRU and the golang-gopkg-macaroon package today?
[17:15] <davmor2> hey guys in the installer it says Enable 3rd party drivers, this includes Graphics, wifi, mp3 etc why are the 3rd party graphics like nvidia and amd never installed?
[17:15] <chrisccoulson> could someone please approve those flash uploads? ^^
[17:57] <slangasek> jamiebennett: snap-confine> I see that this has been uploaded to the xenial SRU queue as 'ubuntu-core-launcher', even though we renamed the source package to snap-confine as of 1.0.35 in Debian and yakkety, why is this?
[17:58] <jamiebennett> slangasek, I'm not sure, let me check
[18:04] <slangasek> jamiebennett: it's possible mvo thought it was preferable to minimize the changes for SRU; IMHO it's preferable to effect the rename so that we stay as close as possible to trunk, given that we will continue to track
[18:04]  * jamiebennett agrees
[18:05] <jamiebennett> slangasek, would that mean a new package would have to be accepted or is it fine as just a rename?
[18:05] <slangasek> it means it will go through as a new package
[18:06] <jamiebennett> slangasek, I guess that is why he went with the update rather than rename
[18:07] <slangasek> jamiebennett: also, this is versioned as '1.0.36~16.04' here, which implies it's a backport of the devel version... but there is no corresponding 1.0.36 in yakkety currently (and at this point, it should be 1.0.36-1 anyway)
[18:07] <slangasek> mwhudson: ^^ is there a snap-confine 1.0.36-1 upload pending?
[18:12] <zyga> o
[18:12] <zyga> o/
[19:06] <mvo> slangasek: I assume you talked about the snap-confine/ubuntu-core-launcher SRU earlier with jamiebennett? I missed the discussion, I heard we need 1.0.36 in yakkety and that its fine to use the new source package. so far I assumed its easier if its the same source package but I'm happy to adjust of course
[19:06] <mvo> slangasek: anything else that needs to be done to move this sru forward?
[19:08] <slangasek> mvo: yes, so I suggested that we should use the new source package name instead of continuing to carry a delta between xenial and yakkety; and was interested to know the status of 1.0.36-1
[19:12] <slangasek> mvo: looks to me like mwhudson has 1.0.36-1 in progress for Debian, but hasn't pushed all the branches/tags to alioth; would like to get that into Debian and yakkety today
[19:59] <chrisccoulson> could someone please approve the flash uploads in partner?
[20:02] <slangasek> chrisccoulson: looking
[20:02] <chrisccoulson> slangasek, thanks
[20:27] <chrisccoulson> slangasek, thanks for approving those
[20:27] <chrisccoulson> will you be around in an hour or so to copy the binaries from proposed to the release pocket?
[20:28] <slangasek> chrisccoulson: yes
[20:28] <chrisccoulson> thanks :)
[20:59] <mwhudson> slangasek: i wanted zyga to check over the 1.0.36 packaging changes but i'm not sure he's done it yet
[21:15] <slangasek> mwhudson: ok; can you push your 'pristine-tar' and 'upstream' branches, anyway?
[21:16] <mwhudson> slangasek: done
[21:16] <mwhudson> slangasek: i'm actually a little confused, i think perhaps really 1.0.36-1 should have been 1.0.35-2, there are very few changes in the released tarball
[21:17] <slangasek> heh
[21:19] <mwhudson> which is why i wanted zyga or someone else upstream to have a look
[21:19] <mwhudson> maybe jdstrand is still around...
[21:22] <slangasek> mwhudson: well, 1.0.36 has also been pushed to xenial-proposed queue, maybe you want to compare?
[21:22] <mwhudson> ah good idea
[21:23] <mwhudson> slangasek: uh as it?
[21:23] <mwhudson> *has it
[21:24] <slangasek> mwhudson: under the name 'ubuntu-core-launcher', yes - see discussion in scrollback
[21:24] <mwhudson> ah
[21:24] <slangasek> I've blocked that SRU review on this discussion, since the version number supposes it's a backport of a thing that doesn't exist anywhere else
[21:25] <mwhudson> hum hum
[21:26] <mwhudson> i think the main change is to confine /usr/lib/snapd/snap-confine (which exists) and not /usr/bin/snap-confine (which doesn't(
[21:26] <mwhudson> which makes sense i guess
[21:26] <mwhudson> even though the profile is still called usr.bin.snap-confine
[21:29] <mwhudson> it also changes to not pass --enable-rootfs-is-core-snap and only pass --enable-nvidia-ubuntu on ubuntu
[21:29] <mwhudson> slangasek: do you know what these configure flags mean?
[21:30] <slangasek> mwhudson: not precisely; the theory of the first option is that snapd is enabled to do different things if it knows it's running the host, but I don't know the specifics, and I've never seen that second option before
[21:32] <slangasek> mwhudson: a glance at the source says --enable-nvidia-ubuntu is bind mounting nvidia drivers from the host
[21:33] <mwhudson> slangasek: i guess these nvidia drivers are not present in debian?
[21:34] <slangasek> mwhudson: there are nvidia drivers in Debian; I don't know if the directory layout is the same; I guess upstream is being conservative and not enabling it until someone checks the compatibility
[21:34] <mwhudson> makes sense
[21:37] <mwhudson> slangasek: ok, test building my updated package
[22:07] <mwhudson> slangasek: i've just pushed my version to alioth, do you want to look or do you trust me? :-)
[22:07] <slangasek> mwhudson: if I didn't trust you, I wouldn't have done the DM sign-off? ;)
[22:07] <mwhudson> heh heh
[22:08] <mwhudson> slangasek: i would appreciate eyeballs on the apparmor bits, i don't really know how that works