[00:03] -queuebot:#ubuntu-release- New binary: abseil [riscv64] (noble-proposed/main) [20230802.1-3] (i386-whitelist, ubuntu-desktop)
[00:33] -queuebot:#ubuntu-release- New binary: lomiri-session [amd64] (noble-proposed/universe) [0.2-11] (no packageset)
[00:43] <amurray> RAOF: hey I got pinged about LP: #1973322 the other day - what would be needed to revive this from the perspective of the SRU team?
[00:43] -ubottu:#ubuntu-release- Launchpad bug 1973322 in bacula (Ubuntu Jammy) "Bacula for 22.04/Jammy" [Medium, Fix Committed] https://launchpad.net/bugs/1973322
[01:03] <vorlon> would whoever is retrying "Failed to upload" builds in the *release* pocket please stop :P
[01:04] <vorlon> or maybe those were needed retries because of the launchpad outage earlier, well
[01:28] <vorlon> jbicha: you filed Debian bug #1064522 for removal of cpdb-backend-file having confirmed with Till it's not needed, but it has a -0ubuntu2 version in Ubuntu which means it would not normally be "auto"removed from Ubuntu; should we be deleting it here also?
[01:28] -ubottu:#ubuntu-release- Debian bug 1064522 in ftp.debian.org "RM: cpdb-backend-file -- RoQA; unused" [Normal, Closed] https://bugs.debian.org/1064522
[01:37] <vorlon> rmadison is behind; that's not a good sign
[01:38] <vorlon> well, behind by < 2h
[01:39] <vorlon> aw, Debian has removed the omxil-bellagio libraries; now I'll never again have a reason to say 'omxil-bellagio'
[01:46] <sarnold> :(
[03:00] <vorlon> had been doing hourly retries of failed amd64 builds; have now switched to doing hourly retries of all failed builds
[03:01] <vorlon> riscv64 in particular is a bit behind on the qt stack, qtbase-opensource-src was last tried yesterday before libwacom was available and failed, hadn't been retried since
[03:01] -queuebot:#ubuntu-release- New binary: abseil [arm64] (noble-proposed/main) [20230802.1-3] (i386-whitelist, ubuntu-desktop)
[03:03] <vorlon> LocutusOfBorg: ^^ um you're introducing a new soname for abseil, are you going to tell me there's nothing in here that breaks feature freeze?
[03:04] <vorlon> LocutusOfBorg: I'm accepting the new binaries, and also immediately rolling back to the previous version of the package until we can discuss
[03:05] -queuebot:#ubuntu-release- New: accepted abseil [amd64] (noble-proposed) [20230802.1-3]
[03:05] -queuebot:#ubuntu-release- New: accepted abseil [armhf] (noble-proposed) [20230802.1-3]
[03:05] -queuebot:#ubuntu-release- New: accepted abseil [ppc64el] (noble-proposed) [20230802.1-3]
[03:05] -queuebot:#ubuntu-release- New: accepted abseil [s390x] (noble-proposed) [20230802.1-3]
[03:05] -queuebot:#ubuntu-release- New: accepted speech-dispatcher-contrib [i386] (noble-proposed) [0.12.0~rc2-3]
[03:05] -queuebot:#ubuntu-release- New: accepted abseil [arm64] (noble-proposed) [20230802.1-3]
[03:05] -queuebot:#ubuntu-release- New: accepted abseil [riscv64] (noble-proposed) [20230802.1-3]
[03:05] -queuebot:#ubuntu-release- New: accepted abseil [i386] (noble-proposed) [20230802.1-3]
[03:05] -queuebot:#ubuntu-release- New: accepted lomiri-session [amd64] (noble-proposed) [0.2-11]
[03:07] <vorlon> libreoffice had built on riscv64 then failed to upload because of launchpad outage, now it fails to build because of kde arch:any/all skew #fail
[05:49] <vorlon> britney just finished; results available soon
[05:54] <pushkarnk> Are things currently in a flux on noble/armhf? I am unable to build openjdk in a chroot, multiple build-deps uninstallable.
[06:05] <vorlon> pushkarnk: things are certainly in flux due to the xz-utils mitigation. If you can show me the uninstallability errors I can have a look at helping to resolve
[06:16] <pushkarnk> vorlon: thanks, here's the log https://pastebin.ubuntu.com/p/Q8bR8SZpSd/
[06:17] <vorlon> well that's something
[06:18] <doko> pushkarnk: proposed is not enabled in your PPA
[06:18] <vorlon> yeah I was going to ask if this is with or without proposed
[06:18] <vorlon> log says it isn't
[06:18] <pushkarnk> ah, got it. Thanks for pointing out
[06:20] <vorlon> pushkarnk: ah but also I recall having a conversation with vpa1977 about openjdk rebootstrapping and priorities, I see that openjdk-11-jre-headless still depends on libcups2 not libcups2t64
[06:21] <wgrant> Did someone fix some dep to stop wxwidgets3.2 from segfaulting on armhf, or did it just work the 10th time?
[06:22] <vorlon> pushkarnk: so openjdk-lts needs a bootstrap cycle to be buildable again on armhf
[06:22] <pushkarnk> vorlon: ack, will look into that
[06:23] <RAOF> amurray: Hm. Tracking everything down, bacula seems good to go except for explicit Security Team ACK.
[06:23] <vorlon> pushkarnk: https://launchpad.net/~canonical-foundations/+archive/ubuntu/archive-bootstrap/+packages?field.name_filter=openjdk&field.status_filter=&field.series_filter= shows a previous unsuccessful bootstrap attempt?
[06:24] <pushkarnk> vorlon: ack
[06:46] <vorlon> so it's not perfect due to me botching a regeneration of my ordered list of packages, but broad strokes, the packages below https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#389-ds-base should be a priority for sorting out as most of the seeded packages are going to be there
[06:51] <vorlon> mwhudson: yeah ubuntu-build --batch is still missing some packages even with the tweak to list()ify the launchpad output; https://launchpad.net/ubuntu/+source/kcoreaddons/5.115.0-0ubuntu5/+build/27974490 wasn't retried since 2024-03-31 despite my comment 4 hours ago about doing hourly retries...
[06:55] <vorlon> doko: hmm you brought in a new upstream version of python-greenlet which regresses buildability on ppc64el
[07:01] <doko> vorlon: required for 3.12. that's https://github.com/python-greenlet/greenlet/issues/395  maybe Heinrich could have a look for riscv64?
[07:01] -ubottu:#ubuntu-release- Issue 395 in python-greenlet/greenlet "greenlet 3.0.3 fails to build on riscv64 and ppc64el" [Open]
[07:01] <vorlon> doko: riscv64 isn't a regression vs release, but ppc64el is
[07:48] <LocutusOfBorg> vorlon, the abseil reason is a sadness in the current version in release. Tests are disabled, riscv64 can't build
[07:49] <LocutusOfBorg> I did conduct a deep analysis on Debian release channel some days ago, explaining why to move forward it would have been useful to also transition it, instead of kicking out tests or ignore results
[07:50] <LocutusOfBorg> and looks like Debian release agreed with me, there are no symbols changes, just a few (~10 symbols) were added, and most of them are marked _internal prefix, so maybe they aren't even meant to be used outside
[07:50] <LocutusOfBorg> so I would say there were no even SONAME breaking change, but meh
[07:54] <LocutusOfBorg> I can't prove that it won't be an issue, but current release pocket is not time64_t, the proposed one has armhf disabled tests (and they looks like real regressions in RB-tree handling on armhf), riscv64 can't build at all
[07:58] <LocutusOfBorg> it might regress buildability of telegram-desktop mozc and s2geometry
[10:01] <philroche> \o The first time I have seen this... for noble livecd-rootfs, the version in -release is newer than in -updates. Is that intentional/expected? https://pastebin.ubuntu.com/p/N6KHkdRGNd/
[10:02] <cjwatson> philroche: https://discourse.ubuntu.com/t/whats-happening-in-noble-repositories/43729
[10:03] <philroche> cjwatson: Thank you
[10:52] <LocutusOfBorg>  vorlon maybe if we can make riscv build, and we ignore the fact that abseil might be broken on armhf, we are safe to not transition
[10:53] <LocutusOfBorg> I have patches for mostly all the build failures but rebuilding llvm is meh for time
[11:12] <jbicha> vorlon: yes, please remove cpdb-backend-file from Ubuntu also
[11:52] <ricotz> hello, please could someone push a no-change rebuild of liborcus?
[12:08] <jbicha> ricotz: done
[12:11] <ricotz> jbicha, thx!
[12:32] -queuebot:#ubuntu-release- Unapproved: timeshift (jammy-proposed/universe) [21.09.1-1 => 21.09.1-1ubuntu1] (no packageset)
[12:50] -queuebot:#ubuntu-release- New: rejected ubuntu-proxy-manager [source] (jammy-proposed) [0.1~22.04.1]
[13:25] <athos> oh, mk-sbuild currently cannot create noble schroots because apt is not in the release pocket I suppose
[14:02] <kanashiro> vorlon I know you are busy but I think you are the one who can help me with this (when you find the time of course), I have runc-app in the NEW queue of focal, jammy and mantic, could you please review them? The package is the same that you already accepted in Noble some time ago. With this, the split of application and library of the container stack packages will be done (and I will not bother you with that again :)
[14:11] <ricotz> kanashiro, please see https://wiki.ubuntu.com/StableReleaseUpdates#Contacting_the_SRU_team
[14:13] <kanashiro> ricotz this is a special case where I need someone with SRU + AA powers, a regular SRU team member (not being an AA) will not accept those packages
[14:16] <ricotz> kanashiro, I see, this a new source package (so you could cosider -backports as well), having at least a SRU bug for references won't hurt to get it processed
[14:17] <kanashiro> moreover, Steve already has some context since he accepted the previous similar uploads (container stack related)
[14:18] <kanashiro> ricotz we do not want -backports, and I did not provide all the info because I believe Steve already have enough context. We do have a LP bug for this: https://bugs.launchpad.net/ubuntu/mantic/+source/runc/+bug/2022390
[14:18] -ubottu:#ubuntu-release- Launchpad bug 2022390 in runc-app (Ubuntu Mantic) "Keep the -dev binary package in sync with Debian" [Undecided, In Progress]
[14:23] -queuebot:#ubuntu-release- Unapproved: xorg-server (mantic-proposed/main) [2:21.1.7-3ubuntu2.7 => 2:21.1.7-3ubuntu2.8] (desktop-core, i386-whitelist, xorg)
[14:23] <ricotz> kanashiro, ah ok, so there is a bug tracking this already, you might want to be patient while the situation in noble is the focus currently
[14:24] <kanashiro> ricotz I know what is happening and specially Steve is busy with all that, that's why I asked him to take a look once he find the time to do it. I am being patient.
[14:26] <ricotz> kanashiro, ignore me then :)
[14:29] <Eickmeyer> LocutusOfBorg: I'm fairly certain you can cross telegram-desktop off that list because, at least here, it's a transitional package to the snap. It'll only be an issue if they move to core24, which I'm fairly certain they won't any time soon. ;)
[14:32] -queuebot:#ubuntu-release- Unapproved: xorg-server (jammy-proposed/main) [2:21.1.4-2ubuntu1.7~22.04.8 => 2:21.1.4-2ubuntu1.7~22.04.9] (desktop-core, i386-whitelist, xorg)
[14:39] <doko> vorlon: we seem to have lost binary removals in the release pocket, e.g. I removed libncurses-ada binaries for armhf before. I removed these again now, because update_excuses complains about a missing build. So I assume, these removals have to be redone?
[14:39] <doko> another one would be libxmlezout
[14:42] <jbicha> LocutusOfBorg: libabsl-dev now Recommends: libgmock-dev (source: googletest) which is in universe so that needs to be handled https://ubuntu-archive-team.ubuntu.com/component-mismatches-proposed.svg
[14:51] -queuebot:#ubuntu-release- Unapproved: libfprint (jammy-proposed/main) [1:1.94.3+tod1-0ubuntu2~22.04.06 => 1:1.94.3+tod1-0ubuntu2~22.04.07] (ubuntu-desktop)
[15:03] <schopin> sil2100: OK for a bugfix upload of src:click? It already has a succesful rebuild.
[15:03] <sil2100> schopin: yeah, go ahead o/
[15:03] <schopin> thx :)
[15:46] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-550 [amd64] (jammy-proposed) [550.67-0ubuntu1.22.04.1]
[15:46] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-550 [i386] (jammy-proposed) [550.67-0ubuntu1.22.04.1]
[15:46] -queuebot:#ubuntu-release- New: accepted nvidia-graphics-drivers-550 [arm64] (jammy-proposed) [550.67-0ubuntu1.22.04.1]
[15:57] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (focal-proposed/main) [2.664.52 => 2.664.53] (desktop-core, i386-whitelist)
[16:29] <jbicha> ubuntu-release: could we get a Discourse post about the Beta status? I think people here have a general idea of status (beta release looks impractical Thursday) but community members may try installing daily builds now thinking it's our usual Beta quality
[16:36] <tsimonq2> +1
[16:56] <jbicha> thank you
[17:07] <vorlon> LocutusOfBorg: abseil - "is not time64_t" is not relevant, we needed to rebuild it anyway for amd64 so it picks up the time_t change anyway?  but ok it sounds like this is something we should get in but also I think we need to prioritize getting amd64 back into a stable state so if you could ping me to restore this after beta freeze is declared I'd appreciate the reminder so I don't lose track
[17:08] <vorlon> kanashiro: maybe RAOF can help you with this SRU in NEW; I'm occupied with xz-utils
[17:38] <vorlon> I'm about to flush the autopkgtest queues and requeue specifically those tests needed for seeded packages
[17:39] <vorlon> doko: I don't see a source or binary package named libncurses-ada; what's the actual package name? I was going to double-check what had happened here
[17:45] <ginggs> vorlon: i believe that's from src:libncursesada
[17:57] <vorlon> ginggs: thanks. doko so I don't know what you removed either time, https://launchpad.net/ubuntu/noble/armhf/libncursesada-dev shows there's only been one publication of this package on armhf in noble and that it's still published. I'm removing it now
[17:57] <vorlon> doko: if you tried to remove from the release pocket, well, the binaries weren't there
[18:03] <doko> so why is update_excuses showing
[18:03] <doko> missing build on armhf: libxmlezout10-dev, libxmlezout7 (from 1.06.2-10)
[18:03] <doko> the binaries are not in the release pocket ...
[18:04] <vorlon> doko: in that case, it's because they're in noble-updates due to the copy-back
[18:04] <vorlon> and uh noble-updates is weird and I can't delete packages from it without changing the state of the series in launchpad from Active development to Pre-release freeze
[18:04] <vorlon> doko: so when you find cases like this please flag to the release team for hinting
[18:05] <doko> ok, I'll search for these tomorrow
[18:07] <ginggs> vorlon: what hint to use in these cases?
[18:07] <vorlon> ginggs: 'force'
[18:07] <doko> vorlon: and python-greenlet is a ftbfs caused by -fno-omit-frame-pointer
[18:07] <vorlon> doko: hah, nice
[18:07] <vorlon> doko: easily fixed then?
[18:09] <doko> building without frame pointer
[18:47] <LocutusOfBorg> vorlon, ack, but somewhat the current abseil is failing to upload on riscv64
[18:48] <LocutusOfBorg>  libabsl-dev | 20230802.1-3          | noble-proposed | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
[18:48] <LocutusOfBorg> you failed to remove it maybe?
[18:49] <LocutusOfBorg>  libabsl20230802 | 20230802.1-3 | noble-proposed | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
[18:54] <juliank> Seems it uploaded fine
[18:55] <juliank> I see now what you mean the new one is 2022* INFO  libabsl-dev_20220623.1-3.1ubuntu2_riscv64.deb: Version older than that in the archive. 20220623.1-3.1ubuntu2 <= 20230802.1-3
[19:36] -queuebot:#ubuntu-release- New sync: jami (noble-proposed/primary) [20231201.0~ds2-1]
[19:49] <LocutusOfBorg> juliank, it was rolled back
[19:49] <LocutusOfBorg> but not completely I would say
[19:57] <LocutusOfBorg> vorlon,  libusb-dev | 2:0.1.12-35          | noble  | amd64, arm64, armhf, ppc64el, riscv64, s390x
[19:57] <LocutusOfBorg> lirc is needing it on i386... is some removal script buggy?
[19:59] <vorlon> LocutusOfBorg: probably not buggy but racy.  currently both lirc and libusb are in the i386 whitelist so I'll restore it
[20:09] <vorlon> libglib2.0-dev/amd64 in main cannot depend on libsysprof-capture-4-dev in universe
[20:09] <vorlon> !
[20:11] <vorlon> jbicha: ^ I guess this is the sysprof support seb128 mentioned elsewhere that will be reverted; eta on that revert?
[20:12] <vorlon> jbicha: nevermind I see seb128 uploaded 56 minutes ago
[20:33] <jbicha> doko: I reported bug 2060073 upstream. I'm guessing we need to restore your "ignore build test failures" change to clear the xz-utils rebuilds?
[20:33] -ubottu:#ubuntu-release- Bug 2060073 in folks (Ubuntu) "folks build test failures with glib 2.80" [High, Triaged] https://launchpad.net/bugs/2060073
[20:35] <doko> not my problem
[20:35] <jbicha> doko: come on
[20:37] <jbicha> I can try rephrasing. Do we need to make sure everything has built for xz-utils rebuilds? If so, then I guess it's appropriate to ignore the build test failure since we are tracking a proper resolution
[20:40] <doko> your reply to #1067675 doesn't help at all for Ubuntu. the packages are not installable once the amd64 upload fails
[20:41] <jbicha> *make sure everything has built ASAP
[20:43] <jbicha> Debian bug 1067675 is a team practice where we are balancing how to handle people doing partial upgrades which seems to happen a bunch in Debian Testing/Unstable
[20:43] -ubottu:#ubuntu-release- Debian bug 1067675 in src:mutter "library package (arch any) depending on a 'common' package with too strict version constraint" [Important, Open] https://bugs.debian.org/1067675
[20:44] <doko> yes, I'm questioning this practice
[20:45] <jbicha> we will probably get a reply from another team member now that I have replied. I don't think you are understanding strong enough why that strict dependency is in place
[20:45] <doko> I'm happy to learn
[20:48] <LocutusOfBorg> fo0bar_, for abseil?
[20:49] <LocutusOfBorg> vorlon, ^^ for abseil please?
[20:49] <LocutusOfBorg> some binaries are still around
[20:49] <LocutusOfBorg> preventing riscv64 from uploading
[20:54] <ricotz> LocutusOfBorg, this doesn't look good indeed - https://paste.debian.net/plain/1312851
[21:03] <doko> LocutusOfBorg: I removed the abseil NBS binaries from proposed and uploaded a no-change rebuild for 20220623.1-3. please wait for any further update until that package migrates to the release pocket, and then of course FFe exceptions
[21:06] <ricotz> doko, is there a way to tell which libabsl-dev is/was used in https://launchpad.net/ubuntu/+source/libreoffice/4:24.2.2-0ubuntu1/+build/28018398
[21:06] <doko> just look at the build log
[21:07] <ricotz> it is still running
[21:08] <ricotz> doko, ^
[21:08] <doko> I don't know of a way to do that. you could cancel the build and restart (after about 1h when the NBS binaries are removed)
[21:09] <ricotz> I guess I will do that :(
[21:09] <ricotz> (build is nearly finished)
[21:09] <doko> it won't be the last package finishing the build ;p
[21:15] <LocutusOfBorg> created 9 hours ago
[21:15] <LocutusOfBorg> Deleted 18 hours ago by Steve Langasek
[21:15] <LocutusOfBorg> I guess it wasn't using the newer abseil
[21:36] <ricotz> but "apt-cache policy libabsl-dev" suggests otherwise
[22:11] <dbungert> I am working on a update_excuses analyzer on seeded packages that are actionable.  Here is first draft of that output.  Right now it's showing missing builds, will add other variations of this idea https://paste.ubuntu.com/p/C2zH6P8JXv/
[22:35] <cpete> dbungert: Thanks for the list. So far it looks like just queued riscv64 builds. Is there anything to do but wait for these to build?
[22:36] <dbungert> I'll see if I can filter things only waiting on risc-v
[22:41] <mwhudson> cpete, dbungert: yeah that would seem to be a good idea
[22:45] <vorlon> cpete, dbungert: so one thing *I* can do is bump the priority of the missing riscv64 builds
[22:46] <mwhudson> in fact is there anything other than glib2.0 blocked on anything other than missing builds?
[22:46] <dbungert> cpete: https://paste.ubuntu.com/p/PQG8DhGXg7/ should be non-riscv missing builds
[22:46] <mwhudson> oh well glib2.0 is being special cased. not sure that's what i meant
[22:47] <vorlon> why is glib2.0 being special cased
[22:47] <mwhudson> bah it would be nice if britney could tell the difference between needs-building and build-failed
[22:47] <dbungert> heh, I thought that was the ask.
[22:48] <dbungert> glib2.0 doesn't need the special case
[22:48] <vorlon> when I said "make sure glib2.0 was in the output" I meant "this is a test case for your algorithm" :)
[22:48] <dbungert> hahaha
[22:49] <dbungert> vorlon: would a dedicated riscv only list be helpful?
[22:51] <vorlon> dbungert: nah I'll just bump the score on any pending builds on any archs
[23:01] <RAOF> Just to check - removing (properly removable) packages from the archive is not going to negatively affect anything at the moment? We're not currently running into LP resource constraints or anything? (I'm just processing a removal request from yesterday)
[23:02] <dbungert> cpete: fixed version https://paste.ubuntu.com/p/RhgCKS9nQ9/
[23:02] <cpete> dbungert: thanks
[23:09] <dbungert> vorlon: glib2.0 is not in my list because I am filtering out items matching `migration-policy-verdict: REJECTED_PERMANENTLY`
[23:31] <dbungert> cpete: this version filters arches harder, because ppc/s390x/risc-v are all a bit behind https://paste.ubuntu.com/p/pYXtgfvCtW/
[23:35] <cpete> dbungert: ack, thanks.
[23:36] <dbungert> I haven't found a way to show bad builds from in progress ones in that report, that may be too time-sensitive anyhow though
[23:40] <cpete> so what's the best approach here. Should I be calling out packages that need to be rebuilt? Do core-devs have a retry build button or should I create a bug for a ncr? I guess for dependencies removed from Noble that need to be re-added and built should get a bug to track at least
[23:42] <cpete> ah wait looking at the wrong page. things should have been copied to noble-updates right?