[05:27] 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] so there was no reason to block glibc etc. on that, but yes, I'll file a bug [05:30] slangasek: bug 1602103 [05:30] bug 1602103 in nova (Ubuntu) "nova-daemons autopkgtest is flaky" [Undecided,New] https://launchpad.net/bugs/1602103 [05:45] 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] 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] (then again we just keep bumping those too..) [05:47] 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] anyway, yay for the bug report, thanks [05:47] so you'd rather use force-skiptest on the packages that get blocked by it? [05:47] yes [05:47] ok [05:48] dropped [06:16] infinity, apw: any idea what these are? https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1 [06:16] the one for linux 28.47 has been sitting there for three weeks, so clearly not mission-critical [06:17] but nobody reguarly looks at devel/unapproved outside of freezes [06:27] 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] -30.49 has one for both proposed and release [06:28] pitti: hmm, looks like they should have been accepted instead of rejected... troubling [06:28] they're not shown at http://archive.ubuntu.com/ubuntu/dists/yakkety/main/uefi/linux-amd64/ [06:28] so that big tar.gz is a signature-y thing? [06:28] and the linux source shouldn't migrate to devel without linux-signed [06:29] the tar.gz is the kernel to be signed [06:29] so, I think this needs launchpad guidance [06:29] oh [06:29] was this kernel forward-copied from xenial-proposed to yakkety? [06:29] it was [06:29] so that's why those managed to be in unapproved, yet the linux-signed is current [06:30] they all are, yes [06:30] so yeah, we don't need those signed /again/, they can all be rejected [06:31] thanks for clarifying [06:31] (done) [06:37] FTR, doing SRUs, but I don't have the guts/enough knowledge about bug 1574727 to release that [06:37] bug 1574727 in grub2-signed (Ubuntu Xenial) "[SRU] Enforce using signed kernels and modules on UEFI" [Undecided,In progress] https://launchpad.net/bugs/1574727 [06:37] (given how often this changed) === ant_ is now known as Guest97948 [10:29] I would like to SRU the latest major release of sosreport now that it has proper DEP8 tests [10:30] 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] jbicha: maitreya> *eyebrows* really? [10:56] slangasek: ^- would you care to double-check that maitreya is now OK to have in our archive? [10:56] (given that the last time it was removed was because of legal papers) [11:26] caribou: for MREs, the previous process was to have an SRU tracking bug anyway. So I presume that just carries on now. [11:26] We'll need one for the SRU verification process in any case. [12:11] Can someone help with the snap-confine SRU: https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-launcher/+bug/1593396 [12:11] Launchpad bug 1593396 in ubuntu-core-launcher (Ubuntu Xenial) "[SRU] 1.0.36" [Undecided,New] [12:11] 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] This will unblock a much needed feature that a lot of the teams are waiting on === ogra_ is now known as ogra [12:16] 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] :) [12:44] apw: there was never any MRE done for this one; it's a new request [12:46] 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] apw: yes, wrong wording; I meant to do an MRE for it then the rules changed [13:03] 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] bdmurray,, I got a mail about a vbox regression http://people.canonical.com/~ubuntu-archive/phased-updates.html [14:17] please kill it [14:18] it has been reproduced with kernel 4.7 and obviously the kernel module build failed [14:18] and BTW the current proposed package should be right [15:29] 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] LocutusOfBorg: noted [15:44] thanks === nacc_ is now known as nacc [16:01] 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. === infinity_ is now known as infinity [16:02] * infinity plucks them out of the rejected queue. [16:04] slangasek: To be fair, it's also an irksome misfeature/bug that they get stuck there at all. [16:04] infinity, because they have been accepted before, or in general [16:05] 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] apw: ^ [16:06] ahh [16:06] 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] infinity: doesn't the EFI signing happen only after it's been released from unapproved? [16:06] in which case, signing the same object multiple times with different timestamps is not desirable [16:06] slangasek: Yes, which means that dists/$suite/signed/$package/$version will be empty if we don't accept it. [16:06] slangasek, yes, the bits will get signed and published again [16:07] though the signed objects should be identicle in this case [16:07] 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] (Actually, they might not be, if a timestamp isn't baked in) [16:07] I believe there is a timestamp [16:07] * infinity shrugs. [16:07] at least for EFI [16:07] infinity, they will actually be the same in my testing [16:07] but new times indeed in dists [16:07] signature proliferation makes me anxious [16:08] 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] mmk [16:08] 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] it would be nice if LP really knew the dist bits even existed [16:09] Exactly. [16:09] Hence "harder to fix". :P [16:09] :) [17:06] cjwatson, jbicha: double-checked the history; as of version 7.0.5, maitreya is fine upstream [17:10] ok, good [17:12] slangasek, any chance you could take a look at the snap-confine SRU and the golang-gopkg-macaroon package today? [17:15] 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] could someone please approve those flash uploads? ^^ [17:57] 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] slangasek, I'm not sure, let me check [18:04] 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] slangasek, would that mean a new package would have to be accepted or is it fine as just a rename? [18:05] it means it will go through as a new package [18:06] slangasek, I guess that is why he went with the update rather than rename [18:07] 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] mwhudson: ^^ is there a snap-confine 1.0.36-1 upload pending? [18:12] o [18:12] o/ [19:06] 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] slangasek: anything else that needs to be done to move this sru forward? [19:08] 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] 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] could someone please approve the flash uploads in partner? [20:02] chrisccoulson: looking [20:02] slangasek, thanks [20:27] slangasek, thanks for approving those [20:27] will you be around in an hour or so to copy the binaries from proposed to the release pocket? [20:28] chrisccoulson: yes [20:28] thanks :) [20:59] 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] mwhudson: ok; can you push your 'pristine-tar' and 'upstream' branches, anyway? [21:16] slangasek: done [21:16] 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] heh [21:19] which is why i wanted zyga or someone else upstream to have a look [21:19] maybe jdstrand is still around... [21:22] mwhudson: well, 1.0.36 has also been pushed to xenial-proposed queue, maybe you want to compare? [21:22] ah good idea [21:23] slangasek: uh as it? [21:23] *has it [21:24] mwhudson: under the name 'ubuntu-core-launcher', yes - see discussion in scrollback [21:24] ah [21:24] 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] hum hum [21:26] 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] which makes sense i guess [21:26] even though the profile is still called usr.bin.snap-confine [21:29] it also changes to not pass --enable-rootfs-is-core-snap and only pass --enable-nvidia-ubuntu on ubuntu [21:29] slangasek: do you know what these configure flags mean? [21:30] 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] mwhudson: a glance at the source says --enable-nvidia-ubuntu is bind mounting nvidia drivers from the host [21:33] slangasek: i guess these nvidia drivers are not present in debian? [21:34] 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] makes sense [21:37] slangasek: ok, test building my updated package [22:07] slangasek: i've just pushed my version to alioth, do you want to look or do you trust me? :-) [22:07] mwhudson: if I didn't trust you, I wouldn't have done the DM sign-off? ;) [22:07] heh heh [22:08] slangasek: i would appreciate eyeballs on the apparmor bits, i don't really know how that works