User1: at least this one seems to be an accident
User2: heh
User2: User15 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 :/
-queuebot:#ubuntu-release- New binary: rust-iovec [ppc64el] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-iovec [s390x] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-iovec [amd64] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-iovec [i386] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: rust-crossbeam-epoch (disco-proposed/universe) [0.5.1-1 => 0.5.2-1] (no packageset) (sync)
-queuebot:#ubuntu-release- New: accepted rust-iovec [amd64] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-iovec [ppc64el] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New binary: rust-iovec [arm64] (disco-proposed/universe) [0.1.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-iovec [i386] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-iovec [s390x] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- New: accepted rust-iovec [arm64] (disco-proposed) [0.1.2-1]
-queuebot:#ubuntu-release- Unapproved: accepted rust-crossbeam-epoch [sync] (disco-proposed) [0.5.2-1]
User1: https://github.com/pygraphviz/pygraphviz/issues/175 :(
User3: pygraphviz issue 175 in pygraphviz "Test failures with Graphviz 2.40.1" [Open]
-queuebot:#ubuntu-release- New binary: rust-crossbeam-deque [s390x] (disco-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-mio [amd64] (disco-proposed/universe) [0.6.16-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-deque [s390x] (disco-proposed) [0.6.1-1]
-queuebot:#ubuntu-release- New: accepted rust-mio [amd64] (disco-proposed) [0.6.16-1]
User2: 'rust-fuchsia-zircon-sys' why are rust package names alchemical formulas?
-queuebot:#ubuntu-release- New binary: rust-crossbeam-deque [ppc64el] (disco-proposed/universe) [0.6.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-crossbeam-deque [ppc64el] (disco-proposed) [0.6.1-1]
User1: i think that one is probably all fuschia's fault
User1: https://github.com/fuchsia-mirror/zircon
-queuebot:#ubuntu-release- Unapproved: python-pygraphviz (disco-proposed/universe) [1.4~rc1-1build4 => 1.4~rc1-1ubuntu1] (no packageset)
User4: User5 Thank you.
-queuebot:#ubuntu-release- New binary: rust-rayon-core [amd64] (disco-proposed/universe) [1.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rayon-core [ppc64el] (disco-proposed/universe) [1.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rayon-core [i386] (disco-proposed/universe) [1.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rayon-core [s390x] (disco-proposed/universe) [1.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-rayon-core [i386] (disco-proposed) [1.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rayon-core [amd64] (disco-proposed) [1.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rayon-core [s390x] (disco-proposed) [1.4.1-1]
-queuebot:#ubuntu-release- New: accepted rust-rayon-core [ppc64el] (disco-proposed) [1.4.1-1]
-queuebot:#ubuntu-release- New binary: rust-rayon-core [arm64] (disco-proposed/universe) [1.4.1-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-rayon-core [arm64] (disco-proposed) [1.4.1-1]
User4: bdmurray, User2 Would it be too late tonight to process src:libreoffice in cosmic UNAPPROVED?
User4: User15 Er, I guess, tag, you're it, says the wiki? ^
User4: Â¯\_(ã)_/Â¯
User4: *whoever* :)
User5: Could you elaborate on the patch without a Launchpad bug?
User4: The LibreOffice theme by default is set to an X11-style design under the LXQt desktop, which is (sorry LibreOffice developers) extremely ugly.
User4: This changes it to use the Breeze theme by default, but only under the LXQt desktop.
User5: User4 I'm talking about "Backport a patch from upstream which fixes testcases with OpenJDK 11."
User4: Oh.
User4: 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.
User4: The patch is from oSoMoN if it makes a difference: https://github.com/LibreOffice/core/commit/10a5880db7df9c3573e1562615f86fe9a211bc56
User4: It removes a reference to a file that is no longer generated.
User5: What's really broken though?
User4: The build is broken. :P
User4: Here's a build under Cosmic with just the Breeze fix: https://launchpad.net/~tsimonq2/+archive/ubuntu/upload-testing/+sourcepub/9494952/+listing-archive-extra
User6: there is a bug for it: LP: #1796361
User7: Launchpad bug 1796361 in libreoffice (Ubuntu) "autopkgtests fail with openjdk 11~28-3ubuntu1 in cosmic-proposed" [Medium,In progress] https://launchpad.net/bugs/1796361
User5: User4 Oh, how about a re-upload with an LP bug reference then.
User6: and the fix is fine, I checked it some time ago
User4: Aha, I didn't know there *was* a bug to reference. :)
User5: I'll be back in a bit to review / accept it.
User4: Sure, thanks.
-queuebot:#ubuntu-release- New binary: rust-rayon [ppc64el] (disco-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New binary: rust-rayon [s390x] (disco-proposed/universe) [1.0.2-1] (no packageset)
User6: User4 thanks for driving this ;-)
User4: No problem. :)
-queuebot:#ubuntu-release- New binary: rust-rayon [amd64] (disco-proposed/universe) [1.0.2-1] (no packageset)
User6: hmm, I was not aware this was pushed to disco, but then the bug # was not referenced on the changelog
-queuebot:#ubuntu-release- New: accepted rust-rayon [amd64] (disco-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-rayon [s390x] (disco-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New: accepted rust-rayon [ppc64el] (disco-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- New binary: rust-rayon [i386] (disco-proposed/universe) [1.0.2-1] (no packageset)
-queuebot:#ubuntu-release- New: accepted rust-rayon [i386] (disco-proposed) [1.0.2-1]
-queuebot:#ubuntu-release- Unapproved: python-networkx (disco-proposed/main) [2.1-1ubuntu2 => 2.1-1ubuntu3] (ubuntu-server)
User1: if someone could approve python-pygraphviz, that would be grant
User1: *grand
User1: because then i can upload a fixed botch
-queuebot:#ubuntu-release- Unapproved: libreoffice (cosmic-proposed/main) [1:6.1.2-0ubuntu1 => 1:6.1.2-0ubuntu1.1] (kubuntu, ubuntu-desktop)
User4: User5 Your follow-up upload. ^
-queuebot:#ubuntu-release- Unapproved: rejected libreoffice [source] (cosmic-proposed) [1:6.1.2-0ubuntu1.1]
User8: Any reason why mutter was rejected for bionic SRU?
User8: https://launchpad.net/ubuntu/bionic/+queue?queue_state=4&queue_text=mutter
-queuebot:#ubuntu-release- Unapproved: accepted python-networkx [source] (disco-proposed) [2.1-1ubuntu3]
-queuebot:#ubuntu-release- Unapproved: accepted python-pysnmp4 [sync] (disco-proposed) [4.4.6+repack1-1]
-queuebot:#ubuntu-release- Unapproved: accepted python-pygraphviz [source] (disco-proposed) [1.4~rc1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected libreoffice [source] (disco-proposed) [1:6.1.3-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected sosreport [sync] (disco-proposed) [3.6-1]
-queuebot:#ubuntu-release- Unapproved: accepted odb-api [sync] (disco-proposed) [0.18.0-6]
-queuebot:#ubuntu-release- Unapproved: python-dbusmock (disco-proposed/universe) [0.18-1 => 0.18-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-setuptools (disco-proposed/main) [40.2.0-1 => 40.5.0-1] (core)
-queuebot:#ubuntu-release- Unapproved: accepted python-dbusmock [source] (disco-proposed) [0.18-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: accepted python-setuptools [source] (disco-proposed) [40.5.0-1]
User9: vorlon, infinity, User11 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
-queuebot:#ubuntu-release- Unapproved: commonmark-bkrs (disco-proposed/universe) [0.5.4+ds-1 => 0.5.4+ds-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted commonmark-bkrs [source] (disco-proposed) [0.5.4+ds-1ubuntu1]
User1: User9 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
User1: User9 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
User1: (if it did, it would have failed)
User9: yeah, that's another thing to investigate. but the previous migration was all green
-queuebot:#ubuntu-release- Unapproved: minieigen (disco-proposed/universe) [0.50.3+dfsg1-5ubuntu4 => 0.50.3+dfsg1-5ubuntu5] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted minieigen [source] (disco-proposed) [0.50.3+dfsg1-5ubuntu5]
User1: well ok i have no idea what happened to python-dbusmock, it doesn't do that locally
User10: infinity, thanks for odb-api! :) I was going to do the same exacly some seconds ago
-queuebot:#ubuntu-release- Unapproved: botch (disco-proposed/universe) [0.21-6ubuntu2 => 0.21-6ubuntu3] (no packageset)
-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)
-queuebot:#ubuntu-release- Unapproved: accepted botch [source] (disco-proposed) [0.21-6ubuntu3]
User11: did vorlon submit duplicate perl/s390x jobs?
User11: aha, you fixed s390-tools
-queuebot:#ubuntu-release- Unapproved: gcc-6-cross (disco-proposed/universe) [33ubuntu1 => 34ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted gcc-6-cross [source] (disco-proposed) [34ubuntu1]
 * mwhudson zzz
