[00:01] -queuebot:#ubuntu-release- Unapproved: accepted rust-crossbeam-utils [sync] (disco-proposed) [0.5.0-1] [00:07] at least this one seems to be an accident [00:07] heh [00:08] infinity: well, having a new s390-tools in the archive that works when removed-not-purged only helps if the new version is in the autopkgtest image to get removed :/ [00:14] -queuebot:#ubuntu-release- New binary: rust-iovec [ppc64el] (disco-proposed/universe) [0.1.2-1] (no packageset) [00:14] -queuebot:#ubuntu-release- New binary: rust-iovec [s390x] (disco-proposed/universe) [0.1.2-1] (no packageset) [00:15] -queuebot:#ubuntu-release- New binary: rust-iovec [amd64] (disco-proposed/universe) [0.1.2-1] (no packageset) [00:15] -queuebot:#ubuntu-release- New binary: rust-iovec [i386] (disco-proposed/universe) [0.1.2-1] (no packageset) [00:17] -queuebot:#ubuntu-release- Unapproved: rust-crossbeam-epoch (disco-proposed/universe) [0.5.1-1 => 0.5.2-1] (no packageset) (sync) [00:17] -queuebot:#ubuntu-release- New: accepted rust-iovec [amd64] (disco-proposed) [0.1.2-1] [00:17] -queuebot:#ubuntu-release- New: accepted rust-iovec [ppc64el] (disco-proposed) [0.1.2-1] [00:17] -queuebot:#ubuntu-release- New binary: rust-iovec [arm64] (disco-proposed/universe) [0.1.2-1] (no packageset) [00:17] -queuebot:#ubuntu-release- New: accepted rust-iovec [i386] (disco-proposed) [0.1.2-1] [00:17] -queuebot:#ubuntu-release- New: accepted rust-iovec [s390x] (disco-proposed) [0.1.2-1] [00:20] -queuebot:#ubuntu-release- New: accepted rust-iovec [arm64] (disco-proposed) [0.1.2-1] [00:20] -queuebot:#ubuntu-release- Unapproved: accepted rust-crossbeam-epoch [sync] (disco-proposed) [0.5.2-1] [00:25] https://github.com/pygraphviz/pygraphviz/issues/175 :( [00:25] pygraphviz issue 175 in pygraphviz "Test failures with Graphviz 2.40.1" [Open] [00:33] -queuebot:#ubuntu-release- New binary: rust-crossbeam-deque [s390x] (disco-proposed/universe) [0.6.1-1] (no packageset) [00:34] -queuebot:#ubuntu-release- New binary: rust-mio [amd64] (disco-proposed/universe) [0.6.16-1] (no packageset) [00:35] -queuebot:#ubuntu-release- New: accepted rust-crossbeam-deque [s390x] (disco-proposed) [0.6.1-1] [00:35] -queuebot:#ubuntu-release- New: accepted rust-mio [amd64] (disco-proposed) [0.6.16-1] [00:35] 'rust-fuchsia-zircon-sys' why are rust package names alchemical formulas? [00:35] -queuebot:#ubuntu-release- New binary: rust-crossbeam-deque [ppc64el] (disco-proposed/universe) [0.6.1-1] (no packageset) [00:36] -queuebot:#ubuntu-release- New: accepted rust-crossbeam-deque [ppc64el] (disco-proposed) [0.6.1-1] [00:44] i think that one is probably all fuschia's fault [00:44] https://github.com/fuchsia-mirror/zircon [00:45] -queuebot:#ubuntu-release- Unapproved: python-pygraphviz (disco-proposed/universe) [1.4~rc1-1build4 => 1.4~rc1-1ubuntu1] (no packageset) [01:03] bdmurray: Thank you. [01:06] -queuebot:#ubuntu-release- New binary: rust-rayon-core [amd64] (disco-proposed/universe) [1.4.1-1] (no packageset) [01:06] -queuebot:#ubuntu-release- New binary: rust-rayon-core [ppc64el] (disco-proposed/universe) [1.4.1-1] (no packageset) [01:06] -queuebot:#ubuntu-release- New binary: rust-rayon-core [i386] (disco-proposed/universe) [1.4.1-1] (no packageset) [01:06] -queuebot:#ubuntu-release- New binary: rust-rayon-core [s390x] (disco-proposed/universe) [1.4.1-1] (no packageset) [01:07] -queuebot:#ubuntu-release- New: accepted rust-rayon-core [i386] (disco-proposed) [1.4.1-1] [01:07] -queuebot:#ubuntu-release- New: accepted rust-rayon-core [amd64] (disco-proposed) [1.4.1-1] [01:07] -queuebot:#ubuntu-release- New: accepted rust-rayon-core [s390x] (disco-proposed) [1.4.1-1] [01:07] -queuebot:#ubuntu-release- New: accepted rust-rayon-core [ppc64el] (disco-proposed) [1.4.1-1] [01:07] -queuebot:#ubuntu-release- New binary: rust-rayon-core [arm64] (disco-proposed/universe) [1.4.1-1] (no packageset) [01:08] -queuebot:#ubuntu-release- New: accepted rust-rayon-core [arm64] (disco-proposed) [1.4.1-1] [01:08] bdmurray, vorlon: Would it be too late tonight to process src:libreoffice in cosmic UNAPPROVED? [01:09] infinity: Er, I guess, tag, you're it, says the wiki? ^ [01:09] ¯\_(ツ)_/¯ [01:09] *whoever* :) [01:09] Could you elaborate on the patch without a Launchpad bug? [01:11] The LibreOffice theme by default is set to an X11-style design under the LXQt desktop, which is (sorry LibreOffice developers) extremely ugly. [01:11] This changes it to use the Breeze theme by default, but only under the LXQt desktop. [01:12] tsimonq2: I'm talking about "Backport a patch from upstream which fixes testcases with OpenJDK 11." [01:12] Oh. [01:13] It was taken from doko's fix in Disco: https://launchpad.net/ubuntu/+source/libreoffice/1:6.1.2-0ubuntu3 and if I recall correctly, this is because he switched the default OpenJDK ~ release day last cycle. [01:14] The patch is from oSoMoN if it makes a difference: https://github.com/LibreOffice/core/commit/10a5880db7df9c3573e1562615f86fe9a211bc56 [01:14] It removes a reference to a file that is no longer generated. [01:14] What's really broken though? [01:14] The build is broken. :P [01:15] Here's a build under Cosmic with just the Breeze fix: https://launchpad.net/~tsimonq2/+archive/ubuntu/upload-testing/+sourcepub/9494952/+listing-archive-extra [01:17] there is a bug for it: LP: #1796361 [01:17] Launchpad bug 1796361 in libreoffice (Ubuntu) "autopkgtests fail with openjdk 11~28-3ubuntu1 in cosmic-proposed" [Medium,In progress] https://launchpad.net/bugs/1796361 [01:17] tsimonq2: Oh, how about a re-upload with an LP bug reference then. [01:18] and the fix is fine, I checked it some time ago [01:18] Aha, I didn't know there *was* a bug to reference. :) [01:18] I'll be back in a bit to review / accept it. [01:18] Sure, thanks. [01:18] -queuebot:#ubuntu-release- New binary: rust-rayon [ppc64el] (disco-proposed/universe) [1.0.2-1] (no packageset) [01:18] -queuebot:#ubuntu-release- New binary: rust-rayon [s390x] (disco-proposed/universe) [1.0.2-1] (no packageset) [01:18] tsimonq2: thanks for driving this ;-) [01:19] No problem. :) [01:19] -queuebot:#ubuntu-release- New binary: rust-rayon [amd64] (disco-proposed/universe) [1.0.2-1] (no packageset) [01:20] hmm, I was not aware this was pushed to disco, but then the bug # was not referenced on the changelog [01:20] -queuebot:#ubuntu-release- New: accepted rust-rayon [amd64] (disco-proposed) [1.0.2-1] [01:20] -queuebot:#ubuntu-release- New: accepted rust-rayon [s390x] (disco-proposed) [1.0.2-1] [01:20] -queuebot:#ubuntu-release- New: accepted rust-rayon [ppc64el] (disco-proposed) [1.0.2-1] [01:20] -queuebot:#ubuntu-release- New binary: rust-rayon [i386] (disco-proposed/universe) [1.0.2-1] (no packageset) [01:21] -queuebot:#ubuntu-release- New: accepted rust-rayon [i386] (disco-proposed) [1.0.2-1] [01:37] -queuebot:#ubuntu-release- Unapproved: python-networkx (disco-proposed/main) [2.1-1ubuntu2 => 2.1-1ubuntu3] (ubuntu-server) [01:40] if someone could approve python-pygraphviz, that would be grant [01:40] *grand [01:40] because then i can upload a fixed botch [02:02] -queuebot:#ubuntu-release- Unapproved: libreoffice (cosmic-proposed/main) [1:6.1.2-0ubuntu1 => 1:6.1.2-0ubuntu1.1] (kubuntu, ubuntu-desktop) [02:03] bdmurray: Your follow-up upload. ^ [02:40] -queuebot:#ubuntu-release- Unapproved: rejected libreoffice [source] (cosmic-proposed) [1:6.1.2-0ubuntu1.1] [03:42] Any reason why mutter was rejected for bionic SRU? [03:42] https://launchpad.net/ubuntu/bionic/+queue?queue_state=4&queue_text=mutter [06:20] -queuebot:#ubuntu-release- Unapproved: accepted python-networkx [source] (disco-proposed) [2.1-1ubuntu3] [06:20] -queuebot:#ubuntu-release- Unapproved: accepted python-pysnmp4 [sync] (disco-proposed) [4.4.6+repack1-1] [06:20] -queuebot:#ubuntu-release- Unapproved: accepted python-pygraphviz [source] (disco-proposed) [1.4~rc1-1ubuntu1] [07:36] -queuebot:#ubuntu-release- Unapproved: rejected libreoffice [source] (disco-proposed) [1:6.1.3-0ubuntu1] [07:36] -queuebot:#ubuntu-release- Unapproved: rejected sosreport [sync] (disco-proposed) [3.6-1] [07:36] -queuebot:#ubuntu-release- Unapproved: accepted odb-api [sync] (disco-proposed) [0.18.0-6] [08:30] -queuebot:#ubuntu-release- Unapproved: python-dbusmock (disco-proposed/universe) [0.18-1 => 0.18-1ubuntu1] (no packageset) [08:33] -queuebot:#ubuntu-release- Unapproved: python-setuptools (disco-proposed/main) [40.2.0-1 => 40.5.0-1] (core) [08:34] -queuebot:#ubuntu-release- Unapproved: accepted python-dbusmock [source] (disco-proposed) [0.18-1ubuntu1] [08:34] -queuebot:#ubuntu-release- Unapproved: accepted python-setuptools [source] (disco-proposed) [40.5.0-1] [08:36] vorlon, infinity, Laney: I'd like to document the remaining blockers for python3-defaults, and propose to migrate it. main reason is that tests are all triggered with 3.6 as supported. and just removing 3.6 doesn't add any new regressions [08:40] -queuebot:#ubuntu-release- Unapproved: commonmark-bkrs (disco-proposed/universe) [0.5.4+ds-1 => 0.5.4+ds-1ubuntu1] (no packageset) [08:44] -queuebot:#ubuntu-release- Unapproved: accepted commonmark-bkrs [source] (disco-proposed) [0.5.4+ds-1ubuntu1] [08:46] doko: i'm not against it, but it's pretty clear that something went wrong with the autopkgtest for some packages when 3.7 was made the default [08:47] doko: check the http://autopkgtest.ubuntu.com/packages/libc/libcloud/disco/amd64 run triggered by python3-defaults/3.7.1-1, that didn't actually test python3.7 [08:47] (if it did, it would have failed) [08:48] yeah, that's another thing to investigate. but the previous migration was all green [08:51] -queuebot:#ubuntu-release- Unapproved: minieigen (disco-proposed/universe) [0.50.3+dfsg1-5ubuntu4 => 0.50.3+dfsg1-5ubuntu5] (no packageset) [08:52] -queuebot:#ubuntu-release- Unapproved: accepted minieigen [source] (disco-proposed) [0.50.3+dfsg1-5ubuntu5] [08:54] well ok i have no idea what happened to python-dbusmock, it doesn't do that locally [08:57] infinity, thanks for odb-api! :) I was going to do the same exacly some seconds ago [09:09] -queuebot:#ubuntu-release- Unapproved: botch (disco-proposed/universe) [0.21-6ubuntu2 => 0.21-6ubuntu3] (no packageset) [09:09] -queuebot:#ubuntu-release- Unapproved: mutter (bionic-proposed/main) [3.28.3-2~ubuntu18.04.1 => 3.28.3-2~ubuntu18.04.2] (desktop-extra, ubuntu-desktop) [09:15] -queuebot:#ubuntu-release- Unapproved: accepted botch [source] (disco-proposed) [0.21-6ubuntu3] [09:26] did vorlon submit duplicate perl/s390x jobs? [09:29] aha, you fixed s390-tools [09:29] -queuebot:#ubuntu-release- Unapproved: gcc-6-cross (disco-proposed/universe) [33ubuntu1 => 34ubuntu1] (no packageset) [09:31] -queuebot:#ubuntu-release- Unapproved: accepted gcc-6-cross [source] (disco-proposed) [34ubuntu1] [10:01] * mwhudson zzz [10:02] doko: IMO document first, then consider a hint [10:03] if it was previously all green (falsely given mwhudson's comments?) then there may be some actual problems here? [10:03] Laney: no, it wasn't triggered, so no information about if it failed or not [10:05] -queuebot:#ubuntu-release- Unapproved: snapd (disco-proposed/main) [2.35.5+18.10 => 2.35.5+18.10ubuntu1] (desktop-core, ubuntu-server) [10:05] well, still cannot build server installation media... async is a reserved keyword. [10:06] https://bugs.launchpad.net/maas/+bug/1801899 [10:06] Ubuntu bug 1801899 in maas (Ubuntu) "cannot install with python3.7 as default async is a reserved keyword" [Critical,New] [10:06] -queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (disco-proposed) [2.35.5+18.10ubuntu1] [10:07] what wasn't triggered? [10:17] doko, please RM https://bugs.launchpad.net/debian/+source/libextutils-parsexs-perl/+bug/1801901 for perl transition [10:17] Ubuntu bug 1801901 in libextutils-parsexs-perl (Ubuntu) "RM libextutils-parsexs-perl broken with new perl" [Undecided,New] [10:20] Laney: libcloud [10:21] but also murano, ironic, ... [10:21] there's a trigger from python3-defaults 3.7.1-1 there [10:21] and why did it succeed? [10:21] you tell me [10:31] -queuebot:#ubuntu-release- Unapproved: libsoup2.4 (disco-proposed/main) [2.64.1-1 => 2.64.1-3] (core) (sync) [10:31] -queuebot:#ubuntu-release- Unapproved: libdazzle (disco-proposed/main) [3.30.1-1 => 3.30.1-2] (ubuntu-desktop) (sync) [10:32] -queuebot:#ubuntu-release- Unapproved: network-manager-openvpn (disco-proposed/main) [1.8.6-1ubuntu1 => 1.8.8-1] (ubuntu-desktop) (sync) [10:47] Laney: ahh, that might be, because openstack did run with python3.6 explicitly... jamespage might confirm that [10:54] -queuebot:#ubuntu-release- Unapproved: matplotlib (disco-proposed/universe) [2.2.2-4build2 => 2.2.2-4ubuntu1] (ubuntustudio) [10:54] -queuebot:#ubuntu-release- Unapproved: accepted matplotlib [source] (disco-proposed) [2.2.2-4ubuntu1] [11:46] doko: I think we did that with a couple of pkgs [11:46] it should be noted in d/rules === M_hc is now known as _hc [12:18] doko, please accept llvm-toolchain-7 [12:19] it should fix testsuite, regressions and intel-mkt failures and make everything migrate [12:19] jamespage: so how do you want to address murano, libcloud, ironic? just ignore the test results to let python3-defaults migrate? [12:20] -queuebot:#ubuntu-release- Unapproved: llvm-toolchain-7 (disco-proposed/main) [1:7-8 => 1:7-9~build1] (kubuntu, ubuntu-desktop) [12:25] -queuebot:#ubuntu-release- Unapproved: matplotlib (disco-proposed/universe) [2.2.2-4ubuntu1 => 2.2.2-4ubuntu2] (ubuntustudio) [12:29] -queuebot:#ubuntu-release- Unapproved: accepted matplotlib [source] (disco-proposed) [2.2.2-4ubuntu2] [12:48] -queuebot:#ubuntu-release- Unapproved: mod-wsgi (disco-proposed/main) [4.5.17-1build1 => 4.5.17-1build2] (ubuntu-server) [12:50] please accept llvm [12:50] -queuebot:#ubuntu-release- Unapproved: shiboken (disco-proposed/universe) [1.2.2-5.1 => 1.2.2-5.1build1] (no packageset) [12:51] -queuebot:#ubuntu-release- Unapproved: kdevelop-python (disco-proposed/universe) [5.2.4-1 => 5.2.4-1build1] (kubuntu) [12:53] -queuebot:#ubuntu-release- Unapproved: accepted kdevelop-python [source] (disco-proposed) [5.2.4-1build1] [12:53] -queuebot:#ubuntu-release- Unapproved: accepted shiboken [source] (disco-proposed) [1.2.2-5.1build1] [12:53] -queuebot:#ubuntu-release- Unapproved: accepted mod-wsgi [source] (disco-proposed) [4.5.17-1build2] [12:58] -queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-7 [source] (disco-proposed) [1:7-9~build1] [13:06] infinity, fun fact, we have packages on the desktop image that ship broken symlinks. I choose to allow them to be blacklisted, as there is no way to know if they are broken symlinks to a file or a dir. [13:14] are seed changes allowed in disco, or is that also frozen for the moment? [13:14] https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu/+merge/358160 specifically [13:46] -queuebot:#ubuntu-release- Unapproved: stress-ng (disco-proposed/universe) [0.09.42-1 => 0.09.44-1] (no packageset) (sync) [13:46] Laney, infinity https://code.launchpad.net/~ubuntu-installer/ubiquity/+git/ubiquity/+merge/358383 [13:50] -queuebot:#ubuntu-release- Unapproved: libcloud (disco-proposed/universe) [2.3.0-1ubuntu2 => 2.3.0-3] (no packageset) (sync) [13:54] -queuebot:#ubuntu-release- Unapproved: accepted libcloud [sync] (disco-proposed) [2.3.0-3] [13:54] -queuebot:#ubuntu-release- Unapproved: magics++ (disco-proposed/universe) [3.2.1-1 => 3.2.1-2~build1] (no packageset) [14:02] doko, ^^ this fixes metview [14:05] -queuebot:#ubuntu-release- Unapproved: accepted magics++ [source] (disco-proposed) [3.2.1-2~build1] [14:12] xnox: don't have much context for this :( [14:13] what's the blacklist about even? [15:03] -queuebot:#ubuntu-release- Unapproved: scikit-learn (disco-proposed/universe) [0.19.2-1ubuntu2 => 0.19.2-1ubuntu3] (no packageset) [15:09] -queuebot:#ubuntu-release- Unapproved: python-biopython (disco-proposed/universe) [1.72-0ubuntu1 => 1.72-0ubuntu2] (no packageset) [15:11] Laney, i.e. skip unselected language-packs, ubiquity itself, unselected fs-utils, full-desktop, etc. every single file which is _not_ copied from the mounted squashfs. [15:11] i mean, if we had stacked squashfs and not excludes we'd be fine..... but it is complicated. [15:13] -queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (cosmic-proposed) [1:6.1.2-0ubuntu1.1] [15:16] -queuebot:#ubuntu-release- Unapproved: accepted python-biopython [source] (disco-proposed) [1.72-0ubuntu2] [15:16] -queuebot:#ubuntu-release- Unapproved: accepted scikit-learn [source] (disco-proposed) [0.19.2-1ubuntu3] [15:17] Laney, given the debug pain, i wonder if i should just upload that into disco. cause currently it is completely bust and cannot install anything at all. [15:21] -queuebot:#ubuntu-release- Unapproved: ecflow (disco-proposed/universe) [4.10.0-2ubuntu2 => 4.11.1-1ubuntu1] (no packageset) [15:24] -queuebot:#ubuntu-release- Unapproved: accepted ecflow [source] (disco-proposed) [4.11.1-1ubuntu1] [15:25] -queuebot:#ubuntu-release- Unapproved: desktop-file-utils (disco-proposed/main) [0.23-3ubuntu2 => 0.23-4ubuntu1] (desktop-core) [15:25] -queuebot:#ubuntu-release- Unapproved: spl-linux (disco-proposed/universe) [0.7.9-3ubuntu2 => 0.7.11-1ubuntu1] (no packageset) [15:27] -queuebot:#ubuntu-release- Unapproved: desktop-file-utils (cosmic-proposed/main) [0.23-3ubuntu2 => 0.23-3ubuntu3] (desktop-core) [15:27] -queuebot:#ubuntu-release- Unapproved: zfs-linux (disco-proposed/main) [0.7.9-3ubuntu6 => 0.7.11-3ubuntu1] (core) [15:33] -queuebot:#ubuntu-release- Unapproved: desktop-file-utils (bionic-proposed/main) [0.23-1ubuntu3.18.04.1 => 0.23-1ubuntu3.18.04.2] (desktop-core) [15:41] -queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (disco-proposed/main) [3.30.0-1ubuntu3 => 3.30.0-1ubuntu4] (ubuntu-desktop, ubuntugnome) [15:42] -queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (bionic-proposed/main) [3.28.0-2ubuntu6.16.04.3 => 3.30.0-1ubuntu3.1] (ubuntugnome) [15:44] -queuebot:#ubuntu-release- Unapproved: bolt (bionic-proposed/main) [0.4-0ubuntu0.18.04.1 => 0.5-0ubuntu0.18.04.1] (ubuntu-desktop) [15:54] -queuebot:#ubuntu-release- New binary: metview [s390x] (disco-proposed/universe) [5.2.1-1ubuntu1] (no packageset) [15:58] -queuebot:#ubuntu-release- Unapproved: accepted mokutil [source] (xenial-proposed) [0.3.0+1538710437.fb6250f-0ubuntu2~16.04.1] [15:59] -queuebot:#ubuntu-release- Unapproved: accepted mokutil [source] (trusty-proposed) [0.3.0+1538710437.fb6250f-0ubuntu2~14.04.1] [16:04] -queuebot:#ubuntu-release- New binary: metview [i386] (disco-proposed/universe) [5.2.1-1ubuntu1] (no packageset) [16:09] -queuebot:#ubuntu-release- Unapproved: udisks2 (disco-proposed/main) [2.7.6-3ubuntu3 => 2.8.1-2] (desktop-core, ubuntu-server) (sync) [16:17] -queuebot:#ubuntu-release- New binary: metview [ppc64el] (disco-proposed/universe) [5.2.1-1ubuntu1] (no packageset) [16:26] -queuebot:#ubuntu-release- Unapproved: firefox (disco-proposed/main) [63.0+build2-0ubuntu0.18.10.2 => 63.0.1+build4.1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop) [16:38] -queuebot:#ubuntu-release- Unapproved: kdevelop-python (disco-proposed/universe) [5.2.4-1build1 => 5.2.4-1ubuntu1] (kubuntu) [16:38] -queuebot:#ubuntu-release- Unapproved: accepted kdevelop-python [source] (disco-proposed) [5.2.4-1ubuntu1] [16:39] -queuebot:#ubuntu-release- Unapproved: rejected firefox [source] (disco-proposed) [63.0.1+build4-0ubuntu1] [16:39] xnox: '/' in relpath is going to return true for any target with a / anywhere in it. [16:39] xnox: Not just top-levels. [16:40] infinity, this is very convenient list "sbin" "usr/sbin" are the relpaths here. hence we prepend '/' to look up things in the blacklist [16:40] infinity, hence '/' in relpath is only true for subdiry things. [16:40] xnox: But you'd also potentially leave other cruft around. [16:41] xnox: I have plenty of symlinks on my system with / in the target that aren't the ones you want to keep. :P [16:41] infinity, i wish you were in #ubuntu-installer to follow a long chat i had with Laney [16:42] xnox: Would that chat somehow prove me wrong? [16:42] xnox: Cause I'm pretty sure it wouldn't. [16:42] -queuebot:#ubuntu-release- New binary: metview [amd64] (disco-proposed/universe) [5.2.1-1ubuntu1] (no packageset) [16:42] infinity, i'm never testing '/' in target..... [16:42] only the source-stem filename [16:43] xnox: Oh, I'm reading it backwards indeed. [16:43] infinity, option 1 - https://code.launchpad.net/~ubuntu-installer/ubiquity/+git/ubiquity/+merge/358383 [16:43] infinity, option 2 - http://paste.ubuntu.com/p/kFPTzBMjNC/ [16:44] xnox: I think option 2 was what I originally suggested as being simple. :) [16:44] infinity, i believe both work currently; however option 2 will break if we ever do usr/sbin -> usr/bin migration. [16:44] (and keep this installer code) [16:44] option 1 tests for that, cause it does stat on the symlink target, after checking it exists in a source, to never blacklist any symlinks to dirs. [16:45] Is sbin->bin a thing that's happening at RH? [16:45] Why do they hate UNIX? [16:45] "never blacklist any symlinks to dirs" <-- We don't want that. [16:46] I've not heard about any sbin -> bin merge [16:46] If that was what we wanted, you wouldn't have the last test in your method. [16:47] i think i got lost in my test cases towards the bottom of that function to be honest..... [16:47] no sbin->bin merge is not happening for us/debian. but some have done it. [16:48] (suse, coreos, or something) [16:48] Those who have done it are wrong. [16:48] Though, I make the same argument about usr-merge. :P [16:48] well, sbin means fuck all these days. given that it is inconsistently ordered sometimes before and sometimes after bin; somtimes in path, sometimes not at all in path; etc. [16:48] Anyhow, "never blacklist any symlinks to dirs" isn't what we want and, thankfully, neither of your patches does that. [16:49] however, we shall stay on topic. [16:49] so reading my code again. [16:49] so yeah, i arrive to conclusion that this is a symlink to a dir, and then i whitelist it for top-level symlinks to dirs only. [16:50] Right. [16:50] infinity, however is my long merge proposal (1) actually equivalent to the pastebin (2) ? [16:50] Both your patches will effectively do the same thing with our current package set, cause we don't ship other things in / that we want to remove. [16:50] despite the fuxies. [16:50] The more complicated one is slightly more "correct", though. [16:52] Keep in mind this runs for every single file we want to consider removing, though, and adding extra stat()s could be non-trivial time when added up. [16:52] and i tested the long one. [16:52] So, the simple patch, while technically "incorrect" might be much more performant. :P [16:52] infinity, this is why i moved the "not in self.blacklist" to be the first fallthrough condition. [16:53] cause most of the things are files; and most files are not blacklisted. Hence not in blacklist should be the only thing checked for most things. [16:53] the extra stat is only done on blacklisted symlinks. [16:54] infinity, Laney did suggest refcounting..... [16:54] infinity, a whitelist might be the fastest..... [16:54] infinity, or like never include known usr-merge paths in the blacklist..... [16:54] No, there's an extra stat on everything that isn't a dir to then decide if it's a link. [16:54] self.blacklist shouldn't really have 'usr/bin' in it. [16:54] infinity, no. [16:55] I mean, after your blacklist fallthrough. [16:55] So, everything in the blacklist. [16:55] I'd be OK with just establishing "we don't blacklist at the top level" as a new rule. [16:55] infinity, st = os.lstat(sourcepath) is done on everything. the stat.S_ISLNK(st.st_mode) is just a bitmask test, not a call to lstat()/stat() [16:56] Ahh, okay. [16:56] infinity, os.lstat() and os.stat() are syscalls..... stat.S_* are not syscalls..... [16:56] It's just querying a structure. [16:56] because python [16:56] That's less vomitous then. [16:57] Why the new "does it exist" check? [16:57] infinity, because we ship broken symlinks in /rofs i.e. $ cat /usr/share/doc/libgtk2.0-0/changelog.gz [16:58] and installer explodes. hence i have to decide what does it mean a broken symlink - is it meant to be blacklistable or not.... ie. symlink to a dir or file..... [16:58] you could catch ENOENT or whatever from the stat though [16:58] i pretend they are symlinks to files and thus blacklistable. [16:59] well, the actually question i care is what to do about them. i chose to return True [16:59] but maybe we want to return False and always install broken symlinks. [16:59] imho we should not have broken symlinks in packages..... cause cat /usr/share/doc/libgtk2.0-0/changelog.gz is clearly broken. [17:00] If it's a bug then the package should be fixed, I don't think it's ubiquity's place to make that decision... [17:00] ^ [17:00] ubiquity isn't lintian. [17:01] Its job is to transfer files from the image to the disk. [17:01] The only reason for this blacklist madness is because of a shortcut taken to make package removal faster. [17:01] hence garbage in / garbage out =) [17:01] It's not supposed to make policy decisions. [17:01] the error message here is unhelpful, and is only exposed by my new code, cause i try to stat broken symlink. [17:02] ubiquity poops up "your iso is broken, could not read source file" cause copy_all is wrapped around catching ENOENT meaning read error of iso [17:02] also libgtk2.0-0 should not be on the .iso ;-) [17:03] Blame the installer? [17:04] Or sometihng it depends on. [17:04] Cause it's not in ubuntu-desktop, only ubuntu-live. [17:04] Maybe an input method or something, [17:04] Anyhow, it's not your job to fix broken packages with the installer. If a package has a dangling symlink, we copy it. [17:04] Plus, that might not actually be a bug. [17:05] There are legit reasons to populate/unpopulate the target of a dangling symlink as a semaphore. [17:05] well, in this case, libgtk2.0-0 was chosen to be blacklisted, and i copied the dangling symlink. [17:05] no, i didn't! [17:05] i returned True to _not_ copy it [17:05] No idea if any packages ship in such a state, but it wouldn't be broken if they did. You'd break them by deleting it, though. :P [17:05] -queuebot:#ubuntu-release- Unapproved: python-scciclient (disco-proposed/universe) [0.6.1-2 => 0.8.0-0ubuntu1] (no packageset) [17:05] haha [17:06] i allow blacklisting dangling symlinks. [17:06] You only didn't copy it because it was broken, right? [17:06] Actually, wait. We're overthinking this. [17:06] -queuebot:#ubuntu-release- Unapproved: scikit-learn (disco-proposed/universe) [0.19.2-1ubuntu3 => 0.19.2-1ubuntu5] (no packageset) [17:06] You don't want to copy it. [17:06] Like... if it was a non broken symlink to a directory, that would be cruft left around. [17:06] -queuebot:#ubuntu-release- New binary: metview [armhf] (disco-proposed/universe) [5.2.1-1ubuntu1] (no packageset) [17:07] I almost talked myself into a corner where I forgot why the blacklist exists. [17:07] infinity, return True => means continue; without copy [17:07] * xnox checks what my code does [17:07] The blacklist is a list of packages that we're choosing not to copy because we're using that as a shortcut to not have to call dpkg --purge. [17:07] it returns True, everything is great [17:07] -queuebot:#ubuntu-release- Unapproved: accepted scikit-learn [source] (disco-proposed) [0.19.2-1ubuntu5] [17:07] We skip directories because refusing to copy directories will break OTHER packages. [17:08] ah [17:08] We skip links in / to dirs for the same reason now. [17:08] Everything else is fair game. [17:08] -queuebot:#ubuntu-release- Unapproved: accepted python-scciclient [source] (disco-proposed) [0.8.0-0ubuntu1] [17:08] Any other checks are bogus. [17:08] * Laney still votes for option 2 [17:08] -queuebot:#ubuntu-release- Unapproved: ironic (disco-proposed/universe) [1:11.1.0-0ubuntu5 => 1:11.1.0-0ubuntu6] (openstack) [17:08] -queuebot:#ubuntu-release- Unapproved: murano (disco-proposed/universe) [1:6.0.0-0ubuntu2 => 1:6.0.0-0ubuntu3] (openstack) [17:08] Option 2 gets the job done. [17:09] If someone ships cruft in / in lvm and it sticks around after install, we'll notice. :P [17:09] And, honestly, anyone shipping anything in / is almost certainly wrong. [17:09] On many levels. [17:09] infinity, hahahahhahahhaha no idea who that might be...... [17:10] let me test then if installer works with http://paste.ubuntu.com/p/kFPTzBMjNC/ [17:10] xnox: Let's go with the 1-liner (after it's tested to solve the problem, but I'm not sure how it wouldn't) [17:10] xnox: Jins. [17:10] Jinx, too... [17:10] JINS! [17:10] Jin and Tonique [17:11] The hip, new Danish jinx. [17:11] -queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (disco-proposed) [1:11.1.0-0ubuntu6] [17:11] -queuebot:#ubuntu-release- Unapproved: accepted murano [source] (disco-proposed) [1:6.0.0-0ubuntu3] [17:12] -queuebot:#ubuntu-release- Unapproved: gnu-smalltalk (disco-proposed/universe) [3.2.5-1.1build2 => 3.2.5-1.2~build1] (no packageset) [17:13] -queuebot:#ubuntu-release- New binary: metview [arm64] (disco-proposed/universe) [5.2.1-1ubuntu1] (no packageset) [17:14] please accept gnu-smalltalk, finally ppc64el is "fixed" [17:14] and please accept metview, with gnu-smalltalk they finish gdbm rebuilds [17:14] -queuebot:#ubuntu-release- New: accepted metview [amd64] (disco-proposed) [5.2.1-1ubuntu1] [17:14] -queuebot:#ubuntu-release- New: accepted metview [armhf] (disco-proposed) [5.2.1-1ubuntu1] [17:15] -queuebot:#ubuntu-release- New: accepted metview [ppc64el] (disco-proposed) [5.2.1-1ubuntu1] [17:15] -queuebot:#ubuntu-release- New: accepted metview [arm64] (disco-proposed) [5.2.1-1ubuntu1] [17:15] -queuebot:#ubuntu-release- New: accepted metview [s390x] (disco-proposed) [5.2.1-1ubuntu1] [17:15] -queuebot:#ubuntu-release- New: accepted metview [i386] (disco-proposed) [5.2.1-1ubuntu1] [17:16] LocutusOfBorg: "fixed"? Do I want to know? :P [17:17] infinity, I added the 64 bit to snprintf [17:18] instead of removing it elsewhere [17:18] one liner patch :) [17:18] also uploaded in debian [17:18] we have lots of python failures that will hold gdbm, looks unrelated to gdbm, I'm retrying some of them now that perl is getting ok [17:21] -queuebot:#ubuntu-release- Unapproved: accepted gnu-smalltalk [source] (disco-proposed) [3.2.5-1.2~build1] [17:45] -queuebot:#ubuntu-release- Unapproved: libkolabxml (disco-proposed/universe) [1.1.6-3build2 => 1.1.6-3ubuntu1] (kubuntu) [17:47] -queuebot:#ubuntu-release- Unapproved: accepted libkolabxml [source] (disco-proposed) [1.1.6-3ubuntu1] [17:47] infinity: if you run out of perl errors, comedilib could be for you [17:49] doko: Easy fix (#include ) [17:50] * infinity checks for an upstream commit before JFDIing it. [17:51] and of course cctools [17:51] then dulwich for s390x is left, and then python3.6 should be removable [17:52] https://github.com/Linux-Comedi/comedilib/commit/3f8514739a2d799d2e6dbb6cd43a7f6bb624a319#diff-e8acc63b1e238f3255c900eed37254b8 [17:52] "Also include random stuff we don't use because why not." [17:52] Solid work, upstream. [17:54] infinity: Qt should be bootstrapped in Bileto 3458 by this evening. [17:55] I assume we still don't want tangling with Perl? :P [17:55] tsimonq2: We definitely don't. [17:55] Alright. [17:57] The only two packages left that have deltas and are part of the bootstrapping are qtbase and qtwebkit; the rest should just be running copy-package. :P [17:57] general question... how can perl entangle with qt? [17:57] I mean, the tracker shows no qt packages, even in update excuses I can't find any qt package... [17:57] a good point might "it regresses testsuites" [17:58] Yeah, if I recall correctly it was something along those lines. [17:58] In general it's just better to do them separately I think. [17:58] I'm not saying to do it now :) I was wondering about something else [17:59] I'm finishing gdbm and maybe llvm if everything is good [17:59] Ah. [18:01] Perhaps Perl is just my go-to scapegoat in this case, but I'm willing to bet that's why Lintian is failing its autopkgtests. [18:01] My lunch is about done though, so other eyes would be encouraged. :) [18:05] -queuebot:#ubuntu-release- Unapproved: comedilib (disco-proposed/universe) [0.10.2-4build10 => 0.10.2-4ubuntu1] (no packageset) [18:06] comedilib fixed, I have no idea about cctools... [18:07] -queuebot:#ubuntu-release- Unapproved: accepted comedilib [source] (disco-proposed) [0.10.2-4ubuntu1] [18:28] -queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.4-0ubuntu1 => 2:12.0.5-0ubuntu1] (openstack, ubuntu-server) [18:32] -queuebot:#ubuntu-release- Unapproved: ubiquity (disco-proposed/main) [18.10.12 => 19.04.1] (core) [18:32] infinity, Laney - oneliner is good, uploaded. [18:33] LocutusOfBorg, tsimonq2 - some library must have a Qt gui, and a perl binding. meaning if one is uninstallable, the other can't migrate. [18:38] -queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.12] [18:41] -queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (xenial-proposed) [4.3.0-1ubuntu3.16.04.4] [18:43] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.39] [18:45] -queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [18.1-59-g0f993084-0ubuntu1~16.04.1] [18:50] -queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.40] [18:58] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.38 => 2.408.40] (desktop-core) [19:33] infinity: did you build the no changes rebuild of nginx for disco using 1.15.5-0ubuntu2 from cosmic-proposed? [19:33] i see you uploaded the no change rebuild for the perl 5.28 transition, was wondering whether you included that changeset from 0ubuntu2 [19:44] teward: You could just look. ;) [19:44] teward: http://launchpadlibrarian.net/395789060/nginx_1.15.5-0ubuntu1_1.15.5-0ubuntu3.diff.gz [19:49] infinity: i could. except LP's timing out :P [19:49] all i've got to go on is ahasenack's email message on the SRU bug. :P [19:58] xnox, doko: LP: #1801901 done [19:58] Launchpad bug 1801901 in libextutils-parsexs-perl (Ubuntu) "RM libextutils-parsexs-perl broken with new perl" [Undecided,Fix released] https://launchpad.net/bugs/1801901 [20:01] infinity: i do see it's in there now, and mdeslaur is going to include the cosmic SRU with the security updates for NGINX in Cosmic, not sure if it needs an official ack from an SRU team member though. [20:01] (not ever sure the policies when two teams have jurisdiction heh [20:02] teward: If the SRU is verified already, it's entirely fine for security to build on top of it and just release. *shrug* [20:02] yep. it's verification done after the three hours of testing and production live testing i did heh [20:18] infinity: i assume after the migration form proposed (after the perl migration) it'll set the bug status properly. Is there any chance we can get the recent security patched version of nginx in, or do you want me to wait for the archive to open and migrations to be done? [20:18] teward: It can wait. [20:18] ack. [20:18] teward: Anyone running production servers on disco right now is looney. [20:18] just thought I'd ask while its on my mind :) [20:19] With a side of tooney. [20:19] heh [20:19] infinity: true that. [20:39] tsimonq2: do you know why your newly-merged lintian fails autopkgtests on !amd64? [20:41] tsimonq2: it's not perl (which you seem to be suggesting in scrollback), there are autopkgtest logs showing the failure when only lintian itself is pulled in from -proposed [20:42] vorlon: I did have to go AFK when I started looking at it, so that's not definitively my answer. [20:43] But, I'm not sure. [20:44] heh, so perl's own autopkgtests are failing? not a good sign [20:44] bash: prove: command not found [20:44] lovely [20:45] Oh, isn't that fun. [20:46] That lintian test was probably broken with https://salsa.debian.org/lintian/lintian/commit/551b964fd8106988fb742a2fc8cf44ad5c335ffc but I'd need to understand the whole skeleton thing a bit to see why. [20:47] Debian only running tests on amd64 does us no favours. :/ [20:47] Just independently reached the same conclusion (and grumbling). :P [20:48] infinity: Want to file a bug or should I? [20:48] (In Debian.) [20:49] tsimonq2: Go nuts. [20:49] My reportbug seems to be broken right now. :/ [20:49] (Shh, don't tell anyone I don't use reportbug. >_>) [20:49] infinity: the only failing test is one with clearly wrong test deps (should Depends: perl, only Depends: libapt-pkg-perl) so I'm going to badtest to unblock us [20:50] vorlon: Oh, that test that can't find 'prove' doesn't depend on perl? :P [20:50] correct [20:50] Kay. I was in a panic making sure /usr/bin/prove was still there (which it is). [20:51] was probably introduced after the last perl abi transition [20:51] so never failed because perl never found itself removed instead of upgraded [20:51] vorlon: Badtesting is fine, but please file a bug? [20:51] yes [20:52] (confirming the test passes locally with perl installed might be nice too) [20:52] -queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.5-0ubuntu1] [20:53] Can we petition Debian to pick some random $fast_arch where they can easily get cycles (ie: ppc64el) and run autopkgtest there too? :P [20:53] Dealing with all the "it only works on amd64" tests ourselves sucks. [20:53] infinity: local test> done [20:55] -queuebot:#ubuntu-release- Unapproved: accepted samba [source] (bionic-proposed) [2:4.7.6+dfsg~ubuntu-0ubuntu2.3] [20:57] automake now "fails" autopkgtestsuite on arm64, but the real reason is that new tests have been added by debian... [20:58] instead of trying a self no-change-rebuild now it does a real "make check" [20:58] huh, why did I upload trnascan-se but not remove the ANAIS binaries :P [20:59] vorlon: not enough coffee :p [20:59] -queuebot:#ubuntu-release- Unapproved: llvm-defaults (disco-proposed/universe) [0.44 => 0.45] (no packageset) (sync) [20:59] teward: a highly implausible hypothesis [20:59] heh [21:00] I mean, the only thing that saves me is that I have to walk to the kitchen for the espresso machine [21:00] Does someone recall if arch:all packages can be Multi-Arch: foreign? [21:00] they can [21:01] Thanks. [21:01] -queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (bionic-proposed) [3.28.3-2~ubuntu18.04.2] [21:02] vorlon: well, you never know :P [21:02] i keep a coffee maker at my desk not 3 feet away from me :P [21:02] because NEVER ENOUGH COFFEE!!!! *chugs another cup, making that his 6th of the day* [21:04] -queuebot:#ubuntu-release- Unapproved: accepted python-openstackclient [source] (bionic-proposed) [3.14.2-0ubuntu1] [21:05] -queuebot:#ubuntu-release- Unapproved: linux-firmware (disco-proposed/main) [1.175 => 1.176] (core, kernel) [21:09] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.3] [21:09] OMG EMPTY AUTOPKGTEST QUEUES?? [21:09] -queuebot:#ubuntu-release- Unapproved: linux-firmware (cosmic-proposed/main) [1.175 => 1.175.1] (core, kernel) [21:10] not on s390x yet... :) [21:10] Wait, really? [21:10] -queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.1 => 1.173.2] (core, kernel) [21:10] -queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.20 => 1.157.21] (core, kernel) [21:11] Quick, retry everything. [21:12] Guess I need to fix those last 5 packages. [21:12] 6. [21:12] which ones do you mean? [21:12] yeah not s390x yet [21:12] http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.28.html [21:12] -queuebot:#ubuntu-release- Unapproved: accepted gnome-calculator [source] (bionic-proposed) [1:3.28.2-1~ubuntu18.04.1] [21:12] k [21:13] *hands infinity the "Retry Perl Autopkgtest hell" button just to push a ton of autopkgtests into the queue* [21:13] oping is easy enough. slic3r can, I think, be reverted and punted. [21:13] The other 3 are mildly confusing. [21:13] but that won't take long i assume [21:13] libnet-ldns-perl : Depends: perlapi-5.26.0 [21:13] doesn't look confusing to me [21:14] or is that the wrong version? [21:14] ah ftbfs [21:14] vorlon: The FTBFS is confusing. :P [21:14] Or, rather, why the testsuite seems to have spontaenously regressed. [21:14] But hasn't done so in Debian. [21:15] And I don't think our networks suddenly got even more restrictive than they already were. [21:16] hmm why does Debian bug #901080 claim this fails due to newer versions of libtest-simple-perl, when autopkgtest log shows no references to libtest-simple-perl? [21:16] Debian bug 901080 in src:libtest-differences-perl "libtest-differences-perl: t/column-headers.t fails with verbose tests" [Normal,Open] http://bugs.debian.org/901080 [21:18] -queuebot:#ubuntu-release- Unapproved: liboping (disco-proposed/universe) [1.10.0-2.1build1 => 1.10.0-2.1ubuntu1] (no packageset) [21:19] -queuebot:#ubuntu-release- Unapproved: accepted liboping [source] (disco-proposed) [1.10.0-2.1ubuntu1] [21:22] -queuebot:#ubuntu-release- Unapproved: slic3r (disco-proposed/universe) [1.2.9+dfsg-9 => 1.2.9+dfsg-9build1] (no packageset) [21:24] vorlon: polymake has no rdeps, upstream is working with the Debian maintainer to fix it, I vote we remove it from the release pocket and let the fix flow in later from autosync. Concur? [21:25] infinity: remove from release pocket and not demote, yes [21:25] -queuebot:#ubuntu-release- Unapproved: accepted slic3r [source] (disco-proposed) [1.2.9+dfsg-9build1] [21:25] vorlon: Well, remove from release pocket is functionally demote, since there's an FTBFS version in proposed. :) [21:26] vorlon: And keeping that there avoids it being a new autosync later. [21:26] infinity: ah :) [21:26] * infinity shrugs. [21:27] * infinity thwacks it. [21:30] infinity, I was fixing polymake right now [21:30] https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/15618448 [21:30] vorlon: nf{log,queue}-bindings have 3-month old RC bugs and testing removals with no response. They can probably go too. [21:31] LocutusOfBorg: Please don't update to a new upstream version unless you're sure it's the same orig Debian will use. [21:31] Such a headache otherwise. [21:31] infinity, I never do this [21:31] if it works, I'll extract the new upstream release as patch on top of the old one [21:31] right now, I don't care because it is my ppa [21:31] infinity: Home now; my theory earlier was that it had to do with the change from ${architecture} -> arch:all in the template files. [21:31] and yes, I agree with you basically [21:32] bad github regenrating tarballs [21:32] LocutusOfBorg: It really doesn't need the whole new upstream release. It just needs a cherrypick of the boost fix and the disabled test. But I was happy waiting a week for bremner to merge upstream's stuff. *shrug* [21:33] You do you, though. It's removed from the release pocket, so it won't be holding up the transition either way. [21:33] infinity, there is a previous PR that bremner never addressed... [21:33] I pinged him some minutes ago, lets see [21:34] anyway, as you say, I can upload if it works, or not, who cares? [21:34] btw I don't get why are you removing them (I'm not opposing to them), while there is still lots of autopkgtests regressions, but yeah, lets move forward [21:34] LocutusOfBorg: He literally said he'd look at it in a week in the bug. [21:35] LocutusOfBorg: That was a couple of days ago. [21:35] infinity: no objections there either [21:35] I'm also looking at slic3r, thanks for doing the dirty job :) [21:35] infinity, I cant find it here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912174 [21:35] Debian bug 912174 in src:polymake "polymake FTBFS: test failure" [Serious,Open] [21:35] LocutusOfBorg: The other bug. [21:35] LocutusOfBorg: The boost one. [21:36] oh the other one yes [21:36] I don't usually look to what is not RC :) [21:37] I mean, they're both RC, one of them just has the wrong severity set. :P [21:37] For whatever bizarre reason. [21:37] Oh, the boost one isn't RC cause the transition hasn't started in Debian yet. [21:38] Anyhow, with those fixes and removals, we're now down to libnet-ldns-perl on the rebuild side, then the long tail of autopkgtest analysis and retries. [21:39] yes, that one [21:47] -queuebot:#ubuntu-release- Unapproved: polymake (disco-proposed/universe) [3.2r2-3build1 => 3.2r2-3ubuntu1] (no packageset) [21:48] Oh, libnet-ldns-perl was failing in cosmic way back in July already. [21:49] Aaaand, it used to ignore the testsuite. [21:50] Okay, this isn't a regression at all, just the new version doesn't skip enough remote tests, while the old one ignored all of them failing. :P [21:51] * infinity will remove, rebuild the old one, then put the new one back post-transition. [21:52] infinity, slic3r is not really BE friendly, and the system admesh is not a drop-in replacement for it [21:52] calculate_normals doesn't exist e.g. [21:52] so, removing it from s390x is the best thing we can do, I presume debian will do the same [21:52] I know you already did some work in another way, just saying that I'm stopping the porting work [21:52] LocutusOfBorg: If that's what happens later, that's fine, but for now, it's reverted to the old version and it's happy. [21:53] yep I know, just saying that I'm stopping for now the perl/gdbm/foo work [21:54] -queuebot:#ubuntu-release- Unapproved: libnet-ldns-perl (disco-proposed/universe) [0.75-3 => 0.75-3build1] (no packageset) [21:54] infinity: Assuming Debian's bug tracker likes me today, that bug is filed and you should also get an email. [21:54] Now, that isn't always the case. >_> [21:55] LocutusOfBorg: Updating to a new version wholesale via a patch is really gross. :/ [21:57] -queuebot:#ubuntu-release- Unapproved: accepted libnet-ldns-perl [source] (disco-proposed) [0.75-3build1] [21:58] -queuebot:#ubuntu-release- Unapproved: accepted polymake [source] (disco-proposed) [3.2r2-3ubuntu1] [21:58] infinity: whenever ldns gets sorted, libzonemaster-perl needs its autopkgtests retried too [21:59] infinity, why should we care? :) [21:59] at least it doesn't make the archive look bad wrt new tarballs [21:59] I could have polished it, but meh [21:59] it will get sorted before disco is out :) [22:00] LocutusOfBorg: Why should we care about horrible gross unmaintainable patches? I mean, if we're sure bremner will update in Debian in a week or two, and you're sure you'll sync over it, then nah, don't care. [22:00] But I very much care about such madness in general, cause it's not maintainable long-term. [22:00] infinity, if it gets non-maintainable, it will get removed, if debian stops maintaining it [22:00] ...? [22:00] Debian isn't maintaining what you did in Ubuntu. [22:00] but you are speaking to a person who has *all* his packages in sync with debian, so I agree with you [22:01] infinity, debian is RC buggy, in case fixes the rc bug, without fixing boost, I'll do a proper merge, because it will show up in my merge page [22:01] in case it gets removed from testing, we can do the same I would say [22:01] 99% debian will update to new release and I'll force-sync [22:02] I care about maintainability when patches are ubuntu specific, but in general, we are fixing an issue that debian will have in the next months, so gross patch will go awayyy [22:02] * LocutusOfBorg looks llvm finish its build finally [22:03] * LocutusOfBorg and goes afk [22:06] infinity: So, I'm finding out that, despite our warnings, people are still doing Bionic -> Cosmic upgrades for Lubuntu. I guess it's partly our fault because we only thought of the upgrade retroactively, but I'd like to know your opinion on how we should clean up the extra LXDE stuff if people decide to do that upgrade. [22:06] Maybe a better way to phrase the question would be asking how Kubuntu did it when they went to Plama 5 from KDE 4; none of those developers are still in the Kubuntu team. [22:07] *Plasma [22:07] tsimonq2: I have no good opinions right now. [22:07] tsimonq2: Also, you always have the problem where you can't really know the user's intent, and forcefully removing packages isn't nice. [22:08] infinity: That is true. [22:08] tsimonq2: (we punted on that in Ubuntu when we moved to gnome-shell and left unity installed, for instance) [22:08] Got it. [22:09] I guess we'll continue to push the documentation we wrote out for cleaning up the upgrades. :P [22:11] infinity: How "not nice" would it be to have a transitional package of sorts which lubuntu-desktop depends on that Conflicts all of the packages we want removed, so a user has to choose between keeping lubuntu-desktop and keeping LXDE? :P [22:11] It just *feels* hacky but I guess something of that sort is an option. [22:14] tsimonq2: Very not nice. [22:14] infinity: Is turning off upgrades an option? [22:15] (Similar to what happened with i386.) [22:15] That is potentially an option. Talk to Brian about that, maybe. [22:15] bdmurray: Hello. ^ [22:16] bdmurray: tl;dr, is turning off Lubuntu 18.04 -> * upgrades an option? [22:17] tsimonq2: Why would it be turned it off for Lubuntu? [22:18] bdmurray: We changed desktops from LXDE to LXQt and pretty much every component was switched out. [22:18] bdmurray: Upgrades are a mess; clean installs are very much preferred. [22:20] tsimonq2, infinity: well it should be technically possible to prevent the upgrade [22:23] I guess I'm more concerned about 18.04 -> 20.04 upgrades, because you have to manually turn on 18.04 -> 18.10 and we can probably expect those users to be slightly more inclined to read the release notes... [22:23]