[06:56] -queuebot:#ubuntu-release- New sync: onetbb (jammy-proposed/primary) [2021.5.0-7]
[06:58] -queuebot:#ubuntu-release- New: accepted onetbb [sync] (jammy-proposed) [2021.5.0-7]
[06:58] -queuebot:#ubuntu-release- New: accepted sdl12-compat [amd64] (jammy-proposed) [1.2.52-3]
[06:58] -queuebot:#ubuntu-release- New: accepted sdl12-compat [armhf] (jammy-proposed) [1.2.52-3]
[06:58] -queuebot:#ubuntu-release- New: accepted sdl12-compat [riscv64] (jammy-proposed) [1.2.52-3]
[06:59] -queuebot:#ubuntu-release- New: accepted sdl12-compat [arm64] (jammy-proposed) [1.2.52-3]
[06:59] -queuebot:#ubuntu-release- New: accepted sdl12-compat [s390x] (jammy-proposed) [1.2.52-3]
[06:59] -queuebot:#ubuntu-release- New: accepted sdl12-compat [ppc64el] (jammy-proposed) [1.2.52-3]
[07:39] <seb128> doko, hey, why did you rename the tbb binaries, there is no explanation nor bug reference in the upload. It makes other things in the archive like gtk no build anymore because they use the old naming, should we at least have a provides?
[07:52] <doko> seb128: no libtbb-dev is built by onetbb. I'll go through the r-dependencies, and change those to libtbb2-dev which still require the old tbb. work in progress, waiting for the builds
[07:53] <doko> hmm, where exactly is gtk affected?
[07:53] <seb128> doko, https://launchpadlibrarian.net/589580643/buildlog_ubuntu-jammy-amd64.gtk4_4.6.1+ds-1ubuntu2_BUILDING.txt.gz
[07:53] <seb128>  libtbb12 : Breaks: libtbb2 (< 2021) but 2020.3-1ubuntu1 is to be installed
[07:54] <seb128> doko, also onettb fails to build on riscv64 so gtk isn't going to be able to build there
[07:54] <seb128> which in on the path to have the new GNOME migrating
[07:55] <doko> the fix is uploaded
[07:55] <doko> ok, I'll look at the breaks
[08:01] <doko> ohh crap, libtbb12 ships multiple shared libs, with unrenamed sonames. bad packaging ... ok, I'll remove that again, until I have a solution for that one
[08:01] <seb128> thanks
[08:02] <seb128> we are past feature freeze, new packages should require a ffe anyway at this point
[08:04] <doko> this package was there, and only was removed yesterday.
[08:06] -queuebot:#ubuntu-release- Packageset: Removed mozjs78 from i386-whitelist in jammy
[08:06] -queuebot:#ubuntu-release- Packageset: Removed shtool from i386-whitelist in jammy
[08:06] -queuebot:#ubuntu-release- Packageset: Added gcc-12-cross-ports to i386-whitelist in jammy
[08:06] -queuebot:#ubuntu-release- Packageset: Added onetbb to i386-whitelist in jammy
[08:06] -queuebot:#ubuntu-release- Packageset: Added postgresql-common to i386-whitelist in jammy
[08:06] -queuebot:#ubuntu-release- Packageset: Added racc to i386-whitelist in jammy
[08:06] -queuebot:#ubuntu-release- Packageset: Added rubocop to i386-whitelist in jammy
[08:06] -queuebot:#ubuntu-release- Packageset: Added ruby-ast to i386-whitelist in jammy
[08:06] -queuebot:#ubuntu-release- Packageset: Added ruby-mini-portile2 to i386-whitelist in jammy
[08:06] -queuebot:#ubuntu-release- Packageset: Added ruby-parallel to i386-whitelist in jammy
[08:07] -queuebot:#ubuntu-release- Packageset: Added ruby-rainbow to i386-whitelist in jammy
[08:07] -queuebot:#ubuntu-release- Packageset: Added ruby-regexp-parser to i386-whitelist in jammy
[08:07] -queuebot:#ubuntu-release- Packageset: Added ruby-rubocop-ast to i386-whitelist in jammy
[08:07] -queuebot:#ubuntu-release- Packageset: Added ruby-unicode-display-width to i386-whitelist in jammy
[08:07] -queuebot:#ubuntu-release- Packageset: Added ruby-whitequark-parser to i386-whitelist in jammy
[08:07] -queuebot:#ubuntu-release- Packageset: Added ssl-cert to i386-whitelist in jammy
=== michagogo is now known as micha_
[09:06] -queuebot:#ubuntu-release- New binary: tbb [i386] (jammy-proposed/universe) [2020.3-1ubuntu2] (i386-whitelist, kubuntu)
[09:07] -queuebot:#ubuntu-release- New binary: tbb [amd64] (jammy-proposed/universe) [2020.3-1ubuntu2] (i386-whitelist, kubuntu)
[09:10] -queuebot:#ubuntu-release- New binary: tbb [s390x] (jammy-proposed/universe) [2020.3-1ubuntu2] (i386-whitelist, kubuntu)
[09:14] -queuebot:#ubuntu-release- New binary: tbb [ppc64el] (jammy-proposed/universe) [2020.3-1ubuntu2] (i386-whitelist, kubuntu)
[09:21] -queuebot:#ubuntu-release- New binary: tbb [riscv64] (jammy-proposed/universe) [2020.3-1ubuntu2] (i386-whitelist, kubuntu)
[09:26] <seb128> sil2100, hey, any chance you could retry https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/jammy/ubuntu-canary ? it failed again on that
[09:26] <seb128> ! Could not open (any of):
[09:26] <seb128> !   http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.jammy/STRUCTURE
[09:26] <ubottu> seb128: I am only a bot, please don't think I'm intelligent :)
[09:26] <seb128> but the ubuntu iso built today so that seems a flaky error
[09:27] <seb128> sil2100, also if you retry you might need to tweak your cmd, the retry you did yesterday didn't include the canary ppa archive according to the log
[09:27] <sil2100> seb128: oh, crap, right - forgot about that. Let me do that via ancientminister then
[09:27] <seb128> sil2100, thx
[09:28] <sil2100> seb128: btw. how are you guys using the canary PPA? Is that like a staging fast-development thing before landing in the archive?
[09:29] <seb128> sil2100, yes, it's either for testing candidate fixes, or in this case I added debug code in an hacked version of livecd-rootfs to try to debug https://bugs.launchpad.net/launchpad-buildd/+bug/1963706
[09:29] <ubottu> Launchpad bug 1963706 in launchpad-buildd "Ubuntu Desktop Canary ISO failing to build since builders update" [High, New]
[09:30] <seb128> sil2100, but most of the time the ppa is empty
[09:30] <sil2100> seb128: ok, good, thanks!
[09:30] <seb128> np!
[09:38] -queuebot:#ubuntu-release- New binary: tbb [arm64] (jammy-proposed/universe) [2020.3-1ubuntu2] (i386-whitelist, kubuntu)
[09:39] -queuebot:#ubuntu-release- New binary: tbb [armhf] (jammy-proposed/universe) [2020.3-1ubuntu2] (i386-whitelist, kubuntu)
[09:40] <juliank> sil2100: Let's force-skiptest netcat-openbsd/1.218-4ubuntu1 then I guess, my retry with new gsocket did not help britney either, let's migrate it, and hope britney doesn't crap out again
[09:41] -queuebot:#ubuntu-release- New: accepted tbb [amd64] (jammy-proposed) [2020.3-1ubuntu2]
[09:41] -queuebot:#ubuntu-release- New: accepted tbb [armhf] (jammy-proposed) [2020.3-1ubuntu2]
[09:41] -queuebot:#ubuntu-release- New: accepted tbb [ppc64el] (jammy-proposed) [2020.3-1ubuntu2]
[09:41] -queuebot:#ubuntu-release- New: accepted tbb [s390x] (jammy-proposed) [2020.3-1ubuntu2]
[09:41] -queuebot:#ubuntu-release- New: accepted tbb [arm64] (jammy-proposed) [2020.3-1ubuntu2]
[09:41] -queuebot:#ubuntu-release- New: accepted tbb [riscv64] (jammy-proposed) [2020.3-1ubuntu2]
[09:41] -queuebot:#ubuntu-release- New: accepted tbb [i386] (jammy-proposed) [2020.3-1ubuntu2]
[09:41] -queuebot:#ubuntu-release- New: accepted python-unicodedata2 [sync] (jammy-proposed) [14.0.0+ds-8]
[09:44] -queuebot:#ubuntu-release- New binary: python-unicodedata2 [amd64] (jammy-proposed/none) [14.0.0+ds-8] (no packageset)
[09:44] -queuebot:#ubuntu-release- New binary: python-unicodedata2 [s390x] (jammy-proposed/none) [14.0.0+ds-8] (no packageset)
[09:44] -queuebot:#ubuntu-release- New binary: python-unicodedata2 [ppc64el] (jammy-proposed/none) [14.0.0+ds-8] (no packageset)
[09:46] -queuebot:#ubuntu-release- New binary: python-unicodedata2 [arm64] (jammy-proposed/universe) [14.0.0+ds-8] (no packageset)
[09:46] -queuebot:#ubuntu-release- New binary: python-unicodedata2 [armhf] (jammy-proposed/universe) [14.0.0+ds-8] (no packageset)
[10:01] <juliank> restarting lxd-armhf2, it has a broken lxd
[10:02] <sil2100> seb128: hm, this one failed even weirder? https://launchpadlibrarian.net/589592686/buildlog_ubuntu_jammy_amd64_ubuntu-canary_BUILDING.txt.gz
[10:02] <juliank> sigh @ " A stop job is running for Service f?tion lxd.daemon (4min 48s / 10min)"
[10:03] <seb128> sil2100, no, that one is expected, that's https://bugs.launchpad.net/launchpad-buildd/+bug/1963706 I mentioned
[10:03] <ubottu> Launchpad bug 1963706 in launchpad-buildd "Ubuntu Desktop Canary ISO failing to build since builders update" [High, New]
[10:03] <seb128> sil2100, the snap preseeding is failing since the buildd have been updated to focal, the snapd team think we might get out of loop devices, I was trying to get more info by making it call journalctl on the failure
[10:03] <juliank> grub having a 30s timeout on cloud images is hilarious too
[10:03] <sil2100> juliank: ACK, let me skiptest it in this case. It's weird to me that it's still having problems...
[10:04] <seb128> sil2100, the ls /dev in the log also shows it has only 8 loop devices which I think helps
[10:04] <seb128> I'm going to go back to the launchpad team with that
[10:04] <seb128> sil2100, by 'helps' I mean to show that it has only that number, that's probably why snapd is failing
[10:07] <juliank> seb128: I think it's unable to run a migration-reference/0 and hence does not know the baseline
[10:07] <juliank> ugh
[10:07] <juliank> sil2100:
[10:10] <sil2100> Hint pushed
[10:10] -queuebot:#ubuntu-release- New binary: python-unicodedata2 [riscv64] (jammy-proposed/universe) [14.0.0+ds-8] (no packageset)
[10:26] <juliank> rabbitmq restarting, britney may lose some test requests
[10:26] <juliank> rather it thinks it queued them but didn't
[10:26] <juliank> It was supposed to restart a while ago, but the restart service was running as wrong user :(
[10:27] <juliank> Mär 08 10:25:54 juju-4d1272-prod-proposed-migration-8 maybe-restart-rabbitmq[751346]: connection_other: 1.6861 gb (57.04%)
[10:27] <juliank> who doesn't love that
[10:28] <juliank> not sure what ` maybe-restart-rabbitmq[751346]: other_system: 18446744073.7914 gb (624023093593.84%)` is all about ...
[13:17] <coreycb> doko: I maybe be hitting an issue with the new gcc-9-cross in focal. https://paste.ubuntu.com/p/7gqYM7QtKp/ it seems to be missing a closing bracket for one of the extern "C" {
[13:24] <coreycb> contents of /usr/lib/gcc-cross/aarch64-linux-gnu/9/include/arm_acle.h: https://paste.ubuntu.com/p/W5PmcNqJY5/
[15:24] -queuebot:#ubuntu-release- New binary: webkit2gtk [amd64] (jammy-proposed/main) [2.35.90-1ubuntu1] (desktop-core, i386-whitelist)
[15:39] -queuebot:#ubuntu-release- New binary: webkit2gtk [ppc64el] (jammy-proposed/main) [2.35.90-1ubuntu1] (desktop-core, i386-whitelist)
[15:39] -queuebot:#ubuntu-release- New binary: webkit2gtk [s390x] (jammy-proposed/main) [2.35.90-1ubuntu1] (desktop-core, i386-whitelist)
[15:48] <jochensp> with open3d working in proposed (thx mwhudson), can someone drop the old ppc64el binary so it can transition? (still no idea about the build failure)
[15:54] <bdmurray> ^ AA ping
[15:57] <seb128> that's not how things work, there is a valid build on that arch in the release pocket, the way you get it to migrate is by fixing the build failure in the candidate
[15:57] <seb128> or if it can't be built there you remove the arch from the control and ask to remove the binary from release in a bug that documents why
[15:58] <jochensp> (in Debian I would just fill a removal bug for ftp..)
[15:59] <jochensp> also it builds fine in Debian ppc64el so if someone can help with doing the necessary dance for Ubuntu I would appreciate
[16:01] <bdmurray> The build failure looks lto related
[16:01] <bdmurray> https://launchpadlibrarian.net/589594556/buildlog_ubuntu-jammy-ppc64el.open3d_0.14.1+dfsg-7build2_BUILDING.txt.gz
[16:02] <jochensp> yeah it seems to use custom CXXFLAGS (like -O3) I don't know where they come from
[16:04] <jbicha> Ubuntu's ppc64el uses -O3; it's the only Ubuntu release architecture to do that
[16:05] <vorlon> seb128: fyi the "flaky error" is whenever the build lands on the unlucky cloud region (lcy02)
[16:05] <seb128> vorlon, ah, thanks
[16:06] <jochensp> jbicha: good to know, are there any other flags (LTO?) custom for ppc64el?
[16:07] <jbicha> -O3 is the only thing special about ppc64el I know of
[16:08] <vorlon> right, LTO is used across all our 64-bit archs, but there can be arch-specific implementation bugs
[16:09] <jochensp> yeah, we worked around LTO in build2 but it still FTBFS on ppc64el, that's why I wonder (and I don't think anyone uses open3d on ppc64el and there are no rdeps so dropping it seams easy)
[16:23] <jochensp> seb128: where should the bug go? (given that open3d builds fine in Debian)
[16:24] <seb128> jochensp, Ubuntu uses launchpad so on https://bugs.launchpad.net/ubuntu/+source/open3d/+filebug
[16:24] <seb128> jochensp, there is https://bugs.launchpad.net/ubuntu/+source/open3d/+bug/1963556 but I don't know if that's the same issue
[16:24] <ubottu> Launchpad bug 1963556 in open3d (Ubuntu) "Open3D segfaults when compiled with LTO" [Undecided, Confirmed]
[16:25] <jochensp> (that's by me) no, that one is fixed with build2
[16:25] <jochensp> filled: https://bugs.launchpad.net/ubuntu/+source/open3d/+bug/1964154
[16:25] <ubottu> Launchpad bug 1964154 in open3d (Ubuntu) "Fails to build on ppc64el due custom compiler flags" [Undecided, New]
[16:26] <jochensp> can someone upload a build2 with ppc64el removed from the archs? (not sure I'm allowed to upload to the queue)
[16:28] <vorlon> that's not what we would do here; we would remove the previous open3d binaries from the archive, no source changes or reupload required
[16:30] <jochensp> that would be great (and was my initial request)
[16:30] <vorlon> as open3d has no reverse-depends, that's probably fine, though on the Canonical side we are generally trying to maintain coverage equal to Debian so I'll at least have a cursory look
[16:31] <vorlon> this looks like a candidate for a source upload that just sets DEB_BUILD_MAINT_OPTIONS=optimize=-lto on ppc64el
[16:31] <jochensp> vorlon: it is in the lto-disabled-list already (but maybe still worth a try)
[16:32] <vorlon> ah true, I don't see any of the lto commandline args passed to the compiler
[16:33] <vorlon> ok so the toolchain is broken, has any bug been opened on gcc for this?
[16:33] <jochensp> I'm not aware of a bug for that (I assumed different compiler flags till now)
[16:33] <vorlon> anyway, binary removal here seems entirely appropriate
[16:35] <coreycb> bdmurray: hello, if you get a chance I'd like to see if we can get the impish changes reviewed for #1960636. also I have a python-glance-store upload that needs rejecting in the impish queue.
[16:37] -queuebot:#ubuntu-release- Unapproved: rejected python-glance-store [source] (impish-proposed) [3.0.0-0ubuntu1]
[16:37] <bdmurray> vorlon: Do you need anything more for bug 1964152?
[16:37] <ubottu> Bug 1964152 in tasksel (Ubuntu Jammy) "removal request for tasksel" [Undecided, Confirmed] https://launchpad.net/bugs/1964152
[17:21] -queuebot:#ubuntu-release- Unapproved: accepted vitrage [source] (impish-proposed) [7.5.0-0ubuntu2]
[17:24] -queuebot:#ubuntu-release- Unapproved: accepted networking-baremetal [source] (impish-proposed) [5.0.0-0ubuntu2]
[17:26] -queuebot:#ubuntu-release- Unapproved: accepted glance [source] (impish-proposed) [2:23.0.0-0ubuntu2]
[17:28] -queuebot:#ubuntu-release- Unapproved: accepted aodh [source] (impish-proposed) [1:13.0.0-0ubuntu2]
[17:31] -queuebot:#ubuntu-release- Unapproved: accepted barbican [source] (impish-proposed) [2:13.0.0-0ubuntu1.1]
[17:43] <vorlon> bdmurray: you should output of reverse-depends -a source but not reverse-depends without -a source?
[17:43] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (impish-proposed) [2:19.0.0-0ubuntu3]
[17:43] <vorlon> bdmurray: also given that it's tasksel, worth checking if it's seeded anywhere... which it is (ubuntustudio)
[17:44] <Eickmeyer> Wierd...
[17:44]  * Eickmeyer looks
[17:45] <bdmurray> vorlon: ack
[17:46] <Eickmeyer> vorlon, bdmurray: That means something is pulling it in. Any clue which package, or do I need to investigate?
[17:46] <bdmurray> Eickmeyer: ubiquity used to depend on it
[17:46] <Eickmeyer> bdmurray: We don't use ubiquity as of 20.10.
[17:47] <vorlon> Eickmeyer: multimedia-tasks depends on it
[17:47] <Eickmeyer> Hmmmm...
[17:47] -queuebot:#ubuntu-release- Unapproved: accepted designate [source] (impish-proposed) [1:13.0.0-0ubuntu2]
[17:47] <vorlon> which is a dep of multimedia-puredata
[17:48] <vorlon> anyway, it appears there is definitely some revdep work to be done on tasksel before it's fit for removal
[17:48] <bdmurray> vorlon: yeah, I see that now thanks. It can move to universe in the meantime though.
[17:49] <Eickmeyer> Which is a dep of puredata.
[17:50] <Eickmeyer> Actually, it's a suggests, not a dep.
[17:52] -queuebot:#ubuntu-release- New source: onetbb (jammy-proposed/primary) [2021.5.0-7ubuntu2]
[17:54] -queuebot:#ubuntu-release- New: accepted onetbb [source] (jammy-proposed) [2021.5.0-7ubuntu2]
[17:54] -queuebot:#ubuntu-release- New: accepted python-unicodedata2 [arm64] (jammy-proposed) [14.0.0+ds-8]
[17:54] -queuebot:#ubuntu-release- New: accepted python-unicodedata2 [ppc64el] (jammy-proposed) [14.0.0+ds-8]
[17:54] -queuebot:#ubuntu-release- New: accepted python-unicodedata2 [s390x] (jammy-proposed) [14.0.0+ds-8]
[17:54] -queuebot:#ubuntu-release- New: accepted webkit2gtk [ppc64el] (jammy-proposed) [2.35.90-1ubuntu1]
[17:54] -queuebot:#ubuntu-release- New: accepted python-unicodedata2 [amd64] (jammy-proposed) [14.0.0+ds-8]
[17:54] -queuebot:#ubuntu-release- New: accepted python-unicodedata2 [riscv64] (jammy-proposed) [14.0.0+ds-8]
[17:54] -queuebot:#ubuntu-release- New: accepted webkit2gtk [s390x] (jammy-proposed) [2.35.90-1ubuntu1]
[17:54] -queuebot:#ubuntu-release- New: accepted python-unicodedata2 [armhf] (jammy-proposed) [14.0.0+ds-8]
[17:54] -queuebot:#ubuntu-release- New: accepted webkit2gtk [amd64] (jammy-proposed) [2.35.90-1ubuntu1]
[18:09] -queuebot:#ubuntu-release- New binary: onetbb [i386] (jammy-proposed/universe) [2021.5.0-7ubuntu2] (i386-whitelist)
[18:09] -queuebot:#ubuntu-release- New: accepted onetbb [i386] (jammy-proposed) [2021.5.0-7ubuntu2]
[18:29] <ahasenack> hi release team, is this the live jammy release notes document? https://discourse.ubuntu.com/t/jammy-jellyfish-release-notes/24668
[18:29] <ahasenack> i.e., can I start adding stuff there without fear of it being lost once the real release notes are published?
[18:30] <ahasenack> I wanted to highlight a change from focal, which is udp nfs mounts are disabled (since groovy), and that caught me (and one other person at least) by surprise: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1964093/comments/5
[18:30] <ubottu> Launchpad bug 1964093 in linux (Ubuntu) "nfsver=3,udp not working anymore" [Undecided, Confirmed]
[18:31] <ahasenack> (and for a moment I thought it was my nfs-utils version bump that caused it)
[18:31] <bdmurray> ahasenack: It is
[18:31] <ahasenack> k
[18:31] <bdmurray> ahasenack: and thank you for thinking about the release notes!
[18:32] <ahasenack> cheers :)
[18:35] <Eickmeyer> ubuntu-archive: Still looking for a review for show-in-file-manager to resolve a Python 3.10 compatibility issue with rapid-photo-downloader.
[18:35] <Eickmeyer> Convoluted, I know, but it's related to a new version of r-p-d.
[18:35] <ahasenack> ok, noted down, maybe someone can make the text better, but the most important bit is there
=== chiluk_ is now known as chiluk
[19:18] -queuebot:#ubuntu-release- Unapproved: accepted postgresql-13 [source] (impish-proposed) [13.6-0ubuntu0.21.10.1]
[20:13] <vorlon> so why has a no-change rebuild of python-leidenalg incorrectly dropped the dependency on python3-igraph?
[20:29] -queuebot:#ubuntu-release- Unapproved: rejected glibc [source] (focal-proposed) [2.31-0ubuntu9.6]
[20:33] <LocutusOfBorg> vorlon,
[20:33] <LocutusOfBorg> I: dh_python3 pydist:292: Cannot find package that provides python_igraph. Please add package that provides it to Build-Depends or add "python_igraph python3-igraph" line to debian/py3dist-overrides or add proper dependency to Depends by hand and ignore this info.
[20:36] <vorlon> LocutusOfBorg: ok but python3-igraph is a build-dep, so what is the actual fix here?
[20:37] -queuebot:#ubuntu-release- Unapproved: accepted ovn [source] (focal-proposed) [20.03.2-0ubuntu0.20.04.3]
[20:39] <LocutusOfBorg> I blame dh_python
[20:40] <LocutusOfBorg> but I'm checking debian build with newer python3-igraph
[20:40] <LocutusOfBorg> test build might give some hint
[20:42] <LocutusOfBorg> yeah, it fails in Debian too
[20:46] <seb128> vorlon, since when deleting binaries on $arch is an appropriate solution to let things migrated that started failing to build? :/
[20:52] <vorlon> seb128: in reference to open3d?
[20:52] <seb128> vorlon, yes
[20:52] <LocutusOfBorg> its science team, do we care? :)
[20:52] <vorlon> seb128: reverse-depends says it's a leaf package; and the arch-specific regression is a toolchain bug.  I don't see a reason to hold it in -proposed, am I missing something?
[20:53] <vorlon> seb128: in *most* cases where we see a per-arch Ubuntu build failure but not a Debian failure I would hold it because we don't want to regress in Debian, but I think this case is special because it's a toolchain issue
[20:53] <seb128> vorlon, release team in the past always pushed on overwritting test results or $stack issues as it removes the visibility on the issue and lower the pressure to get it fixed at the right place
[20:54] <vorlon> seb128: I opened a bug task on gcc-11 which is the right place for thi
[20:54] <vorlon> s
[20:54] <seb128> vorlon, also it seems highly inconsistent with your position on wanting to kick adsys out of the release pocket because tests were failing on one arch when the package is also Ubuntu specific and a leaf package
[20:55] <vorlon> seb128: adsys needed to get out of the way so the major language transitions could go through.  It was not clear to me at the time that adsys had a pending MIR (that's not one of the things I would ordinarily check) and that as a result it was a package of core interest
[20:56] <vorlon> so my policy there is to not regress test coverage, and the way to do that without holding up python3+perl indefinitely (since the longer it's blocked the more tangled it gets) was to demote the leaf package
[20:56] <seb128> vorlon, I was not speaking about kicking it out for letting python-default migrate, but after the migration was done when I removed the block tag you asked why we were letting a package with a failing test back in release
[20:57] <seb128> I mean I can understand the position than we don't want package broken in the release pocket
[20:57] <seb128> but then I struggle to understand why it's ok for one universe package and not another
[20:57] <vorlon> seb128: in general I think non-existent packages are better than broken packages
[20:58] <vorlon> seb128: but I also found your argument about adsys sufficiently persuasive that I didn't chase it further :)
[20:58] <seb128> :)
[20:58] <seb128> sorry I didn't mean to make an argument around adsys
[20:59] <seb128> I was just genuinely surprised that we considered ok to delete the build on one arch to let a package update migrate when the new version is failing to build
[20:59] <vorlon> yes; in most cases I look for whether Debian ftpmasters have also agreed to remove the architecture support before I do so
[20:59] <seb128> maybe I was dealing more with L_aney for such things in the past and his position is slightly different from yours and just never noticed
[21:00] <vorlon> in fact I took that position over the weekend
[21:02] <seb128> alright
[21:06] <seb128> vorlon, going back to the earlier topic of the ISO build failing when landing on lcy02, do you know if that is tracked by a RT or something? the desktop ISO has been failing for 3 days in a row on amd64, we might be unlucky but still sounds like it's happening often enough at this point that it would be worth getting resolved
[21:07] <vorlon> seb128: I'm afraid I don't know whether it's in an RT; cjwatson has been tracking it from the LP side, and jchittum was the first victim with the cloud images
[21:08] <seb128> cjwatson, jchittum, is that worth reporting a bug or filing a RT is that actively being worked on at this point?
[21:08] <seb128> vorlon, thx
[21:14] <jchittum> seb128: Is it failing early from trying to reach "people.canonical.com"?
[21:14] <jchittum> or is it failing from something related to loop devices?
[21:14] <jchittum> i'm reading back, sorry, bit distracted
[21:15] <jchittum> there is an RT related to failed metadata services related to lcy02
[21:17] <vorlon> jchittum: that's the one
[21:17] <vorlon> it breaks ISO builds also
[21:18] <jchittum> ah, we have an RT and an SF case now
[21:19] <jchittum> so it's escalated to "production" stuff but still no resolution due to the metadate issue
[21:31] <cjwatson> Right, it's in RT and has also been escalated to Bootstack who are the team who can actually do something about it
[21:32] <cjwatson> vorlon,seb128: https://portal.admin.canonical.com/C136237 and https://canonical.my.salesforce.com/5004K00000E8Ncg (with varying degrees of visibility on both of those)
[21:32] <cjwatson> (I can't even see the latter although I'm CCed on it)
[21:33] <cjwatson> It's not necessary to report more bugs/RTs
[21:43] <jchittum> I will say that this is going to cause releasing images for the current set of CVEs to be painful
[21:43] <jchittum> Gonna be a lot of retrying builds
[22:35] <seb128> cjwatson, thanks
[23:50]  * RAOF idly wishes that upstreams would produce deliberate tarballs didn't include .github detritus.