User11: User9 IMO document first, then consider a hint
User11: if it was previously all green (falsely given mwhudson's comments?) then there may be some actual problems here?
User9: User11 no, it wasn't triggered, so no information about if it failed or not
-queuebot:#ubuntu-release- Unapproved: snapd (disco-proposed/main) [2.35.5+18.10 => 2.35.5+18.10ubuntu1] (desktop-core, ubuntu-server)
User12: well, still cannot build server installation media... async is a reserved keyword.
User12: https://bugs.launchpad.net/maas/+bug/1801899
User7: Ubuntu bug 1801899 in maas (Ubuntu) "cannot install with python3.7 as default async is a reserved keyword" [Critical,New]
-queuebot:#ubuntu-release- Unapproved: accepted snapd [source] (disco-proposed) [2.35.5+18.10ubuntu1]
User11: what wasn't triggered?
User12: doko, please RM https://bugs.launchpad.net/debian/+source/libextutils-parsexs-perl/+bug/1801901 for perl transition
User7: Ubuntu bug 1801901 in libextutils-parsexs-perl (Ubuntu) "RM libextutils-parsexs-perl broken with new perl" [Undecided,New]
User9: User11 libcloud
User9: but also murano, ironic, ...
User11: there's a trigger from python3-defaults 3.7.1-1 there
User9: and why did it succeed?
User11: you tell me
-queuebot:#ubuntu-release- Unapproved: libsoup2.4 (disco-proposed/main) [2.64.1-1 => 2.64.1-3] (core) (sync)
-queuebot:#ubuntu-release- Unapproved: libdazzle (disco-proposed/main) [3.30.1-1 => 3.30.1-2] (ubuntu-desktop) (sync)
-queuebot:#ubuntu-release- Unapproved: network-manager-openvpn (disco-proposed/main) [1.8.6-1ubuntu1 => 1.8.8-1] (ubuntu-desktop) (sync)
User9: User11 ahh, that might be, because openstack did run with python3.6 explicitly... jamespage might confirm that
-queuebot:#ubuntu-release- Unapproved: matplotlib (disco-proposed/universe) [2.2.2-4build2 => 2.2.2-4ubuntu1] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted matplotlib [source] (disco-proposed) [2.2.2-4ubuntu1]
User13: User9 I think we did that with a couple of pkgs
User13: it should be noted in d/rules
User10: doko, please accept llvm-toolchain-7
User10: it should fix testsuite, regressions and intel-mkt failures and make everything migrate
User9: User13 so how do you want to address murano, libcloud, ironic? just ignore the test results to let python3-defaults migrate?
-queuebot:#ubuntu-release- Unapproved: llvm-toolchain-7 (disco-proposed/main) [1:7-8 => 1:7-9~build1] (kubuntu, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: matplotlib (disco-proposed/universe) [2.2.2-4ubuntu1 => 2.2.2-4ubuntu2] (ubuntustudio)
-queuebot:#ubuntu-release- Unapproved: accepted matplotlib [source] (disco-proposed) [2.2.2-4ubuntu2]
-queuebot:#ubuntu-release- Unapproved: mod-wsgi (disco-proposed/main) [4.5.17-1build1 => 4.5.17-1build2] (ubuntu-server)
User10: please accept llvm
-queuebot:#ubuntu-release- Unapproved: shiboken (disco-proposed/universe) [1.2.2-5.1 => 1.2.2-5.1build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: kdevelop-python (disco-proposed/universe) [5.2.4-1 => 5.2.4-1build1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted kdevelop-python [source] (disco-proposed) [5.2.4-1build1]
-queuebot:#ubuntu-release- Unapproved: accepted shiboken [source] (disco-proposed) [1.2.2-5.1build1]
-queuebot:#ubuntu-release- Unapproved: accepted mod-wsgi [source] (disco-proposed) [4.5.17-1build2]
-queuebot:#ubuntu-release- Unapproved: accepted llvm-toolchain-7 [source] (disco-proposed) [1:7-9~build1]
User12: 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.
User14: are seed changes allowed in disco, or is that also frozen for the moment?
User14: https://code.launchpad.net/~ahasenack/ubuntu-seeds/+git/ubuntu/+merge/358160 specifically
-queuebot:#ubuntu-release- Unapproved: stress-ng (disco-proposed/universe) [0.09.42-1 => 0.09.44-1] (no packageset) (sync)
User12: Laney, infinity https://code.launchpad.net/~ubuntu-installer/ubiquity/+git/ubiquity/+merge/358383
-queuebot:#ubuntu-release- Unapproved: libcloud (disco-proposed/universe) [2.3.0-1ubuntu2 => 2.3.0-3] (no packageset) (sync)
-queuebot:#ubuntu-release- Unapproved: accepted libcloud [sync] (disco-proposed) [2.3.0-3]
-queuebot:#ubuntu-release- Unapproved: magics++ (disco-proposed/universe) [3.2.1-1 => 3.2.1-2~build1] (no packageset)
User10: doko, ^^ this fixes metview
-queuebot:#ubuntu-release- Unapproved: accepted magics++ [source] (disco-proposed) [3.2.1-2~build1]
User11: User12 don't have much context for this :(
User11: what's the blacklist about even?
-queuebot:#ubuntu-release- Unapproved: scikit-learn (disco-proposed/universe) [0.19.2-1ubuntu2 => 0.19.2-1ubuntu3] (no packageset)
-queuebot:#ubuntu-release- Unapproved: python-biopython (disco-proposed/universe) [1.72-0ubuntu1 => 1.72-0ubuntu2] (no packageset)
User12: 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.
User12: i mean, if we had stacked squashfs and not excludes we'd be fine..... but it is complicated.
-queuebot:#ubuntu-release- Unapproved: accepted libreoffice [source] (cosmic-proposed) [1:6.1.2-0ubuntu1.1]
-queuebot:#ubuntu-release- Unapproved: accepted python-biopython [source] (disco-proposed) [1.72-0ubuntu2]
-queuebot:#ubuntu-release- Unapproved: accepted scikit-learn [source] (disco-proposed) [0.19.2-1ubuntu3]
User12: Laney, given the debug pain, i wonder if i should just upload that into disco. cause currently it is completely bust and cannot install sherry24@example.net.
-queuebot:#ubuntu-release- Unapproved: ecflow (disco-proposed/universe) [4.10.0-2ubuntu2 => 4.11.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted ecflow [source] (disco-proposed) [4.11.1-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: desktop-file-utils (disco-proposed/main) [0.23-3ubuntu2 => 0.23-4ubuntu1] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: spl-linux (disco-proposed/universe) [0.7.9-3ubuntu2 => 0.7.11-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: desktop-file-utils (cosmic-proposed/main) [0.23-3ubuntu2 => 0.23-3ubuntu3] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: zfs-linux (disco-proposed/main) [0.7.9-3ubuntu6 => 0.7.11-3ubuntu1] (core)
-queuebot:#ubuntu-release- Unapproved: desktop-file-utils (bionic-proposed/main) [0.23-1ubuntu91.69.162.6 => 0.23-1ubuntu91.69.162.6] (desktop-core)
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (disco-proposed/main) [3.30.0-1ubuntu3 => 3.30.0-1ubuntu4] (ubuntu-desktop, ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: gnome-initial-setup (bionic-proposed/main) [3.28.0-2ubuntu91.69.162.6 => 3.30.0-1ubuntu3.1] (ubuntugnome)
-queuebot:#ubuntu-release- Unapproved: bolt (bionic-proposed/main) [0.4-0ubuntu91.69.162.6 => 0.5-0ubuntu91.69.162.6] (ubuntu-desktop)
-queuebot:#ubuntu-release- New binary: metview [s390x] (disco-proposed/universe) [5.2.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted mokutil [source] (xenial-proposed) [0.3.0+1538710437.fb6250f-0ubuntu2~16.04.1]
-queuebot:#ubuntu-release- Unapproved: accepted mokutil [source] (trusty-proposed) [0.3.0+1538710437.fb6250f-0ubuntu2~14.04.1]
-queuebot:#ubuntu-release- New binary: metview [i386] (disco-proposed/universe) [5.2.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: udisks2 (disco-proposed/main) [2.7.6-3ubuntu3 => 2.8.1-2] (desktop-core, ubuntu-server) (sync)
-queuebot:#ubuntu-release- New binary: metview [ppc64el] (disco-proposed/universe) [5.2.1-1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: firefox (disco-proposed/main) [63.0+build2-0ubuntu91.69.162.6 => 63.0.1+build4.1-0ubuntu1] (kubuntu, mozilla, ubuntu-desktop)
-queuebot:#ubuntu-release- Unapproved: kdevelop-python (disco-proposed/universe) [5.2.4-1build1 => 5.2.4-1ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted kdevelop-python [source] (disco-proposed) [5.2.4-1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: rejected firefox [source] (disco-proposed) [63.0.1+build4-0ubuntu1]
User15: User12 '/' in relpath is going to return true for any target with a / anywhere in it.
User15: User12 Not just top-levels.
User12: infinity, this is very convenient list "sbin" "usr/sbin" are the relpaths here. hence we prepend '/' to look up things in the blacklist
User12: infinity, hence '/' in relpath is only true for subdiry things.
User15: User12 But you'd also potentially leave other cruft around.
User15: User12 I have plenty of symlinks on my system with / in the target that aren't the ones you want to keep. :P
User12: infinity, i wish you were in #ubuntu-installer to follow a long chat i had with Laney
User15: User12 Would that chat somehow prove me wrong?
User15: User12 Cause I'm pretty sure it wouldn't.
-queuebot:#ubuntu-release- New binary: metview [amd64] (disco-proposed/universe) [5.2.1-1ubuntu1] (no packageset)
User12: infinity, i'm never testing '/' in target.....
User12: only the source-stem filename
User15: User12 Oh, I'm reading it backwards indeed.
User12: infinity, option 1 - https://code.launchpad.net/~ubuntu-installer/ubiquity/+git/ubiquity/+merge/358383
User12: infinity, option 2 - http://paste.ubuntu.com/p/kFPTzBMjNC/
User15: User12 I think option 2 was what I originally suggested as being simple. :)
User12: infinity, i believe both work currently; however option 2 will break if we ever do usr/sbin -> usr/bin migration.
User12: (and keep this installer code)
User12: 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.
User15: Is sbin->bin a thing that's happening at RH?
User15: Why do they hate UNIX?
User15: "never blacklist any symlinks to dirs" <-- We don't want that.
User11: I've not heard about any sbin -> bin merge
User15: If that was what we wanted, you wouldn't have the last test in your method.
User12: i think i got lost in my test cases towards the bottom of that function to be honest.....
User12: no sbin->bin merge is not happening for us/debian. but some have done it.
User12: (suse, coreos, or something)
User15: Those who have done it are wrong.
User15: Though, I make the same argument about usr-merge. :P
User12: 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.
User15: Anyhow, "never blacklist any symlinks to dirs" isn't what we want and, thankfully, neither of your patches does that.
User12: however, we shall stay on topic.
User12: so reading my code again.
User12: 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.
User15: Right.
User12: infinity, however is my long merge proposal (1) actually equivalent to the pastebin (2) ?
User15: 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.
User12: despite the fuxies.
User15: The more complicated one is slightly more "correct", though.
User15: 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.
User12: and i tested the long one.
User15: So, the simple patch, while technically "incorrect" might be much more performant. :P
User12: infinity, this is why i moved the "not in self.blacklist" to be the first fallthrough condition.
User12: 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.
User12: the extra stat is only done on blacklisted symlinks.
User12: infinity, Laney did suggest refcounting.....
User12: infinity, a whitelist might be the fastest.....
User12: infinity, or like never include known usr-merge paths in the blacklist.....
User15: No, there's an extra stat on everything that isn't a dir to then decide if it's a link.
User12: self.blacklist shouldn't really have 'usr/bin' in it.
User12: infinity, no.
User15: I mean, after your blacklist fallthrough.
User15: So, everything in the blacklist.
User11: I'd be OK with just establishing "we don't blacklist at the top level" as a new rule.
User12: 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()
User15: Ahh, okay.
User12: infinity, os.lstat() and os.stat() are syscalls..... stat.S_* are not syscalls.....
User15: It's just querying a structure.
User12: because python
User15: That's less vomitous then.
User15: Why the new "does it exist" check?
User12: infinity, because we ship broken symlinks in /rofs i.e. $ cat /usr/share/doc/libgtk2.0-0/changelog.gz
User12: 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.....
User11: you could catch ENOENT or whatever from the stat though
User12: i pretend they are symlinks to files and thus blacklistable.
User12: well, the actually question i care is what to do about them. i chose to return True
User12: but maybe we want to return False and always install broken symlinks.
User12: imho we should not have broken symlinks in packages..... cause cat /usr/share/doc/libgtk2.0-0/changelog.gz is clearly broken.
User11: If it's a bug then the package should be fixed, I don't think it's ubiquity's place to make that decision...
User15: ^
User15: ubiquity isn't lintian.
User15: Its job is to transfer files from the image to the disk.
User15: The only reason for this blacklist madness is because of a shortcut taken to make package removal faster.
User12: hence garbage in / garbage out =)
User15: It's not supposed to make policy decisions.
User12: the error message here is unhelpful, and is only exposed by my new code, cause i try to stat broken symlink.
User12: 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
User12: also libgtk2.0-0 should not be on the .iso ;-)
User15: Blame the installer?
User15: Or sometihng it depends on.
User15: Cause it's not in ubuntu-desktop, only ubuntu-live.
User15: Maybe an input method or something,
User15: Anyhow, it's not your job to fix broken packages with the installer.  If a package has a dangling symlink, we copy it.
User15: Plus, that might not actually be a bug.
User15: There are legit reasons to populate/unpopulate the target of a dangling symlink as a semaphore.
User12: well, in this case, libgtk2.0-0 was chosen to be blacklisted, and i copied the dangling symlink.
User12: no, i didn't!
User12: i returned True to _not_ copy it
User15: 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
-queuebot:#ubuntu-release- Unapproved: python-scciclient (disco-proposed/universe) [0.6.1-2 => 0.8.0-0ubuntu1] (no packageset)
User11: haha
User12: i allow blacklisting dangling symlinks.
User11: You only didn't copy it because it was broken, right?
User15: Actually, wait.  We're overthinking this.
-queuebot:#ubuntu-release- Unapproved: scikit-learn (disco-proposed/universe) [0.19.2-1ubuntu3 => 0.19.2-1ubuntu5] (no packageset)
User15: You don't want to copy it.
User11: Like... if it was a non broken symlink to a directory, that would be cruft left around.
-queuebot:#ubuntu-release- New binary: metview [armhf] (disco-proposed/universe) [5.2.1-1ubuntu1] (no packageset)
User15: I almost talked myself into a corner where I forgot why the blacklist exists.
User12: infinity, return True => means continue; without copy
 * xnox checks what my code does
