pittislangasek, 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:27
pittiso there was no reason to block glibc etc. on that, but yes, I'll file a bug05:28
pittislangasek: bug 160210305:30
ubot5bug 1602103 in nova (Ubuntu) "nova-daemons autopkgtest is flaky" [Undecided,New] https://launchpad.net/bugs/160210305:30
slangasekpitti: 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:45
pittislangasek: right, I should version it at least, so that it stops blocking other packaes, but won't apply to newer nova versions05:46
pitti(then again we just keep bumping those too..)05:46
slangasekwell, 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
slangasekanyway, yay for the bug report, thanks05:47
pittiso you'd rather use force-skiptest on the packages that get blocked by it?05:47
pittiinfinity, apw: any idea what these are? https://launchpad.net/ubuntu/yakkety/+queue?queue_state=106:16
pittithe one for linux 28.47 has been sitting there for three weeks, so clearly not mission-critical06:16
pittibut nobody reguarly looks at devel/unapproved outside of freezes06:17
slangasekpitti: 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 archive06:27
pitti-30.49 has one for both proposed and release06:28
slangasekpitti: hmm, looks like they should have been accepted instead of rejected... troubling06:28
slangasekthey're not shown at http://archive.ubuntu.com/ubuntu/dists/yakkety/main/uefi/linux-amd64/06:28
pittiso that big tar.gz is a signature-y thing?06:28
slangasekand the linux source shouldn't migrate to devel without linux-signed06:28
slangasekthe tar.gz is the kernel to be signed06:29
slangasekso, I think this needs launchpad guidance06:29
slangasekwas this kernel forward-copied from xenial-proposed to yakkety?06:29
slangasekit was06:29
slangasekso that's why those managed to be in unapproved, yet the linux-signed is current06:29
pittithey all are, yes06:30
slangasekso yeah, we don't need those signed /again/, they can all be rejected06:30
pittithanks for clarifying06:31
pittiFTR, doing SRUs, but I don't have the guts/enough knowledge about bug 1574727 to release that06:37
ubot5bug 1574727 in grub2-signed (Ubuntu Xenial) "[SRU] Enforce using signed kernels and modules on UEFI" [Undecided,In progress] https://launchpad.net/bugs/157472706:37
pitti(given how often this changed)06:37
=== ant_ is now known as Guest97948
caribouI would like to SRU the latest major release of sosreport now that it has proper DEP8 tests10:29
cariboushould 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:30
cjwatsonjbicha: maitreya> *eyebrows* really?10:54
cjwatsonslangasek: ^- 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)10:56
rbasakcaribou: for MREs, the previous process was to have an SRU tracking bug anyway. So I presume that just carries on now.11:26
rbasakWe'll need one for the SRU verification process in any case.11:26
jamiebennettCan someone help with the snap-confine SRU: https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-launcher/+bug/159339612:11
ubot5Launchpad bug 1593396 in ubuntu-core-launcher (Ubuntu Xenial) "[SRU] 1.0.36" [Undecided,New]12:11
apwcaribou, 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 it12:11
jamiebennettThis will unblock a much needed feature that a lot of the teams are waiting on12:11
=== ogra_ is now known as ogra
LocutusOfBorgslangasek, hi, did you change your opinion about singular and armhf? I have a strong feeling that this is the last blocker for ntl migration12:16
caribouapw: there was never any MRE done for this one; it's a new request12:44
apwcaribou, 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:46
caribouapw: yes, wrong wording; I meant to do an MRE for it then the rules changed12:47
jbichacjwatson: 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 app13:03
LocutusOfBorgbdmurray,, I got a mail about a vbox regression http://people.canonical.com/~ubuntu-archive/phased-updates.html14:17
LocutusOfBorgplease kill it14:17
LocutusOfBorgit has been reproduced with kernel 4.7 and obviously the kernel module build failed14:18
LocutusOfBorgand BTW the current proposed package should be right14:18
slangasekcjwatson: 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 hmm15:29
bdmurrayLocutusOfBorg: noted15:44
=== nacc_ is now known as nacc
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:01
=== infinity_ is now known as infinity
* infinity plucks them out of the rejected queue.16:02
infinityslangasek: To be fair, it's also an irksome misfeature/bug that they get stuck there at all.16:04
apwinfinity, because they have been accepted before, or in general16:04
infinityslangasek: 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
infinityapw: ^16:05
infinityapw: 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
slangasekinfinity: doesn't the EFI signing happen only after it's been released from unapproved?16:06
slangasekin which case, signing the same object multiple times with different timestamps is not desirable16:06
infinityslangasek: Yes, which means that dists/$suite/signed/$package/$version will be empty if we don't accept it.16:06
apwslangasek, yes, the bits will get signed and published again16:06
apwthough the signed objects should be identicle in this case16:07
infinityslangasek: 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
slangasekI believe there is a timestamp16:07
* infinity shrugs.16:07
slangasekat least for EFI16:07
apwinfinity, they will actually be the same in my testing16:07
apwbut new times indeed in dists16:07
slangaseksignature proliferation makes me anxious16:07
infinityslangasek: 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
infinitySmarter 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:08
apwit would be nice if LP really knew the dist bits even existed16:09
infinityHence "harder to fix". :P16:09
slangasekcjwatson, jbicha: double-checked the history; as of version 7.0.5, maitreya is fine upstream17:06
cjwatsonok, good17:10
jamiebennettslangasek, any chance you could take a look at the snap-confine SRU and the golang-gopkg-macaroon package today?17:12
davmor2hey 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
chrisccoulsoncould someone please approve those flash uploads? ^^17:15
slangasekjamiebennett: 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:57
jamiebennettslangasek, I'm not sure, let me check17:58
slangasekjamiebennett: 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 track18:04
* jamiebennett agrees18:04
jamiebennettslangasek, would that mean a new package would have to be accepted or is it fine as just a rename?18:05
slangasekit means it will go through as a new package18:05
jamiebennettslangasek, I guess that is why he went with the update rather than rename18:06
slangasekjamiebennett: 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
slangasekmwhudson: ^^ is there a snap-confine 1.0.36-1 upload pending?18:07
mvoslangasek: 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 course19:06
mvoslangasek: anything else that needs to be done to move this sru forward?19:06
slangasekmvo: 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-119:08
slangasekmvo: 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 today19:12
chrisccoulsoncould someone please approve the flash uploads in partner?19:59
slangasekchrisccoulson: looking20:02
chrisccoulsonslangasek, thanks20:02
chrisccoulsonslangasek, thanks for approving those20:27
chrisccoulsonwill you be around in an hour or so to copy the binaries from proposed to the release pocket?20:27
slangasekchrisccoulson: yes20:28
chrisccoulsonthanks :)20:28
mwhudsonslangasek: i wanted zyga to check over the 1.0.36 packaging changes but i'm not sure he's done it yet20:59
slangasekmwhudson: ok; can you push your 'pristine-tar' and 'upstream' branches, anyway?21:15
mwhudsonslangasek: done21:16
mwhudsonslangasek: 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 tarball21:16
mwhudsonwhich is why i wanted zyga or someone else upstream to have a look21:19
mwhudsonmaybe jdstrand is still around...21:19
slangasekmwhudson: well, 1.0.36 has also been pushed to xenial-proposed queue, maybe you want to compare?21:22
mwhudsonah good idea21:22
mwhudsonslangasek: uh as it?21:23
mwhudson*has it21:23
slangasekmwhudson: under the name 'ubuntu-core-launcher', yes - see discussion in scrollback21:24
slangasekI'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 else21:24
mwhudsonhum hum21:25
mwhudsoni 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
mwhudsonwhich makes sense i guess21:26
mwhudsoneven though the profile is still called usr.bin.snap-confine21:26
mwhudsonit also changes to not pass --enable-rootfs-is-core-snap and only pass --enable-nvidia-ubuntu on ubuntu21:29
mwhudsonslangasek: do you know what these configure flags mean?21:29
slangasekmwhudson: 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 before21:30
slangasekmwhudson: a glance at the source says --enable-nvidia-ubuntu is bind mounting nvidia drivers from the host21:32
mwhudsonslangasek: i guess these nvidia drivers are not present in debian?21:33
slangasekmwhudson: 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 compatibility21:34
mwhudsonmakes sense21:34
mwhudsonslangasek: ok, test building my updated package21:37
mwhudsonslangasek: i've just pushed my version to alioth, do you want to look or do you trust me? :-)22:07
slangasekmwhudson: if I didn't trust you, I wouldn't have done the DM sign-off? ;)22:07
mwhudsonheh heh22:07
mwhudsonslangasek: i would appreciate eyeballs on the apparmor bits, i don't really know how that works22:08

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!