| 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:27 |
|---|---|---|
| pitti | so there was no reason to block glibc etc. on that, but yes, I'll file a bug | 05:28 |
| pitti | slangasek: bug 1602103 | 05:30 |
| ubot5 | bug 1602103 in nova (Ubuntu) "nova-daemons autopkgtest is flaky" [Undecided,New] https://launchpad.net/bugs/1602103 | 05:30 |
| 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:45 |
| 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:46 |
| 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:47 |
| pitti | dropped | 05:48 |
| 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:16 |
| pitti | but nobody reguarly looks at devel/unapproved outside of freezes | 06:17 |
| 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:27 |
| 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:28 |
| 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:29 |
| pitti | they all are, yes | 06:30 |
| slangasek | so yeah, we don't need those signed /again/, they can all be rejected | 06:30 |
| pitti | thanks for clarifying | 06:31 |
| pitti | (done) | 06:31 |
| pitti | FTR, doing SRUs, but I don't have the guts/enough knowledge about bug 1574727 to release that | 06:37 |
| ubot5 | 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 |
| pitti | (given how often this changed) | 06:37 |
| === ant_ is now known as Guest97948 | ||
| caribou | I would like to SRU the latest major release of sosreport now that it has proper DEP8 tests | 10:29 |
| 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:30 |
| cjwatson | jbicha: maitreya> *eyebrows* really? | 10:54 |
| 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) | 10:56 |
| 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. | 11:26 |
| jamiebennett | Can someone help with the snap-confine SRU: https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-launcher/+bug/1593396 | 12:11 |
| ubot5 | Launchpad bug 1593396 in ubuntu-core-launcher (Ubuntu Xenial) "[SRU] 1.0.36" [Undecided,New] | 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:11 |
| === ogra_ is now known as ogra | ||
| 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:16 |
| caribou | apw: there was never any MRE done for this one; it's a new request | 12:44 |
| 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:46 |
| caribou | apw: yes, wrong wording; I meant to do an MRE for it then the rules changed | 12:47 |
| 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 | 13:03 |
| 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:17 |
| 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 | 14:18 |
| 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:29 |
| bdmurray | LocutusOfBorg: noted | 15:44 |
| LocutusOfBorg | thanks | 15: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 | |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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 | :) | 16:09 |
| slangasek | cjwatson, jbicha: double-checked the history; as of version 7.0.5, maitreya is fine upstream | 17:06 |
| cjwatson | ok, good | 17:10 |
| jamiebennett | slangasek, any chance you could take a look at the snap-confine SRU and the golang-gopkg-macaroon package today? | 17:12 |
| 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:15 |
| 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:57 |
| jamiebennett | slangasek, I'm not sure, let me check | 17:58 |
| 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:04 | |
| 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:05 |
| jamiebennett | slangasek, I guess that is why he went with the update rather than rename | 18:06 |
| 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:07 |
| zyga | o | 18:12 |
| zyga | o/ | 18:12 |
| 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:06 |
| 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:08 |
| 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:12 |
| chrisccoulson | could someone please approve the flash uploads in partner? | 19:59 |
| slangasek | chrisccoulson: looking | 20:02 |
| chrisccoulson | slangasek, thanks | 20:02 |
| 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:27 |
| slangasek | chrisccoulson: yes | 20:28 |
| chrisccoulson | thanks :) | 20:28 |
| mwhudson | slangasek: i wanted zyga to check over the 1.0.36 packaging changes but i'm not sure he's done it yet | 20:59 |
| slangasek | mwhudson: ok; can you push your 'pristine-tar' and 'upstream' branches, anyway? | 21:15 |
| 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:16 |
| slangasek | heh | 21:17 |
| mwhudson | which is why i wanted zyga or someone else upstream to have a look | 21:19 |
| mwhudson | maybe jdstrand is still around... | 21:19 |
| 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:22 |
| mwhudson | slangasek: uh as it? | 21:23 |
| mwhudson | *has it | 21:23 |
| 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:24 |
| mwhudson | hum hum | 21:25 |
| 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:26 |
| 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:29 |
| 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:30 |
| slangasek | mwhudson: a glance at the source says --enable-nvidia-ubuntu is bind mounting nvidia drivers from the host | 21:32 |
| mwhudson | slangasek: i guess these nvidia drivers are not present in debian? | 21:33 |
| 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:34 |
| mwhudson | slangasek: ok, test building my updated package | 21:37 |
| 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:07 |
| mwhudson | slangasek: i would appreciate eyeballs on the apparmor bits, i don't really know how that works | 22:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!