User15: 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.
User12: it returns True, everything is great
-queuebot:#ubuntu-release- Unapproved: accepted scikit-learn [source] (disco-proposed) [0.19.2-1ubuntu5]
User15: We skip directories because refusing to copy directories will break OTHER packages.
User12: ah
User15: We skip links in / to dirs for the same reason now.
User15: Everything else is fair game.
-queuebot:#ubuntu-release- Unapproved: accepted python-scciclient [source] (disco-proposed) [0.8.0-0ubuntu1]
User15: Any other checks are bogus.
 * Laney still votes for option 2
-queuebot:#ubuntu-release- Unapproved: ironic (disco-proposed/universe) [1:11.1.0-0ubuntu5 => 1:11.1.0-0ubuntu6] (openstack)
-queuebot:#ubuntu-release- Unapproved: murano (disco-proposed/universe) [1:6.0.0-0ubuntu2 => 1:6.0.0-0ubuntu3] (openstack)
User15: Option 2 gets the job done.
User15: If someone ships cruft in / in lvm and it sticks around after install, we'll notice. :P
User15: And, honestly, anyone shipping anything in / is almost certainly wrong.
User15: On many levels.
User12: infinity, hahahahhahahhaha no idea who that might be......
User12: let me test then if installer works with http://paste.ubuntu.com/p/kFPTzBMjNC/
User15: User12 Let's go with the 1-liner (after it's tested to solve the problem, but I'm not sure how it wouldn't)
User15: User12 Jins.
User15: Jinx, too...
User15: JINS!
User11: Jin and Tonique
User15: The hip, new Danish jinx.
-queuebot:#ubuntu-release- Unapproved: accepted ironic [source] (disco-proposed) [1:11.1.0-0ubuntu6]
-queuebot:#ubuntu-release- Unapproved: accepted murano [source] (disco-proposed) [1:6.0.0-0ubuntu3]
-queuebot:#ubuntu-release- Unapproved: gnu-smalltalk (disco-proposed/universe) [3.2.5-1.1build2 => 3.2.5-1.2~build1] (no packageset)
-queuebot:#ubuntu-release- New binary: metview [arm64] (disco-proposed/universe) [5.2.1-1ubuntu1] (no packageset)
User10: please accept gnu-smalltalk, finally ppc64el is "fixed"
User10: and please accept metview, with gnu-smalltalk they finish gdbm rebuilds
-queuebot:#ubuntu-release- New: accepted metview [amd64] (disco-proposed) [5.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted metview [armhf] (disco-proposed) [5.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted metview [ppc64el] (disco-proposed) [5.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted metview [arm64] (disco-proposed) [5.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted metview [s390x] (disco-proposed) [5.2.1-1ubuntu1]
-queuebot:#ubuntu-release- New: accepted metview [i386] (disco-proposed) [5.2.1-1ubuntu1]
User15: User10 "fixed"?  Do I want to know? :P
User10: infinity, I added the 64 bit to snprintf
User10: instead of removing it elsewhere
User10: one liner patch :)
User10: also uploaded in debian
User10: 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
-queuebot:#ubuntu-release- Unapproved: accepted gnu-smalltalk [source] (disco-proposed) [3.2.5-1.2~build1]
-queuebot:#ubuntu-release- Unapproved: libkolabxml (disco-proposed/universe) [1.1.6-3build2 => 1.1.6-3ubuntu1] (kubuntu)
-queuebot:#ubuntu-release- Unapproved: accepted libkolabxml [source] (disco-proposed) [1.1.6-3ubuntu1]
User9: User15 if you run out of perl errors, comedilib could be for you
User15: User9 Easy fix (#include <sys/sysmacros.h>)
 * infinity checks for an upstream commit before JFDIing it.
User9: and of course cctools
User9: then dulwich for s390x is left, and then python3.6 should be removable
User15: https://github.com/Linux-Comedi/comedilib/commit/3f8514739a2d799d2e6dbb6cd43a7f6bb624a319#diff-e8acc63b1e238f3255c900eed37254b8
User15: "Also include random stuff we don't use because why not."
User15: Solid work, upstream.
User4: User15 Qt should be bootstrapped in Bileto 3458 by this evening.
User4: I assume we still don't want tangling with Perl? :P
User15: User4 We definitely don't.
User4: Alright.
User4: 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
User10: general question... how can perl entangle with qt?
User10: I mean, the tracker shows no qt packages, even in update excuses I can't find any qt package...
User10: a good point might "it regresses testsuites"
User4: Yeah, if I recall correctly it was something along those lines.
User4: In general it's just better to do them separately I think.
User10: I'm not saying to do it now :) I was wondering about something else
User10: I'm finishing gdbm and maybe llvm if everything is good
User4: Ah.
User4: 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.
User4: My lunch is about done though, so other eyes would be encouraged. :)
-queuebot:#ubuntu-release- Unapproved: comedilib (disco-proposed/universe) [0.10.2-4build10 => 0.10.2-4ubuntu1] (no packageset)
User15: comedilib fixed, I have no idea about cctools...
-queuebot:#ubuntu-release- Unapproved: accepted comedilib [source] (disco-proposed) [0.10.2-4ubuntu1]
-queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.0.4-0ubuntu1 => 2:12.0.5-0ubuntu1] (openstack, ubuntu-server)
-queuebot:#ubuntu-release- Unapproved: ubiquity (disco-proposed/main) [18.10.12 => 19.04.1] (core)
User12: infinity, Laney - oneliner is good, uploaded.
User12: LocutusOfBorg, tsimonq2 - some library must have a Qt gui, and a perl binding. meaning if one is uninstallable, the other can't migrate.
-queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.12]
-queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (xenial-proposed) [4.3.0-1ubuntu91.69.162.6]
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.39]
-queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [18.1-59-g0f993084-0ubuntu1~16.04.1]
-queuebot:#ubuntu-release- Unapproved: rejected livecd-rootfs [source] (xenial-proposed) [2.408.40]
-queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.38 => 2.408.40] (desktop-core)
User16: User15 did you build the no changes rebuild of nginx for disco using 1.15.5-0ubuntu2 from cosmic-proposed?
User16: i see you uploaded the no change rebuild for the perl 5.28 transition, was wondering whether you included that changeset from 0ubuntu2
User15: User16 You could just look. ;)
User15: User16 http://launchpadlibrarian.net/395789060/nginx_1.15.5-0ubuntu1_1.15.5-0ubuntu3.diff.gz
User16: User15 i could.  except LP's timing out :P
User16: all i've got to go on is ahasenack's email message on the SRU bug.  :P
User2: xnox, User9 LP: #1801901 done
User7: Launchpad bug 1801901 in libextutils-parsexs-perl (Ubuntu) "RM libextutils-parsexs-perl broken with new perl" [Undecided,Fix released] https://launchpad.net/bugs/1801901
User16: User15 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.
User16: (not ever sure the policies when two teams have jurisdiction heh
User15: User16 If the SRU is verified already, it's entirely fine for security to build on top of it and just release.  *shrug*
User16: yep.  it's verification done after the three hours of testing and production live testing i did heh
User16: User15 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?
User15: User16 It can wait.
User16: ack.
User15: User16 Anyone running production servers on disco right now is looney.
User16: just thought I'd ask while its on my mind :)
User15: With a side of tooney.
User16: heh
User16: User15 true that.
User2: User4 do you know why your newly-merged lintian fails autopkgtests on !amd64?
User2: User4 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
User4: User2 I did have to go AFK when I started looking at it, so that's not definitively my answer.
User4: But, I'm not sure.
User2: heh, so perl's own autopkgtests are failing? not a good sign
User2: bash: prove: command not found
User2: lovely
User15: Oh, isn't that fun.
User15: 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.
User15: Debian only running tests on amd64 does us no favours. :/
User4: Just independently reached the same conclusion (and grumbling). :P
User4: User15 Want to file a bug or should I?
User4: (In Debian.)
User15: User4 Go nuts.
User15: My reportbug seems to be broken right now. :/
User4: (Shh, don't tell anyone I don't use reportbug. >_>)
User2: User15 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
User15: User2 Oh, that test that can't find 'prove' doesn't depend on perl? :P
User2: correct
User15: Kay.  I was in a panic making sure /usr/bin/prove was still there (which it is).
User2: was probably introduced after the last perl abi transition
User2: so never failed because perl never found itself removed instead of upgraded
User15: User2 Badtesting is fine, but please file a bug?
User2: yes
User15: (confirming the test passes locally with perl installed might be nice too)
-queuebot:#ubuntu-release- Unapproved: accepted neutron [source] (bionic-proposed) [2:12.0.5-0ubuntu1]
User15: Can we petition Debian to pick some random $fast_arch where they can easily get cycles (ie: ppc64el) and run autopkgtest there too? :P
User15: Dealing with all the "it only works on amd64" tests ourselves sucks.
User2: User15 local test> done
-queuebot:#ubuntu-release- Unapproved: accepted samba [source] (bionic-proposed) [2:4.7.6+dfsg~ubuntu-0ubuntu2.3]
User10: automake now "fails" autopkgtestsuite on arm64, but the real reason is that new tests have been added by debian...
User10: instead of trying a self no-change-rebuild now it does a real "make check"
User2: huh, why did I upload trnascan-se but not remove the ANAIS binaries :P
User16: User2 not enough coffee :p
-queuebot:#ubuntu-release- Unapproved: llvm-defaults (disco-proposed/universe) [0.44 => 0.45] (no packageset) (sync)
User2: User16 a highly implausible hypothesis
User16: heh
User2: I mean, the only thing that saves me is that I have to walk to the kitchen for the espresso machine
User4: Does someone recall if arch:all packages can be Multi-Arch: foreign?
User2: they can
User4: Thanks.
-queuebot:#ubuntu-release- Unapproved: accepted mutter [source] (bionic-proposed) [3.28.3-2~ubuntu18.04.2]
User16: User2 well, you never know :P
User16: i keep a coffee maker at my desk not 3 feet away from me :P
User16: because NEVER ENOUGH COFFEE!!!! *chugs another cup, making that his 6th of the day*
-queuebot:#ubuntu-release- Unapproved: accepted python-openstackclient [source] (bionic-proposed) [3.14.2-0ubuntu1]
-queuebot:#ubuntu-release- Unapproved: linux-firmware (disco-proposed/main) [1.175 => 1.176] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.3]
User1: OMG EMPTY AUTOPKGTEST QUEUES??
-queuebot:#ubuntu-release- Unapproved: linux-firmware (cosmic-proposed/main) [1.175 => 1.175.1] (core, kernel)
User2: not on s390x yet... :)
User15: Wait, really?
-queuebot:#ubuntu-release- Unapproved: linux-firmware (bionic-proposed/main) [1.173.1 => 1.173.2] (core, kernel)
-queuebot:#ubuntu-release- Unapproved: linux-firmware (xenial-proposed/main) [1.157.20 => 1.157.21] (core, kernel)
User15: Quick, retry everything.
User15: Guess I need to fix those last 5 packages.
User15: 6.
User2: which ones do you mean?
User1: yeah not s390x yet
User15: http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.28.html
-queuebot:#ubuntu-release- Unapproved: accepted gnome-calculator [source] (bionic-proposed) [1:3.28.2-1~ubuntu18.04.1]
User2: k
User16: *hands infinity the "Retry Perl Autopkgtest hell" button just to push a ton of autopkgtests into the queue*
User15: oping is easy enough.  slic3r can, I think, be reverted and punted.
User15: The other 3 are mildly confusing.
User1: but that won't take long i assume
User2: libnet-ldns-perl : Depends: perlapi-5.26.0
User2: doesn't look confusing to me
User2: or is that the wrong version?
User2: ah ftbfs
User15: User2 The FTBFS is confusing. :P
User15: Or, rather, why the testsuite seems to have spontaenously regressed.
User15: But hasn't done so in Debian.
User15: And I don't think our networks suddenly got even more restrictive than they already were.
User2: 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?
User7: 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
-queuebot:#ubuntu-release- Unapproved: liboping (disco-proposed/universe) [1.10.0-2.1build1 => 1.10.0-2.1ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted liboping [source] (disco-proposed) [1.10.0-2.1ubuntu1]
-queuebot:#ubuntu-release- Unapproved: slic3r (disco-proposed/universe) [1.2.9+dfsg-9 => 1.2.9+dfsg-9build1] (no packageset)
User15: User2 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?
User2: User15 remove from release pocket and not demote, yes
-queuebot:#ubuntu-release- Unapproved: accepted slic3r [source] (disco-proposed) [1.2.9+dfsg-9build1]
User15: User2 Well, remove from release pocket is functionally demote, since there's an FTBFS version in proposed. :)
User15: User2 And keeping that there avoids it being a new autosync later.
User2: User15 ah :)
 * infinity shrugs.
 * infinity thwacks it.
