[02:09] 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] RAOF: https://wiki.ubuntu.com/MAASUpdates [02:42] 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] Aha! [02:42] I thought I'd read a maas one, but there wasn't anything linked to the SRU page. [02:43] Oh, well. The upload still needed a tracking bug. [02:58] Oh hey infinity, nice to see you around again :) [05:05] good morning [05:56] 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] 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] SpamapS: ^^^ [05:57] doko: I'd be happy to *accept* an upload to fix that bug. [05:58] please find somebody else to waste that time === maclin1 is now known as maclin [07:41] 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] vlc is starting to depend on it soon, so I presume it would be better to have sonames in sync [07:41] also, htseq is unbuildable on i386 in debian and Ubuntu, but only debian removed it so far [09:30] 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] also gnutls26 in trusty unapproved :) [09:31] right [09:34] 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] juliank, there is already a gnutls28 in zesty-proposed which has adt failures ... do you want to be merged witht hat ? [09:46] 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] ok i thikn it make sense to let this previous one out [09:50] 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] apw: thanks [09:54] LocutusOfBorg, that gnutls26 is based on the previos upload in -proposed which has failed verification [09:57] 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] 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] apw: The broken one is by Simon Deziel , the one LocutusOfBorg is interested in is by Samuel D. Leslie , but based on the broken one [09:58] There's a fixed patch in https://bugs.launchpad.net/debian/+source/gnutls28/+bug/1709193 [09:58] Ubuntu bug 1709193 in gnutls28 (Ubuntu Xenial) "Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer" [Undecided,Fix committed] [09:59] juliank, my bad i read those names as the saem, which is just wrong [09:59] So the realistic option is to rebase Samuel's patch on top of the updated patch for that bug [09:59] 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] apw, I might just add this one?https://launchpadlibrarian.net/334087516/lp1709193-14.04-version2.debdiff [10:11] 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] That is; '%VERIFY_ALLOW_SIGN_RSA_MD5' will allow RSA-MD5 signatures in certificate chains. [10:13] It's "OK" for self-signatures I guess, but I fear it might allow MD5 in general? [10:13] juliank, indeed that sounds like something we would want input from tyhicks on [10:13] 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] 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] (because the self-signature is irrelevant for a root cert) [10:19] * juliank is looking at gnutls git [10:20] This sound like it: https://gitlab.com/gnutls/gnutls/commit/b93ae1abf1b84fdc094f2474f1b2e4848081810e [10:20] But there might be other commits needed [10:30] juliank, well it seems to remove a lot of code ... otehr than that i am not sure [10:30] anyhow, we should wait on the security team feedback for that MD5 thing before we accept that SRU [10:31] Maybe just do LocutusOfBorg's one first without the other? [10:32] 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] juliank, i have added security to the bug, and pinged for an oppinion [10:33] 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] juliank, security people are very much like that [10:37] anyhow lets see what they say [10:49] 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] * for next week, really [10:50] I guess optimally I'd just patch launchpad to create diffs for synced packages... [10:53] I have the fake sync in the apt PPA already since Jul 18, so that would be ready to go :) [10:58] Though I do have to do a 1.4.8 anyway, so it might not be 1.4.7 entering [11:25] "just" [11:25] https://bugs.launchpad.net/launchpad/+bug/851562 [11:25] Ubuntu bug 851562 in Launchpad itself "Diffs not available for syncs on +queue page like for regular uploads" [High,Triaged] [11:30] cjwatson: :D [11:36] 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] We used to call the the "categorical just" in CS. <30 minute presentation>. "Isn't that just an instance of ?" [11:37] grr, gpg: signing failed: Card reset required [11:41] 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] (not tested, but since uploading changes...) [12:13] anybody on the release team time to check FFE on bug 1706248? [12:13] 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] 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] Laney, otherwise things fail to detect perl.h and FTBFS =/ [14:34] 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] update_excuses not update for three hours? [20:07] yep, looks like britney having a sad day [20:51] http://people.canonical.com/~ubuntu-archive/proposed-migration/log/artful/2017-09-06/ [20:51] seems running now [21:23] 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] RAOF: do we still have to do SRU's to zesty even though it is EOL? [23:10] Like, who cares if somebody upgrades to it and regresses, they're not supported anyway. [23:10] SpamapS: Zesty isn't EOL yet, is it?! [23:10] RAOF: 4/13/17 [23:10] oh haha [23:10] That's RELEASE date [23:11] derpaderp [23:11] I's smahrt [23:11] RAOF: carry on. ;) [23:11] I'll prep a zesty upload [23:11] I would be rather surprised if we EOL'd Zesty *before* we released Artful :) [23:15] 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] so not really wondering