[01:38] -queuebot:#ubuntu-release- Unapproved: exim4 (disco-proposed/main) [4.92-4ubuntu1 => 4.92-4ubuntu1.1] (ubuntu-server)
[05:21] <infinity> vorlon: Historically, we've never emptied proposed at EOL, we just snapshot it as "this is the way it was".  But ESM does make that a bit goofier, I guess.
[05:22] <infinity> vorlon: No strong opinion either way.  We could publish it to -updates, we could binary copy it to ESM (and leave it in proposed)...
[05:25] <infinity> vorlon: I'm even more confused about the seccomp that the security team uploaded (long) after ESMiness.
[05:47] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-amdgpu-hwe-18.04 (bionic-proposed/main) [18.1.0-1~18.04.1 => 19.0.1-1~18.04.1] (no packageset)
[05:47] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-nouveau-hwe-18.04 (bionic-proposed/main) [1:1.0.15-3~18.04.1 => 1:1.0.16-1~18.04.1] (no packageset)
[05:47] -queuebot:#ubuntu-release- Unapproved: xserver-xorg-video-ati-hwe-18.04 (bionic-proposed/main) [1:18.1.0-1~18.04.1 => 1:19.0.1-0ubuntu1~18.04.1] (no packageset)
[09:09] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-150.176] (core, kernel)
[09:16] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-150.176]
[09:33] <tjaalton> sil2100: is it your sru day? could you review libglvnd for bionic, it's been sitting on the queue for some weeks now
[09:34] <tjaalton> oh hang on, it's in proposed
[09:35] <tjaalton> huh, the upload never happened.. shame on me
[09:37] -queuebot:#ubuntu-release- Unapproved: libglvnd (bionic-proposed/main) [1.0.0-2ubuntu2.2 => 1.0.0-2ubuntu2.3] (core)
[09:37] <tjaalton> sil2100: nevermind :)
[09:39] <Laney> :D
[09:39] -queuebot:#ubuntu-release- Unapproved: cups (bionic-proposed/main) [2.2.7-1ubuntu2.5 => 2.2.7-1ubuntu2.6] (core)
[09:44] <sil2100> ;)
[09:44] <sil2100> tjaalton: I can try getting to it today, yes
[09:58] -queuebot:#ubuntu-release- Unapproved: cups (disco-proposed/main) [2.2.10-4ubuntu1 => 2.2.10-4ubuntu2] (core)
[10:13] <tjaalton> sil2100: i uploaded it *somewhere* earlier, since it had to be forced now
[10:14] <tjaalton> sil2100: and thanks, if you do
[10:14] -queuebot:#ubuntu-release- Unapproved: libpinyin (bionic-proposed/main) [2.1.91-1 => 2.2.2-1ubuntu0.18.04.1] (input-methods, ubuntu-desktop)
[10:15] -queuebot:#ubuntu-release- Unapproved: ibus-libpinyin (bionic-proposed/main) [1.9.2-2 => 1.11.0-1ubuntu0.18.04.1] (input-methods, ubuntu-desktop)
[10:25] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (disco-proposed) [2.578.6]
[10:30] -queuebot:#ubuntu-release- Unapproved: libpinyin (cosmic-proposed/main) [2.2.0-1 => 2.2.2-1ubuntu0.18.10.1] (input-methods, ubuntu-desktop)
[10:31] -queuebot:#ubuntu-release- Unapproved: ibus-libpinyin (cosmic-proposed/main) [1.10.0-1 => 1.11.0-1ubuntu0.18.10.1] (input-methods, ubuntu-desktop)
[10:34] -queuebot:#ubuntu-release- Unapproved: accepted tracker-miners [source] (disco-proposed) [2.1.6-1ubuntu1~19.04]
[10:48] -queuebot:#ubuntu-release- Unapproved: accepted gnome-control-center [source] (disco-proposed) [1:3.32.2-0ubuntu1]
[10:52] <sil2100> marcustomlinson: hey! Is it intentional that the disco libreoffice SRU has an interim UNRELEASED version in the changelog?
[10:53] <sil2100> I mean, it's probably not a blocking issue, but the changelog looks messy because of it
[11:00] -queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1008.9] (no packageset)
[11:12] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1008.9]
[11:35] <apw> sil2100, that is a very Debian thing to do, is it a Debian version in there ?
[11:41] <sil2100> apw: it looks like it yes
[11:45] -queuebot:#ubuntu-release- Unapproved: systemd (cosmic-proposed/main) [239-7ubuntu10.13 => 239-7ubuntu10.14] (core)
[11:46] -queuebot:#ubuntu-release- Unapproved: ktouch (disco-proposed/universe) [4:18.12.3-0ubuntu1 => 4:18.12.3-0ubuntu1.1] (kubuntu)
[11:48] -queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.21 => 237-3ubuntu10.22] (core)
[11:49] <sil2100> apw: I'll accept it in this case
[11:49] -queuebot:#ubuntu-release- Unapproved: rejected biosdevname [source] (bionic-proposed) [0.4.1-0ubuntu10.1]
[11:52] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (disco-proposed) [1:6.2.4-0ubuntu0.19.04.1]
[11:53] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice-l10n [source] (disco-proposed) [1:6.2.4-0ubuntu0.19.04.1]
[12:41] <jdstrand> infinity (cc vorlon): libseccomp should be out of -proposed today. there was some question on snapd and trusty/esm which is why it is there in the first place, but that got answered yesterday
[12:59] -queuebot:#ubuntu-release- Unapproved: cups (xenial-proposed/main) [2.1.3-4ubuntu0.8 => 2.1.3-4ubuntu0.9] (core)
[13:01] -queuebot:#ubuntu-release- Unapproved: zfs-linux (bionic-proposed/main) [0.7.5-1ubuntu16.4 => 0.7.5-1ubuntu16.6] (core)
[13:17] -queuebot:#ubuntu-release- Unapproved: libio-socket-ssl-perl (bionic-proposed/main) [2.056-1 => 2.060-3~ubuntu18.04.1] (core) (sync)
[14:41] <infinity> jdstrand: But why was it there in the first place, that was the question.
[14:46] -queuebot:#ubuntu-release- Unapproved: rejected osgearth [sync] (trusty-updates) [2.4.0+dfsg-6]
[14:52] <sil2100> infinity: I think I heard jdstrand mentioning they put it there for it to get wider testing or something
[14:56] -queuebot:#ubuntu-release- Unapproved: accepted libglvnd [source] (bionic-proposed) [1.0.0-2ubuntu2.3]
[14:58] <vorlon> xnox: tweaked the test case for libwww-perl slightly on the openssl.l.l bug, to ensure we actually test the Breaks
[14:58] <xnox> vorlon:  oooh, ok.
[15:01] -queuebot:#ubuntu-release- Unapproved: accepted libwww-perl [sync] (bionic-proposed) [6.31-1ubuntu0.1]
[15:13] -queuebot:#ubuntu-release- Unapproved: accepted libio-socket-ssl-perl [sync] (bionic-proposed) [2.060-3~ubuntu18.04.1]
[15:14] -queuebot:#ubuntu-release- Unapproved: accepted libpinyin [source] (cosmic-proposed) [2.2.2-1ubuntu0.18.10.1]
[15:29] <vorlon> xnox: the patch against libnet-ssleay-perl patches the documentation to include statements that certain features are not available in this version of net-ssleay
[15:30] <vorlon> xnox: do we care about the misleading docs? (or is there a fix-up patch I haven't gotten to yet in the review)
[15:31] <xnox> vorlon:  i think some of those docs are not lies, as the missing bits got implemented in 1.88 only which is in eoan
[15:31] <xnox> vorlon:  and i did not yet think about backporting that, or not.
[15:34] <vorlon> xnox: ok
[15:37] <vorlon> xnox: one of the patches added is to ignore unexpected SIGPIPE being raised during tests; have you considered whether this behavior change will raise unexpected SIGPIPE on real-world use cases and be a regression risk?
[15:38] <xnox> vorlon:  as far as i recall, no. it was merged as test-suite flakiness rather than TLS1.3
[15:43] <vorlon> xnox: ok; can you consider now whether there's regression risk there?
[15:43] <vorlon> and would it be gauche for the perl library itself to ignore SIGPIPE
[15:52] -queuebot:#ubuntu-release- Unapproved: libpinyin (cosmic-proposed/main) [2.2.0-1 => 2.2.2-1~ubuntu18.10.1] (input-methods, ubuntu-desktop)
[15:54] -queuebot:#ubuntu-release- Unapproved: libpinyin (bionic-proposed/main) [2.1.91-1 => 2.2.2-1~ubuntu18.04.1] (input-methods, ubuntu-desktop)
[15:56] -queuebot:#ubuntu-release- Unapproved: rejected libpinyin [source] (bionic-proposed) [2.2.2-1ubuntu0.18.04.1]
[15:58] -queuebot:#ubuntu-release- Unapproved: accepted libpinyin [source] (cosmic-proposed) [2.2.2-1~ubuntu18.10.1]
[16:00] -queuebot:#ubuntu-release- Unapproved: accepted libpinyin [source] (bionic-proposed) [2.2.2-1~ubuntu18.04.1]
[16:08] <jdstrand> infinity: I put it there because snapd development encompasses more than just the deb and I a) thought it was going to be supported in sem and b) didn't think that the snapd team would be able to pull in the esm ppa in all the places it would need it (ie, travis, spread tests, what have you)
[16:08] <vorlon> debian/patches/Move-SSL_ERROR_WANT_READ-SSL_ER
[16:08] <vorlon> oops
[16:09] <vorlon> xnox: debian/patches/Move-SSL_ERROR_WANT_READ-SSL_ERROR_WANT_WRITE-retry-.patch also looks like an interesting behavior change to the Net::SSLeay api, read/write change behavior to not retry?
[16:10] <jdstrand> infinity: so if it was going to be supported I thought for this upload going to trusty-security might make it easier for them to transition to using esm in their project. as it turns out, as of right now, they aren't going to have snapd in esm, so I will push libseccomp to trusty/esm and delete from -proposed
[16:11] <jdstrand> infinity: and I told them if the decision changes wrt snapd/trusty/esm, to come to us so we can work together on a plan for them building/testing/delivering snapd debs via esm
[16:13] <jdstrand> infinity: as to why libseccomp is in any of -proposed, yes, sil2100 is right, we wanted wider testing. the non-trusty releases will go to -security
[16:14] <jdstrand> I'm working to publish the USN for it today
[16:32] -queuebot:#ubuntu-release- Unapproved: accepted ibus-libpinyin [source] (cosmic-proposed) [1.11.0-1ubuntu0.18.10.1]
[16:34] -queuebot:#ubuntu-release- Unapproved: accepted ibus-libpinyin [source] (bionic-proposed) [1.11.0-1ubuntu0.18.04.1]
[16:40] <xnox> vorlon:  yes, which is now inline with what openssl told everyone to do.... also note that it's unusual to see those errors from openssl pre-tls1.3 as well.
[16:41] <xnox> vorlon:  i wish i knew how much stuff uses perl for openssl. especially server side, rather than just client.
[16:42] <xnox> however i hope that people normally have their webserver do tls for them
[16:52] <vorlon> xnox: then I think this needs to be called out in the bug as regression potential and say that it's a risk of regression whose impact is currently unknown and we're willing to accept that risk
[17:22] <vorlon> xnox: I'm unsure if the change in SIGPIPE behavior also has the potential to affect non-perl users of lissl
[17:27] <vorlon> xnox: I've written up the regression potential for libnet-ssleay-perl and reading it does not give me warm fuzzies about accepting this package.  I think the API change to read/write/ssl_read_all/ssl_write_all should be reverted and the tests fixed otherwise
[18:23] -queuebot:#ubuntu-release- Unapproved: cups (cosmic-proposed/main) [2.2.8-5ubuntu1.3 => 2.2.8-5ubuntu1.4] (core)
[19:09] <vorlon> ubuntu-mate/daily-live: eoan-desktop-amd64.iso oversized by 61582336 bytes
[19:09] <vorlon> that's a fair number of bytes
[19:10] <vorlon> Wimpress: ^^ was that something you're still planning to slim down, or raise the limit on?
[19:12] <Wimpress> vorlon: I did slim it down, considerably.
[19:12] <Wimpress> But now I have added the nvidia drivers to the shipl-live seed.
[19:14] <Wimpress> Which add ~115MB to the image.
[19:16] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (disco-proposed/main) [2.578.4 => 2.578.5] (desktop-core)
[19:34] <vorlon> rbasak: why do you say it was wrong to continue overriding the pcs autopkgtests which have always been garbage?
[19:36] <vorlon> rbasak: (more precisely, they regressed when /etc/init.d/networking stopped being part of the system)
[20:50] <xnox> vorlon:  shall we do a codesearch of users of read/write?
[20:51] <vorlon> that wouldn't catch 3rd party software
[20:52] <vorlon> xnox: wouldn't it be better to revert the api change, and fix whatever the other problem was with the tests?
[20:53] <xnox> vorlon:  the other problem is that TLSv1.3 started to generate a lot more WANT_READ WANT_WRITE errors, and they were never been properly testing with TLSv1.2 as no renegotiation was done.
[20:53] <xnox> and for people to install hooks they need access to a non-eating read/write......
[20:54] <vorlon> xnox: so we can't sanely support TLSv1.3 from perl without changing the API?
[20:54] <vorlon> OTOH
[20:54] <vorlon> wouldn't it be better to not support TLS1.3 from perl than to break existing third-party code?
[20:55] <xnox> vorlon:  i had an upload to cap context at tls1.2 and be done with it
[20:55] <xnox> vorlon:  but that also means nobody gets tls1.3
[20:55] <xnox> defeating a bit the point of this sru.....
[20:55] <xnox> vorlon:  also 3rd party software in perl?!
[20:56] <vorlon> xnox: I thought the point of sruing the perl bindings is to make sure updating openssl /didn't break the perl bindings/, not to enable TLSv1.3 support in perl
[20:56] <vorlon> I would be happier with capping perl @ 1.2 than breaking the API
[20:59] <xnox> vorlon:  https://paste.ubuntu.com/p/D76nnxWNnY/ is the patch i had around for while whilst the hang drama was ongoing
[21:00] <xnox> it is unexpected behaviour. cause max_proto would be set
[21:00] <xnox> but that only covers i think the CTX api only
[21:00] <xnox> not the SSL api
[21:00] <vorlon> xnox: if you wanted to do the work, I think we could in principle make read/write return short reads only for TLSv1.3; retain the existing behavior for earlier protocol versions; and cap to TLSv1.2 by default requiring someone to opt in from the perl code
[21:01] <vorlon> but barring that, I would still rather cap to 1.2 now, avoid changing the api, and possibly deal with perl 1.3 support later in a separate SRU
[21:01] <xnox> ok
[21:01] <xnox> let me have a cup of tea
[21:19] -queuebot:#ubuntu-release- Unapproved: libseccomp (disco-security/main) [2.4.1-0ubuntu0.19.04.3 => 2.4.1-0ubuntu0.19.04.3] (core) (sync)
[21:19] <xnox> vorlon:  wait a minute.
[21:20] -queuebot:#ubuntu-release- Unapproved: libseccomp (cosmic-security/main) [2.4.1-0ubuntu0.18.10.3 => 2.4.1-0ubuntu0.18.10.3] (core) (sync)
[21:20] <xnox> vorlon:  "SSL_MODE_AUTO_RETRY has been made the default"
[21:21] -queuebot:#ubuntu-release- Unapproved: libseccomp (bionic-security/main) [2.4.1-0ubuntu0.18.04.2 => 2.4.1-0ubuntu0.18.04.2] (core) (sync)
[21:21] <xnox> https://wiki.openssl.org/index.php/TLS1.3#Non-application_data_records
[21:21] <xnox> so ssl_read()/ssl_write() should be auto-consuming things anyway.......
[21:21] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.48 => 2.408.49] (desktop-core)
[21:21] -queuebot:#ubuntu-release- Unapproved: libseccomp (xenial-security/main) [2.4.1-0ubuntu0.16.04.2 => 2.4.1-0ubuntu0.16.04.2] (core) (sync)
[21:21] <vorlon> xnox: ah
[21:22] <vorlon> xnox: in that case feel free to edit the regression-potential text back
[21:22] -queuebot:#ubuntu-release- Unapproved: accepted libseccomp [sync] (disco-security) [2.4.1-0ubuntu0.19.04.3]
[21:22] <xnox> vorlon:  but that also has the blocking/non-blocking sockets caveats.
[21:22] -queuebot:#ubuntu-release- Unapproved: accepted libseccomp [sync] (bionic-security) [2.4.1-0ubuntu0.18.04.2]
[21:22] -queuebot:#ubuntu-release- Unapproved: accepted libseccomp [sync] (cosmic-security) [2.4.1-0ubuntu0.18.10.3]
[21:22] <xnox> i think i want to double check with upstream on that.
[21:23] -queuebot:#ubuntu-release- Unapproved: accepted libseccomp [sync] (xenial-security) [2.4.1-0ubuntu0.16.04.2]
[21:23] <xnox> vorlon:  also upstream does cross-test a wide matrix of openssl releases, perl releases, and the perl library.
[21:23] <xnox> they test like all the combinations possible back to forever, and multiple openssl versions & implementations
[21:24] <vorlon> ok
[22:18] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.49]
[22:21] <Eickmeyer> Is there an AA that can process lsp-plugins in the NEW queue?
[22:22] <Eickmeyer> Also, we (the Ubuntu Studio team) now have two packages that need sponsoring.  (bug 1829562 and bug 1831154)
[22:23] <Eickmeyer> Expect more new packages for Ubuntu Studio this cycle. We're WAY behind, and still playing catch-up after the two years of stagnation.
[23:06] <rbasak> vorlon: the pcs autopkgtest might have been garbage before, and may well still be, but the failures in Disco for 0.10 AIUI was a true positive - it correctly failed due to an installability problem that correctly should have blocked proposed migration before it got any further (to something that may or may not be correct - I haven't looked)
[23:07] <rbasak> vorlon: the errors changed.
[23:21] <xnox> but we can't tell the difference between always failed, and always failed but differently now.
[23:21] <xnox> unless there is uninstallability return codes that are returned back to britney? ie. "can't even install"
[23:28] <rbasak> xnox: I was under the impression that the whole point of a versioned badtest was that there would be a manual check before bumping the version forward.
[23:28] <rbasak> I suppose another reason is that if it starts magically working then it won't be ignored forever.
[23:29] <rbasak> But if all we're doing is bumping it forward blindly if it is still failing, then what's the point of doing it manually like this?
[23:30] <rbasak> Anyway, I need to go.
[23:30] <rbasak> I'll check back later.