User10: infinity, I was fixing polymake right now
User10: https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/15618448
User15: User2 nf{log,queue}-bindings have 3-month old RC bugs and testing removals with no response.  They can probably go too.
User15: User10 Please don't update to a new upstream version unless you're sure it's the same orig Debian will use.
User15: Such a headache otherwise.
User10: infinity, I never do this
User10: if it works, I'll extract the new upstream release as patch on top of the old one
User10: right now, I don't care because it is my ppa
User4: User15 Home now; my theory earlier was that it had to do with the change from ${architecture} -> arch:all in the template files.
User10: and yes, I agree with you basically
User10: bad github regenrating tarballs
User15: User10 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*
User15: You do you, though.  It's removed from the release pocket, so it won't be holding up the transition either way.
User10: infinity, there is a previous PR that bremner never addressed...
User10: I pinged him some minutes ago, lets see
User10: anyway, as you say, I can upload if it works, or not, who cares?
User10: 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
User15: User10 He literally said he'd look at it in a week in the bug.
User15: User10 That was a couple of days ago.
User2: User15 no objections there either
User10: I'm also looking at slic3r, thanks for doing the dirty job :)
User10: infinity, I cant find it here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912174
User7: Debian bug 912174 in src:polymake "polymake FTBFS: test failure" [Serious,Open]
User15: User10 The other bug.
User15: User10 The boost one.
User10: oh the other one yes
User10: I don't usually look to what is not RC :)
User15: I mean, they're both RC, one of them just has the wrong severity set. :P
User15: For whatever bizarre reason.
User15: Oh, the boost one isn't RC cause the transition hasn't started in Debian yet.
User15: 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.
User10: yes, that one
-queuebot:#ubuntu-release- Unapproved: polymake (disco-proposed/universe) [3.2r2-3build1 => 3.2r2-3ubuntu1] (no packageset)
User15: Oh, libnet-ldns-perl was failing in cosmic way back in July already.
User15: Aaaand, it used to ignore the testsuite.
User15: 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
 * infinity will remove, rebuild the old one, then put the new one back post-transition.
