[02:09] <RAOF> Huh. Maas doesn't have a documented micro-release-exception?
[02:11] -queuebot:#ubuntu-release- Unapproved: rejected maas [source] (xenial-proposed) [2.2.3-6106-g314b2b2-0ubuntu1~16.04.1]
[02:31] -queuebot:#ubuntu-release- Unapproved: rejected python3.5 [source] (xenial-proposed) [3.5.2-2ubuntu0~16.04.2]
[02:41] <infinity> RAOF: https://wiki.ubuntu.com/MAASUpdates
[02:42] <infinity> RAOF: I believe it's still in the "needs review and possibly tweaks before being approved and linked from the SRU pages", but there it is.
[02:42] <RAOF> Aha!
[02:42] <RAOF> I thought I'd read a maas one, but there wasn't anything linked to the SRU page.
[02:43] <RAOF> Oh, well. The upload still needed a tracking bug.
[02:58] <tsimonq2> Oh hey infinity, nice to see you around again :)
[05:05] <didrocks> good morning
[05:56] <doko> bdmurray: see LP: #1682934, I'm not caring anymore about that and will fix it as won't fix. if RAOF thinks it is fine to reject, then fine ...
[05:56] <ubot5`> Launchpad bug 1682934 in python2.7 (Ubuntu) "python3 in /usr/local/bin can cause python3 packages to fail to install" [Undecided,Confirmed] https://launchpad.net/bugs/1682934
[05:56] <doko> SpamapS: ^^^
[05:57] <RAOF> doko: I'd be happy to *accept* an upload to fix that bug.
[05:58] <doko> please find somebody else to waste that time
[07:41] <LocutusOfBorg> hello, question, what about syncing a library that changed soname, but has no reverse-dependencies  in the archive? https://packages.qa.debian.org/p/pupnp-1.8.html
[07:41] <LocutusOfBorg> vlc is starting to depend on it soon, so I presume it would be better to have sonames in sync
[07:41] <LocutusOfBorg> also, htseq is unbuildable on i386 in debian and Ubuntu, but only debian removed it so far
[09:30] <juliank> Just a reminder about the gnutls28 is in zesty unapproved: It fixes an in-place encryption data loss on arm64 (ciphertext becomes all zeroes) and a connectivity issue (well, OSCP verification failing where it should not). Would be great to have that in -proposed soon.
[09:30] <LocutusOfBorg> also gnutls26 in trusty unapproved :)
[09:31] <juliank> right
[09:34] <juliank> The zesty SRU should be easy to review, and as a bonus point, I just copied the patches from Debian stable and refreshed them (so chances are they are fine, given they passed Debian's release team...)
[09:35]  * apw looks
[09:42] <apw> juliank, there is already a gnutls28 in zesty-proposed which has adt failures ... do you want to be merged witht hat ?
[09:46] <juliank> apw: It's based on that, I did not actually noticed that was still in -proposed. From a quick look, the failures in -proposed seem to be unrelated (aria2 fails in an http connection failure - no https, and systemd has been failing for a long time) - after all, the proposed change only affects the openssl compat library. So I guess you could either replace it, or push the existing to proposed first.
[09:47]  * apw dies a little inside ...
[09:47] <apw> ok i thikn it make sense to let this previous one out
[09:50] <juliank> apw: It's certainly verified, I just think the uploader did not watch the autopkgtests and bug around so nobody looked at it further :)
[09:51] -queuebot:#ubuntu-release- Unapproved: accepted gnutls28 [source] (zesty-proposed) [3.5.6-4ubuntu4.3]
[09:52] <juliank> apw: thanks
[09:54] <apw> LocutusOfBorg, that gnutls26 is based on the previos upload in -proposed which has failed verification
[09:57] <apw> LocutusOfBorg, these are all by the same person and as far as i can see they have based their second fix on their own bad version of the fix
[09:57] <apw> LocutusOfBorg, it looks like you have been sponsoring for them, if so could you circle with them and work out whats what with these two fixes
[09:58] <juliank> apw: The broken one is by Simon Deziel <simon.deziel@gmail.com>, the one LocutusOfBorg is interested in is by Samuel D. Leslie <sdl@nexiom.net>, but based on the broken one
[09:58] <juliank> There's a fixed patch in https://bugs.launchpad.net/debian/+source/gnutls28/+bug/1709193
[09:58] <ubot5`> Ubuntu bug 1709193 in gnutls28 (Ubuntu Xenial) "Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer" [Undecided,Fix committed]
[09:59] <apw> juliank, my bad i read those names as the saem, which is just wrong
[09:59] <juliank> So the realistic option is to rebase Samuel's patch on top of the updated patch for that bug
[09:59] <apw> yep, i'll reject what is here with that position
[10:01] -queuebot:#ubuntu-release- Unapproved: rejected gnutls26 [source] (trusty-proposed) [2.12.23-12ubuntu2.10]
[10:07] -queuebot:#ubuntu-release- Unapproved: accepted cryptsetup [source] (xenial-proposed) [2:1.6.6-5ubuntu2.1]
[10:07] <LocutusOfBorg> apw, I might just add this one?https://launchpadlibrarian.net/334087516/lp1709193-14.04-version2.debdiff
[10:11] <juliank> It's odd because I'm not sure if VERIFY_ALLOW_SIGN_RSA_MD5 would not allow MD5 signatures anywhere in the chain. I don't know if that's really something you'd want.
[10:12] <juliank> That is; '%VERIFY_ALLOW_SIGN_RSA_MD5' will allow RSA-MD5 signatures in certificate chains.
[10:13] <juliank> It's "OK" for self-signatures I guess, but I fear it might allow MD5 in general?
[10:13] <apw> juliank, indeed that sounds like something we would want input from tyhicks on
[10:13] <apw> as it is likely something they have turned off deliberatly
[10:15] -queuebot:#ubuntu-release- Unapproved: gnutls26 (trusty-proposed/main) [2.12.23-12ubuntu2.9 => 2.12.23-12ubuntu2.10] (core)
[10:15] <juliank> I think there is a bug that if the root cert is self-signed with MD5 that it is falsely rejected in gnutls26
[10:16] <juliank> (because the self-signature is irrelevant for a root cert)
[10:19]  * juliank is looking at gnutls git
[10:20] <juliank> This sound like it: https://gitlab.com/gnutls/gnutls/commit/b93ae1abf1b84fdc094f2474f1b2e4848081810e
[10:20] <juliank> But there might be other commits needed
[10:30] <apw> juliank, well it seems to remove a lot of code ... otehr than that i am not sure
[10:30] <apw> anyhow, we should wait on the security team feedback for that MD5 thing before we accept that SRU
[10:31] <juliank> Maybe just do LocutusOfBorg's one first without the other?
[10:32] <juliank> Should probably ask upstream about the whole thing, they might have a solution, although they're probably not that happy about questions about such old software :D
[10:32] <apw> juliank, i have added security to the bug, and pinged for an oppinion
[10:33] <juliank> Funny thing is that 2.12.23 was released 4 years ago (obviously ,it's in 14.04 after all), and 2.12.24 10 months ago, collecting patches for like 3 years
[10:37] <apw> juliank, security people are very much like that
[10:37] <apw> anyhow lets see what they say
[10:49] <juliank> Right now I'm figuring out how to best upload apt 1.4.7 (which is in stretch) to zesty-proposed. In theory, it could be synced but then there's no diff for review. I could also do a fake sync by rewriting the changes file; or I could just upload it with a changed changelog. It would sort of be nice to share the tarball and history with stretch.
[10:50] <juliank> * for next week, really
[10:50] <juliank> I guess optimally I'd just patch launchpad to create diffs for synced packages...
[10:53] <juliank> I have the fake sync in the apt PPA already since Jul 18, so that would be ready to go :)
[10:58] <juliank> Though I do have to do a 1.4.8 anyway, so it might not be 1.4.7 entering
[11:25] <cjwatson> "just"
[11:25] <cjwatson> https://bugs.launchpad.net/launchpad/+bug/851562
[11:25] <ubot5`> Ubuntu bug 851562 in Launchpad itself "Diffs not available for syncs on +queue page like for regular uploads" [High,Triaged]
[11:30] <juliank> cjwatson: :D
[11:36] <juliank> cjwatson: syncpackage --no-lp actually does a reasonable job, except that it also resigns the .dsc; so it's probably easiest for me to just change that
[11:36] <Laney> We used to call the the "categorical just" in CS. <30 minute presentation>. "Isn't that just an instance of <insane category theoretic structure>?"
[11:37] <juliank> grr, gpg: signing failed: Card reset required
[11:41] <juliank> But, yay, with that line patched out, syncpackage --no-lp does a reasonable job of syncing apt 1.4.7 from stretch to zesty, probably with launchpad generating a diff then
[11:41] <juliank> (not tested, but since uploading changes...)
[12:13] <cpaelzer> anybody on the release team time to check FFE on bug 1706248?
[12:13] <ubot5`> bug 1706248 in slof (Ubuntu) "[FFE] SLOF dhcp request doesn't include client architecture code 93" [Medium,Confirmed] https://launchpad.net/bugs/1706248
[13:10] -queuebot:#ubuntu-release- Unapproved: ubuntu-fan (zesty-proposed/main) [0.12.2.1 => 0.12.4~17.04.1] (no packageset)
[13:25] -queuebot:#ubuntu-release- New sync: fontawesomefx (artful-proposed/primary) [8.9-1]
[13:32] -queuebot:#ubuntu-release- New sync: libimglib2-java (artful-proposed/primary) [4.3.0-1]
[13:32] -queuebot:#ubuntu-release- New sync: libparsington-java (artful-proposed/primary) [1.0.1-1]
[13:52] -queuebot:#ubuntu-release- New: accepted fontawesomefx [sync] (artful-proposed) [8.9-1]
[13:52] -queuebot:#ubuntu-release- New: accepted libparsington-java [sync] (artful-proposed) [1.0.1-1]
[13:52] -queuebot:#ubuntu-release- New: accepted libimglib2-java [sync] (artful-proposed) [4.3.0-1]
[13:56] -queuebot:#ubuntu-release- New binary: fontawesomefx [amd64] (artful-proposed/none) [8.9-1] (no packageset)
[13:57] -queuebot:#ubuntu-release- New binary: libparsington-java [amd64] (artful-proposed/none) [1.0.1-1] (no packageset)
[14:02] -queuebot:#ubuntu-release- New binary: libimglib2-java [amd64] (artful-proposed/none) [4.3.0-1] (no packageset)
[14:04] -queuebot:#ubuntu-release- New: accepted fontawesomefx [amd64] (artful-proposed) [8.9-1]
[14:04] -queuebot:#ubuntu-release- New: accepted libparsington-java [amd64] (artful-proposed) [1.0.1-1]
[14:04] -queuebot:#ubuntu-release- New: accepted libimglib2-java [amd64] (artful-proposed) [4.3.0-1]
[14:14] <xnox> Rebuilding perl, by syncing from debian, to get the right config.h defines for the new glibc.
[14:18]  * Laney cries
[14:28] -queuebot:#ubuntu-release- Unapproved: rejected google-cloud-sdk [source] (zesty-proposed) [166.0.0-0ubuntu1~17.04.0]
[14:28] -queuebot:#ubuntu-release- Unapproved: rejected google-cloud-sdk [source] (xenial-proposed) [166.0.0-0ubuntu1~16.04.0]
[14:34] <xnox> Laney, otherwise things fail to detect perl.h and FTBFS =/
[14:34] <xnox> as it includes header that glibc no longer ships
[14:49] -queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (zesty-proposed/partner) [163.0.0-0ubuntu1~17.04.0 => 169.0.0-0ubuntu1~17.04.0] (no packageset)
[14:50] -queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (xenial-proposed/partner) [163.0.0-0ubuntu1~16.04.0 => 169.0.0-0ubuntu1~16.04.0] (no packageset)
[14:51] -queuebot:#ubuntu-release- Unapproved: google-cloud-sdk (trusty-proposed/partner) [163.0.0-0ubuntu1~14.04.0 => 169.0.0-0ubuntu1~14.04.0] (no packageset)
[20:01] <doko> update_excuses not update for three hours?
[20:07] <LocutusOfBorg> yep, looks like britney having a sad day
[20:51] <LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/proposed-migration/log/artful/2017-09-06/
[20:51] <LocutusOfBorg> seems running now
[21:23] <LocutusOfBorg> but something is down, autopkgtests and something more :(
[22:11] -queuebot:#ubuntu-release- Unapproved: ibm-java80 (xenial-proposed/partner) [8.0.4.1-0ubuntu1 => 8.0.4.11-0ubuntu1] (no packageset)
[23:09] <SpamapS> RAOF: do we still have to do SRU's to zesty even though it is EOL?
[23:10] <SpamapS> Like, who cares if somebody upgrades to it and regresses, they're not supported anyway.
[23:10] <RAOF> SpamapS: Zesty isn't EOL yet, is it?!
[23:10] <SpamapS> RAOF: 4/13/17
[23:10] <SpamapS> oh haha
[23:10] <SpamapS> That's RELEASE date
[23:11] <SpamapS> derpaderp
[23:11] <SpamapS> I's smahrt
[23:11] <SpamapS> RAOF: carry on. ;)
[23:11] <SpamapS> I'll prep a zesty upload
[23:11] <RAOF> I would be rather surprised if we EOL'd Zesty *before* we released Artful :)
[23:15] <juliank> I'm wondering about ndiswrapper SRUs for HWE kernels; whether it really makes sense to do the intermediate SRU there as well (given that the intermediate release has no HWE kernel). But I guess it does not hurt and I just re-upload the devel version anyway with ~16.04.1 or something appended
[23:15] <juliank> so not really wondering