User10: infinity, slic3r is not really BE friendly, and the system admesh is not a drop-in replacement for it
User10: calculate_normals doesn't exist e.g.
User10: so, removing it from s390x is the best thing we can do, I presume debian will do the same
User10: I know you already did some work in another way, just saying that I'm stopping the porting work
User15: User10 If that's what happens later, that's fine, but for now, it's reverted to the old version and it's happy.
User10: yep I know, just saying that I'm stopping for now the perl/gdbm/foo work
-queuebot:#ubuntu-release- Unapproved: libnet-ldns-perl (disco-proposed/universe) [0.75-3 => 0.75-3build1] (no packageset)
User4: User15 Assuming Debian's bug tracker likes me today, that bug is filed and you should also get an email.
User4: Now, that isn't always the case. >_>
User15: User10 Updating to a new version wholesale via a patch is really gross. :/
-queuebot:#ubuntu-release- Unapproved: accepted libnet-ldns-perl [source] (disco-proposed) [0.75-3build1]
-queuebot:#ubuntu-release- Unapproved: accepted polymake [source] (disco-proposed) [3.2r2-3ubuntu1]
User2: User15 whenever ldns gets sorted, libzonemaster-perl needs its autopkgtests retried too
User10: infinity, why should we care? :)
User10: at least it doesn't make the archive look bad wrt new tarballs
User10: I could have polished it, but meh
User10: it will get sorted before disco is out :)
User15: User10 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.
User15: But I very much care about such madness in general, cause it's not maintainable long-term.
User10: infinity, if it gets non-maintainable, it will get removed, if debian stops maintaining it
User15: ...?
User15: Debian isn't maintaining what you did in Ubuntu.
User10: but you are speaking to a person who has *all* his packages in sync with debian, so I agree with you
User10: 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
User10: in case it gets removed from testing, we can do the same I would say
User10: 99% debian will update to new release and I'll force-sync
User10: 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
 * LocutusOfBorg looks llvm finish its build finally
 * LocutusOfBorg and goes afk
User4: User15 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.
User4: 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.
User4: *Plasma
User15: User4 I have no good opinions right now.
User15: User4 Also, you always have the problem where you can't really know the user's intent, and forcefully removing packages isn't nice.
User4: User15 That is true.
User15: User4 (we punted on that in Ubuntu when we moved to gnome-shell and left unity installed, for instance)
User4: Got it.
User4: I guess we'll continue to push the documentation we wrote out for cleaning up the upgrades. :P
User4: User15 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
User4: It just *feels* hacky but I guess something of that sort is an option.
User15: User4 Very not nice.
User4: User15 Is turning off upgrades an option?
User4: (Similar to what happened with i386.)
User15: That is potentially an option.  Talk to Brian about that, maybe.
User4: User5 Hello. ^
User4: User5 tl;dr, is turning off Lubuntu 18.04 -> * upgrades an option?
User5: User4 Why would it be turned it off for Lubuntu?
User4: User5 We changed desktops from LXDE to LXQt and pretty much every component was switched out.
User4: User5 Upgrades are a mess; clean installs are very much preferred.
User5: tsimonq2, User15 well it should be technically possible to prevent the upgrade
User4: 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...
User4: But it would also be nice to be able to put flavor-specific release notes regardless...
User4: (Natively in the upgrader.)
-queuebot:#ubuntu-release- New binary: polymake [s390x] (disco-proposed/universe) [3.2r2-3ubuntu1] (no packageset)
User9: User15 no bug report for comedilib in debian?
-queuebot:#ubuntu-release- New: accepted polymake [s390x] (disco-proposed) [3.2r2-3ubuntu1]
User9: User15 ok, removed cctools, no rdeps
User15: User9 My reportbug is broken, submittodebian doesn't work, and I blame you. :P
User15: Querying Debian BTS for reports on comedilib (source)...
User15: Unable to connect to Debian BTS (error: "TypeError("fixer() missing 1 required positional argument: 'check_hostname'")"); continue [y|N|?]?
User9: blaming doesn't fix it, and I have to fix the glibc ftbfs'es myself as well ;p
User15: I mean, I guess it doesn't need to talk to the BTS to send a bug email.
User15: There, submitted.
User9: is there an easy way to re-run all python related autopkg tests with all-proposed? would be a good time, because the machines are idle
User15: Why would we want that?
User15: all-proposed doesn't actually test what we want to test, generally.
User9: scroll back, you are even highlighted
User15: If it did, it would be the default.
User9: the tests pick up python3-defaults from the release pocket which has 3.6 as supported. but now most packages are built without 3.6 support
User9: or hint python3-defaults into the release pocket
User9: removing a python3 version doesn't add any regressions
User15: Uhm.
User15: Tests triggered by python3-defaults in proposed shouldn't pick up python3-defaults from release.
User15: Example?
User9: no, but all the other tests
User9: pyresample
User9: all (test) dependencies which already migrated, and don't have 3.6 anymore
User15: python-dbusmock needs fixing.
-queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (bionic-proposed) [237-3ubuntu10.5]
User9: User15 it is fixed, the -proposed, but we don't know yet why it doesn't build
User9: and meson and i386
User9: meson on i386
User9: the usual systemd madness
User9: and python-ruffus, but that is already ignored on other archs
-queuebot:#ubuntu-release- Unapproved: dulwich (disco-proposed/universe) [0.19.6-2build1 => 0.19.6-2ubuntu1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted dulwich [source] (disco-proposed) [0.19.6-2ubuntu1]
-queuebot:#ubuntu-release- Unapproved: xindy (disco-proposed/universe) [91.69.162.660104-5 => 91.69.162.660104-5build1] (no packageset)
-queuebot:#ubuntu-release- Unapproved: accepted xindy [source] (disco-proposed) [91.69.162.660104-5build1]
User9: autopkg test queues are empty now \o/
-queuebot:#ubuntu-release- New binary: polymake [amd64] (disco-proposed/universe) [3.2r2-3ubuntu1] (no packageset)
-queuebot:#ubuntu-release- New: accepted polymake [amd64] (disco-proposed) [3.2r2-3ubuntu1]
User1: User15 python-dbusmock builds locally, i have _no_ idea what is going on in the buildds
User1: User15 but maybe you know more about how the environments might differ? :)
User1: User15 also the one in release only fails autopkgtests because of warning on stderr, i think overriding that one is totally sane
User1: oh and the meson/i386 test has been failing for a while too
User1: i have a bad question about that one: is it possible to know which compute host a test runs on?
User1: User9 remember this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894774
User7: Debian bug 894774 in src:meson "meson fails it's autopkg tests on i386" [Important,Open]
-queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (xenial-proposed/main) [1:16.04.25 => 1:16.04.26] (core)
ubuntu-release
Ubuntu IRC