[00:02] -queuebot:#ubuntu-release- New binary: w1retap [amd64] (noble-proposed/universe) [1.4.6-1ubuntu3] (no packageset)
[00:02] -queuebot:#ubuntu-release- New binary: w1retap [s390x] (noble-proposed/universe) [1.4.6-1ubuntu3] (no packageset)
[00:03] -queuebot:#ubuntu-release- New: accepted w1retap [amd64] (noble-proposed) [1.4.6-1ubuntu3]
[00:03] -queuebot:#ubuntu-release- New: accepted w1retap [s390x] (noble-proposed) [1.4.6-1ubuntu3]
[00:03] <vorlon> boo, freeipa *just* got reuploaded and built because sssd hadn't been removed yet; that would've worked nicely
[00:04] -queuebot:#ubuntu-release- New binary: w1retap [arm64] (noble-proposed/universe) [1.4.6-1ubuntu3] (no packageset)
[00:04] -queuebot:#ubuntu-release- New binary: w1retap [armhf] (noble-proposed/universe) [1.4.6-1ubuntu3] (no packageset)
[00:05] -queuebot:#ubuntu-release- New: accepted w1retap [arm64] (noble-proposed) [1.4.6-1ubuntu3]
[00:05] -queuebot:#ubuntu-release- New: accepted w1retap [armhf] (noble-proposed) [1.4.6-1ubuntu3]
[00:05] <vorlon> ok, badtesting gdm3/armhf rather than unwinding sssd right now
[00:08] <vorlon> gst-plugins-good1.0 ftbfs on arm64 with a test timeout, retrying
[00:10] <vorlon> coqlib abi changed on no-change rebuild, poking its revdeps
[00:14] <vorlon> juliank: your rebuild of ignition-msgs appears to have changed the Provides: field of libignition-msgs8-8
[00:15] <vorlon> thus breaking e.g. libignition-fuel-tools-dev
[00:16] <vorlon> rust-nix is entangled and has a new upstream version in -proposed
[00:20] <vorlon> jbicha: ^^ rust-nix appears to be a sync by you from experimental with revdeps that are not ready to go; but uhm it's rust so I guess I'll start yanking stuff out the hard way
[00:26] <vorlon> whole lot of coq build failures, I guess they need built in series
[00:29] <vorlon> jbicha: ah and it looks like you missed rust-calloop from experimental which needs updating for rust-nix and is needed for rust-wayland-client; fixed now
[00:29] <vorlon> jbicha: by "fixed" I mean "synced"
[00:35] <vorlon> and some desktop rust stuff that needs working through. rust-zvariant-derive -> rust-zvariant -> rust-zbus-names -> rust-zbun
[00:35] <vorlon> *zbus
[00:36] <vorlon> rust-zvariant-derive has an unclear build failure wrt rust-proc-macro-crate
[00:37] <vorlon> ok, too new rust-proc-macro-crate in -proposed
[00:41] <vorlon> right, rust-{glib,gtk4,zbus}-macros require rust-proc-macro-crate 3, but rust-zvariant-derive requires rust-proc-macro-crate 1; no newer rust-zvariant-derive available in experimental; working on ripping out the rust-zbus revdep chain
[00:53] <jbicha> vorlon: if you need rust-nix cleared out, then you may need to take out the whole rust GNOME stack in noble-proposed
[00:53] <vorlon> jbicha: nah, priorities. I'm nuking the other stuff that's not ready for rust-nix 0.27
[00:53] <vorlon> just did a bunch, letting that cook to get a fresh look after dinner
[00:54] <jbicha> ok, yeah the priorities are why I didn't get around to finishing the rust GNOME 46 transition in noble yet either
[00:54] <vorlon> rust-zbus, rust-erbium-net and revdeps are now gone
[00:54] <jbicha> ok, thanks
[00:55] <vorlon> and rust-calloop now built
[03:01] <vorlon> jbicha: the build-dep chain for gnome-online-accounts -> libadwaita-1 on i386 is rather deep.  Can goa build without libadwaita?
[03:02] <vorlon> hmm it can if we disable goabackend
[03:02] <vorlon> no revdeps on the backend
[03:07] -queuebot:#ubuntu-release- Packageset: 30 entries have been added or removed
[03:22] -queuebot:#ubuntu-release- Packageset: Added appstream to i386-whitelist in noble
[03:22] -queuebot:#ubuntu-release- Packageset: Added gnome-desktop to i386-whitelist in noble
[03:22] -queuebot:#ubuntu-release- Packageset: Added rust-ouroboros-macro to i386-whitelist in noble
[03:26] <vorlon> fixing openmpi on i386 (missing patchelf transitive build-dep), needed for the glib2.0 cluster
[03:27] <vorlon> via polymake -> lrslib
[03:32] <vorlon> 527s o overwrite '/usr/lib/arm-linux-gnueabihf/slurm-wlm/accounting_storage_mysql.so', which is also in package slurm-wlm-basic-plugins 23.11.4-1.2ubuntu3
[03:32] <vorlon> >:|
[03:37] -queuebot:#ubuntu-release- Packageset: Removed appstream from i386-whitelist in noble
[03:37] -queuebot:#ubuntu-release- Packageset: Removed gnome-desktop from i386-whitelist in noble
[03:37] -queuebot:#ubuntu-release- Packageset: Removed libadwaita-1 from i386-whitelist in noble
[03:37] -queuebot:#ubuntu-release- Packageset: Removed python-cryptography from i386-whitelist in noble
[03:37] -queuebot:#ubuntu-release- Packageset: Removed rust-asn1 from i386-whitelist in noble
[03:37] -queuebot:#ubuntu-release- Packageset: Removed rust-asn1-derive from i386-whitelist in noble
[03:37] -queuebot:#ubuntu-release- Packageset: Removed rust-foreign-types-shared from i386-whitelist in noble
[03:37] -queuebot:#ubuntu-release- Packageset: Removed rust-openssl from i386-whitelist in noble
[03:37] -queuebot:#ubuntu-release- Packageset: Removed rust-openssl-sys from i386-whitelist in noble
[03:37] -queuebot:#ubuntu-release- Packageset: Removed rust-ouroboros from i386-whitelist in noble
[03:37] -queuebot:#ubuntu-release- Packageset: Removed rust-ouroboros-macro from i386-whitelist in noble
[03:37] -queuebot:#ubuntu-release- Packageset: Removed rust-paste from i386-whitelist in noble
[03:38] -queuebot:#ubuntu-release- Packageset: Removed rust-pem from i386-whitelist in noble
[03:38] -queuebot:#ubuntu-release- Packageset: Removed rust-proc-macro2 from i386-whitelist in noble
[03:38] -queuebot:#ubuntu-release- Packageset: Removed rust-pyo3 from i386-whitelist in noble
[03:38] -queuebot:#ubuntu-release- Packageset: Removed rust-pyo3-macros from i386-whitelist in noble
[03:38] -queuebot:#ubuntu-release- Packageset: Removed rust-pyo3-macros-backend from i386-whitelist in noble
[03:38] -queuebot:#ubuntu-release- Packageset: Removed rust-quote from i386-whitelist in noble
[03:38] -queuebot:#ubuntu-release- Packageset: Removed rust-syn from i386-whitelist in noble
[03:38] -queuebot:#ubuntu-release- Packageset: Removed rust-unicode-ident from i386-whitelist in noble
[03:38] -queuebot:#ubuntu-release- Packageset: Added patchelf to i386-whitelist in noble
[04:38] <Eickmeyer> ubuntu-archive: I realize with everything going on with the time_t64 transition, everyone has been strapped for... time (no pun intended). However, orchis-kde has been sitting in source:NEW for over two weeks now after corrections were made after RAOF's review. It's just a theme, unseeded this cycle. Please somebody, take a quick look.
[05:26] <vorlon> jbicha: I'll take a closer look at this later but if you're about maybe you can comment on whether https://launchpad.net/ubuntu/+source/rust-smithay-client-toolkit/0.18.0-1/+build/27956251 looks sane to sync, or if it adversely impacts the rust gnome stack
[05:29] <vorlon> good correlation with other packages currently rendered uninstallable, tho
[05:31] <vorlon> jbicha: ah rust-wayland-backend still depends on old rust-nix, so nuking this bunch as well
[05:32] <vorlon> openmpi/i386 sorted
[07:20] <vorlon> frown, can't reproduce any of the current uninstallabilities with update-output-helper
[07:33] -queuebot:#ubuntu-release- New binary: rust-ptyprocess [amd64] (noble-proposed/none) [0.4.1-2] (no packageset)
[07:33] -queuebot:#ubuntu-release- New binary: rust-ptyprocess [armhf] (noble-proposed/none) [0.4.1-2] (no packageset)
[07:33] -queuebot:#ubuntu-release- New binary: rust-ptyprocess [arm64] (noble-proposed/none) [0.4.1-2] (no packageset)
[07:34] -queuebot:#ubuntu-release- New binary: rust-ptyprocess [ppc64el] (noble-proposed/none) [0.4.1-2] (no packageset)
[07:34] -queuebot:#ubuntu-release- New binary: rust-ptyprocess [s390x] (noble-proposed/none) [0.4.1-2] (no packageset)
[07:35] -queuebot:#ubuntu-release- New: accepted rust-ptyprocess [amd64] (noble-proposed) [0.4.1-2]
[07:35] -queuebot:#ubuntu-release- New: accepted rust-ptyprocess [armhf] (noble-proposed) [0.4.1-2]
[07:35] -queuebot:#ubuntu-release- New: accepted rust-ptyprocess [s390x] (noble-proposed) [0.4.1-2]
[07:35] -queuebot:#ubuntu-release- New: accepted rust-ptyprocess [arm64] (noble-proposed) [0.4.1-2]
[07:35] -queuebot:#ubuntu-release- New: accepted rust-ptyprocess [ppc64el] (noble-proposed) [0.4.1-2]
[07:36] -queuebot:#ubuntu-release- New binary: rust-vsock [arm64] (noble-proposed/none) [0.4.0-1] (no packageset)
[07:36] -queuebot:#ubuntu-release- New binary: rust-vsock [ppc64el] (noble-proposed/none) [0.4.0-1] (no packageset)
[07:36] -queuebot:#ubuntu-release- New binary: rust-vsock [armhf] (noble-proposed/none) [0.4.0-1] (no packageset)
[07:36] -queuebot:#ubuntu-release- New binary: rust-vsock [s390x] (noble-proposed/none) [0.4.0-1] (no packageset)
[07:38] -queuebot:#ubuntu-release- New: accepted rust-vsock [arm64] (noble-proposed) [0.4.0-1]
[07:38] -queuebot:#ubuntu-release- New: accepted rust-vsock [ppc64el] (noble-proposed) [0.4.0-1]
[07:38] -queuebot:#ubuntu-release- New: accepted rust-vsock [armhf] (noble-proposed) [0.4.0-1]
[07:38] -queuebot:#ubuntu-release- New: accepted rust-vsock [s390x] (noble-proposed) [0.4.0-1]
[08:04] <vorlon> alright, made it once through https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt, now things need to settle and it's 1am, so good night
[08:06] <vorlon> retrying coq* and akonadi* builds every 2 hours until they're done
 juliank: your rebuild of ignition-msgs appears to have changed the Provides: field of libignition-msgs8-8
[08:22] <juliank> vorlon: peculiar
[08:22] <juliank> Is this some magic ABI thing
[08:25] <juliank> Uh it tries to encode protobuf ABI I suppose
[08:25] <juliank> But I guess it failed because it doesn't expect t64 so protobuf32 became just protobuf
[08:27] <juliank> vorlon: yeah so that is eyaxtl what happened  and we probably ought to fix Debian/rules to pick up the t64 in there
[08:28] <juliank> But it can be done later
[08:30] <vorlon> juliank: well ignition* are currently uninstallable, do you want rebuilds against the current virtual package, or
[08:30] <juliank> Yeah we need to the virtual package is the full ABI
[08:30] <vorlon> that's the biggest block of stuff left unresolved on https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt (and preventing a clear view of armhf)
[08:31] <juliank> Then I should fix the virtual package first
[08:31] <vorlon> ok
[08:31] <vorlon> alrighty, really going to bed now :)
[08:32] <juliank> ack, will upload and rebuild stuff
[09:43] <doko> juliank: I think openscap-daemon is a wrong positive in your list
[09:45] <juliank> doko: Depends:
[09:45] <juliank>  dbus,
[09:45] <juliank>  libopenscap25,
[09:46] <juliank> ^ there it is
[09:55] <juliank> Fixing libignition-msgs8-8-protobuf32 -> libignition-msgs8-8-protobuf32t64 provides now
[09:56] <juliank> ah
[09:57] <juliank> so the pattern (libfuse[[:alnum:].-]+) doesn't translate to libprotobuf
[09:57] <juliank> need (libprotobuf[0-9][[:alnum:].-]*)
[09:57] <juliank> libprotobuf-dev also depends libprotobuf-lite32
[09:57] <juliank> Probably always the safest choice to require [0-9] after the prefix
[10:09] <doko> yes, and  libopenscap25 is a provides, provided by the new openscap t64 library
[10:13] <juliank> doko: on !armhf, yes, but of course not on armhf
[10:14] <juliank> doko: this is the generic pattern, libfoo1t64 provides libfoo1 on 64-bit architectures
[10:14] <juliank> I guess you need a break :)
[10:15] <juliank> I have prepared rebuilds for libignition-msgs8-8-protobuf32t64, and done an "until rmadison | grep version on all releases" sleep loop after which they will be dput automagically!
[10:16] <juliank> ( until rmadison libignition-msgs8-8 | grep "8.2.0+ds-1ubuntu3.*amd64, arm64, armhf, ppc64el, riscv64, s390x"; do echo "Sleep..."; sleep 300; done; dput *.changes ) | ts
[10:16] <juliank> muhaha
[10:16] -queuebot:#ubuntu-release- New binary: libcanberra [amd64] (noble-proposed/main) [0.30-10ubuntu8] (i386-whitelist, ubuntu-desktop)
[10:21] <juliank> heh messed up caribou because it has a control.in
[10:24] <juliank> and freeipa because it has a control.common
[10:28] <juliank> gst-plugins-good0.1 has libsoup2.4-1 (>= 2.48) | libsoup-3.0-0, so it would install the libsoup-3.0-0 now
[10:29] <juliank> Could bump the first one to libsoup-2.4-1 too
[10:30] <juliank> *1.0 not 0.1
[10:31] -queuebot:#ubuntu-release- New binary: libcanberra [arm64] (noble-proposed/main) [0.30-10ubuntu8] (i386-whitelist, ubuntu-desktop)
[10:32] -queuebot:#ubuntu-release- New binary: libcanberra [i386] (noble-proposed/main) [0.30-10ubuntu8] (i386-whitelist, ubuntu-desktop)
[10:32] -queuebot:#ubuntu-release- New binary: libcanberra [s390x] (noble-proposed/main) [0.30-10ubuntu8] (i386-whitelist, ubuntu-desktop)
[10:32] -queuebot:#ubuntu-release- New binary: libcanberra [armhf] (noble-proposed/main) [0.30-10ubuntu8] (i386-whitelist, ubuntu-desktop)
[10:32] -queuebot:#ubuntu-release- New binary: libcanberra [ppc64el] (noble-proposed/main) [0.30-10ubuntu8] (i386-whitelist, ubuntu-desktop)
[10:32] <juliank> done
[10:33] <doko> the globus packages: libglobus-common0 (>= 15) | libglobus-common0t64 (>= 15)
[10:34] <juliank> heh
[10:35] <juliank> I guess they checked which symbols were used
[10:35] <juliank> and determined no time_t used so hardcoded alternatives
[10:42] <juliank> doko: changed global-ben to ignore dependencies in an or group if the t64 one is in the group as well; though arguably this one is suboptimal - the t64 should be first for solver ease :)
[10:44] <juliank> doko: Eww, launchpad now published the deleted libcanberra 0.30-12.2ubuntu1 libraries, global-ben just picked up that transition, too early :(
[10:44] <doko> file a bug in Debian ...
[10:45] <doko> I removed the 0.30-12.2ubuntu1 versions just an hour ago
[10:45] <juliank> so we should wait for the new libcanberra ones to be published before triggering the build
[10:45] <juliank> :)
[10:45] <juliank> but plenty of rebuilds needed
[10:46] <doko> yes, and I don't know how many more merges are missing for the desktop ...
[10:46] <juliank> :(
[10:53] <juliank> doko: We could have a report on missing t64 libraries, but it mayn ot be accurate some have been reverted after all
[10:55] <doko> but there are not so many that are reverted, and we can check that with package history.
[10:57] <juliank> doko: https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.missing-t64.txt
[10:57] <juliank> doko: there we go
[10:58] <juliank> doko: This checks vorlon's override map for new names and checks whether any source package in release or proposed builds the new names
[10:58] <juliank> Probably worth adding source package names
[11:00] <doko> yes, source names would be helpful
[11:01] -queuebot:#ubuntu-release- New binary: libcanberra [riscv64] (noble-proposed/main) [0.30-10ubuntu8] (i386-whitelist, ubuntu-desktop)
[11:01] <juliank> doko: Added
[11:02] <juliank> Should I order them by source package maybe
[11:03] -queuebot:#ubuntu-release- New: accepted libcanberra [amd64] (noble-proposed) [0.30-10ubuntu8]
[11:03] -queuebot:#ubuntu-release- New: accepted libcanberra [armhf] (noble-proposed) [0.30-10ubuntu8]
[11:03] -queuebot:#ubuntu-release- New: accepted libcanberra [ppc64el] (noble-proposed) [0.30-10ubuntu8]
[11:03] -queuebot:#ubuntu-release- New: accepted libcanberra [s390x] (noble-proposed) [0.30-10ubuntu8]
[11:03] -queuebot:#ubuntu-release- New: accepted libcanberra [arm64] (noble-proposed) [0.30-10ubuntu8]
[11:03] -queuebot:#ubuntu-release- New: accepted libcanberra [riscv64] (noble-proposed) [0.30-10ubuntu8]
[11:03] -queuebot:#ubuntu-release- New: accepted libcanberra [i386] (noble-proposed) [0.30-10ubuntu8]
[11:03] <doko> yeah for libevent ...
[11:04] <juliank> Let me change syntax a bit
[11:04] <juliank> doko: Now it has `source old new`, ordered by source package
[11:05] <juliank> e.g. src:e2fsprogs is fine
[11:05] <juliank> the libraries were not transitioned just libext2fs2
[11:06] <juliank> But I think we could skip them now and try to get the rest migrating first and then do them after the initial stuff went through
[11:07] <doko> yes. can you annotate that list, which ones are not wanted? e.g. binutils
[11:07] <doko> python3.10, 3.11
[11:08] <doko> pam reverted
[11:10] <doko> mrpt can be removed, new upstream
[11:10] <juliank> added those to ignore list
[11:10] <juliank> which is hardcoded in the code lol
[11:12] <doko> ruby3.1 obsolete
[11:13] <juliank> I'm sending an email to ubuntu-devel with the full list
[11:15] <juliank> sent
[11:25] <jbicha> vorlon: I handled the goa/libadwaita situation with https://launchpad.net/ubuntu/+source/gvfs/1.53.90-4 (but it's stuck in noble-proposed)
[11:25] <jbicha> nothing else uses goa on i386
[12:52] <doko> jbicha: any idea about the folks test failures (during build)?
[13:16] <doko> vorlon: can speech-disaptcher-contrib ~rc1 work with speech-dispatcher ~rc2?
[14:48] <juliank> heh my "until" loop was in the wrong directory, uploaded all ignition rebuilds now
[14:50] <juliank> doko: oh did you do all libcanberra rebuilds already? My script was about to reupload them because you put "libcanberra t64" in the changelog and not the library name
[14:54] <doko> yes
[14:56] <doko> wondering if I should do libevent as well, before the work week starts ...
[14:56] <juliank> I'm wondering if we should try to migrate with "misbuilt" libevent
[14:56] <juliank> because this will overflow the queues
[14:56] <juliank> I suppose
[14:57] <doko> not more rebuilds than canberra
[14:57] <doko> ~120
[14:58] <juliank> doko: this one is incomplete: https://launchpad.net/ubuntu/+source/deepin-movie-reborn/5.10.8-2ubuntu1 - you missed libdmr0.1
[14:58] <juliank> hmm https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.rebuild-for.txt only shows 55 for canberra
[14:58] <doko> ok, fixing
[14:58] <juliank> presumably the rest are not built on armhf in release pocket
[15:00] <juliank> heh global-ben is triggered by gnutls-bin (>= 3.6.6) | libgnutls30 (<< 3.6.0)
[15:00] <juliank> sigh
[15:07] <doko> uploading it, not accepting from NEW
[15:10] <juliank> ok so we need to sort out libignition-*
[15:10] <juliank> I think they need to be built in a particular order maybe
[15:10] <juliank> igntion-sensors fails with libignition-transport11-11 : Depends: libignition-msgs8-8-protobuf32
[15:11] <juliank> I did not rebuilt libignition-transport I suppose
[15:12] <juliank> Oh maybe *partially* which is broken now
[15:12] <juliank> gazebo needs gui and sensors
[15:12] <juliank> so we have so far gazebo > gui and sensors > transport
[15:13] -queuebot:#ubuntu-release- New binary: libevent [amd64] (noble-proposed/main) [2.1.12-stable-9ubuntu1] (core, i386-whitelist)
[15:14] -queuebot:#ubuntu-release- New binary: libevent [i386] (noble-proposed/main) [2.1.12-stable-9ubuntu1] (core, i386-whitelist)
[15:14] <juliank> launch needs gazebo and ignition-fuel-tools
[15:14] <juliank> so we have so far launch > gazebo + fuel-tools > gui and sensors > transport
[15:15] -queuebot:#ubuntu-release- New binary: libevent [arm64] (noble-proposed/main) [2.1.12-stable-9ubuntu1] (core, i386-whitelist)
[15:15] -queuebot:#ubuntu-release- New binary: libevent [ppc64el] (noble-proposed/main) [2.1.12-stable-9ubuntu1] (core, i386-whitelist)
[15:15] -queuebot:#ubuntu-release- New binary: libevent [armhf] (noble-proposed/main) [2.1.12-stable-9ubuntu1] (core, i386-whitelist)
[15:15] -queuebot:#ubuntu-release- New binary: libevent [s390x] (noble-proposed/main) [2.1.12-stable-9ubuntu1] (core, i386-whitelist)
[15:15] <juliank> hope that's it
[15:16] <juliank> transport builds, and I think fuel-tools too
[15:17] <juliank> once transport is published, can build gui and sensors, then gazebo, then launch
[15:24] <vorlon>     got exception: MigrationConstraintException('trying cruft removal item -libclang-rt-18-dev/armhf/1:18.1.0~rc2-3, while testing has libclang-rt-18-dev/1:18.1.2-1ubuntu2 on armhf')
[15:24] <vorlon> well that's new
[15:25] <doko> that's very old cruft
[15:25] <juliank> doko: found 13 more canberra rebuilds by running the script and checking the changelogs whether you touched them :)
[15:26] <juliank> doko: inclined to upload them https://dpaste.com/36S43BUJ6
[15:26] <juliank> gnome and kde stuff really
[15:27] <vorlon> jbicha: goa/libadwaita> ok then the goa delta can be dropped (next cycle?) - the gvfs change was of course invisible since as you say it's stuck in -proposed; it also wouldn't directly help me get things OUT of proposed since gvfs has to migrate first before the i386 binaries would be removable without increasing uninstallability, and....
[15:27] <vorlon> doko: speech-dispatcher-contrib> no idea but the previous one sure couldn't!
[15:27] <juliank> will go ahead and upload the 13 additional rebuilds!
[15:27] <juliank> I checked every changelog and spot checked the control files :)
[15:27] <vorlon> doko: very old cruft which confuses and breaks britney.  I'll try to remove it now
[15:29] <juliank> OK this should be all the rebuilds so far that I see
[15:29] <vorlon> and now I'll go away again for an hour I guess, since can't make any more progress with update_output_notest until that change is published and incorporated
[15:29] <juliank> vorlon: should we do libevent now?
[15:29] <juliank> You can have an opinion on that first :)
[15:29] <vorlon> juliank: you already asserted not to on the mailing list, so I'm not sure why the question
[15:30] <juliank> well doko uploaded them but did not approve them
[15:30] <juliank> So you are the tie breaker :)
[15:30] <vorlon> btw your list of missing transitions should be cross-checked against upload-nmus.log; the latest one is in JIRA but I can push it somewhere later today
[15:30] <juliank> ack
[15:30] <vorlon> there are annotations there about e.g. the kde packages
[15:31] <juliank> Yeah it's based only on the map
[15:31] <vorlon> and uw-imap
[15:31] <vorlon> I will double check that the annotation on uw-imap doesn't use any inappropriate language
[15:31] <juliank> heh
[15:37] -queuebot:#ubuntu-release- New binary: libevent [riscv64] (noble-proposed/main) [2.1.12-stable-9ubuntu1] (core, i386-whitelist)
[15:59] <vorlon> another few coq packages needing uploaded for a coq-elpi ABI change rather than libstd-coq; done
[16:01] <juliank> I also uploaded gbrainy, fixing broken libcanberra-gtk-3-0 build-depends
[16:02] <juliank> Now it uses libcanberra-gtk-3-dev :)
[16:03] <doko> maybe rename it nobrainy ...
[16:06] <juliank> lol
[16:11] <juliank> I think we did get some good work done these past days :)
[16:12] <juliank> I wonder if we will need to end up force-skiptest */amd64
[16:15] <juliank> or say bye bye to i386 autopkgtests
[16:16] <juliank> We'd at least get double the throughput
[16:17] <juliank> But that's for bdmurray and vorlon to fight out; my advise is to drop i386 tests for now and let amd64 catch up and then we can run i386 again but we put our most important architecture first
[16:24] -queuebot:#ubuntu-release- Unapproved: openssh (jammy-proposed/main) [1:8.9p1-3ubuntu0.6 => 1:8.9p1-3ubuntu0.7] (core, i386-whitelist)
[16:24] -queuebot:#ubuntu-release- Unapproved: openssh (mantic-proposed/main) [1:9.3p1-1ubuntu3.2 => 1:9.3p1-1ubuntu3.3] (core, i386-whitelist)
[16:29] <juliank> trying to dist-upgrade noble with proposed I get:
[16:29] <juliank> The following packages have been kept back:
[16:29] <juliank>   cpdb-backend-cups google-perftools gstreamer1.0-plugins-good iftop libgstreamer-plugins-good1.0-0 python3-ipywidgets update-notifier update-notifier-common
[16:29] <juliank> interesting
[16:30] <juliank> Only python3-ipywidgets is not installable, though
[16:30] <juliank> python3-ipywidgets : Depends: jupyter-nbextension-jupyter-js-widgets (= 8.1.1-3) but 8.1.1-2 is to be installed
[16:30] <juliank> So I guess apt solver limitations
[16:31] <juliank> I should take a solver dump
[16:32] <juliank>   Holding Back google-perftools:amd64 rather than change libgoogle-perftools4t64:amd64
[16:32] <juliank> sigh
[16:33] <juliank> Probably need to inject random conflicts to get the scores correct
[16:37] <juliank> ah good that ipywidgets is fixed
[16:37] <juliank> ta doko
[16:37] <doko> no, removed package, but the references to the removed packages where not removed :-/
[16:38] <doko> what is that about google-perftools?
[16:39] <juliank> it's fine
[16:39] <juliank> the solver is not happy to remove libgoogle-perftools4
[16:39] <juliank> Unless you tell it manually
[16:40] <juliank> It's not the smartest solver
[16:40] <juliank> We'll end up having to hint it a bit in u-r-u presumably
[16:40] <juliank> feed it the t64 old -> new mapping and have u-r-u mark old ones for removal and noew ones for install before calling apt's upgrade algorithm
[16:41] <juliank> the more Conflicts: oldname you have, the more likely apt is to execute the transition rather than hold packages back
[16:42] <juliank> So adding a google-perftools Conflicts: libgoogle-perftools4 may also help
[16:42] <doko> the upgrade still wants to remove some of the desktop, plus ubuntu-release-upgrader =)
[16:45] <juliank> google-perftools Conflicts: libgoogle-perftools4 (<< 2.15-3~), libtcmalloc-minimal4 (<< 2.15-3~) makes it happy to upgrade it
[16:46] <juliank> doko: oh I see yes
[16:47] <juliank> hinting the solver with `ubuntu-desktop gnome-shell gir1.2-webkit-6.0` makes it happier
[16:48] <juliank> that only removes cheese, orca, rhythmbox, and totem
[16:48] <juliank> let's add them to the list
[16:49] <juliank> yup, apt dist-upgrade -tnoble -s ubuntu-desktop gnome-shell gir1.2-webkit-6.0 orca cheese rhythmbox totem basically only removes libraries
[16:49] <juliank> So it's all installable, just apt too stupid
[16:49] <juliank> Possibly with an apt upgrade && apt dist-upgrade it becomes better, but not sure
[16:52] <juliank> # Rebuilding mandos due to mandos-client 1.8.16-1ubuntu1 depending on {'libgnutls30'} - should be {'libgnutls30t64'}
[16:52] <juliank> hmm
[16:53] <juliank> ah yes that was the or group
[16:53] <juliank> sorry
[16:53] <juliank> I think all rebuilds have been done or failed to build
[16:54] <juliank> or are in depwait
[16:54] <juliank> the 3 remaining in https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.rebuild-for.txt are just noise
[16:54] <juliank> So going through update_excuses missing builds or https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.txt packages in [] to sort them out is the next step
[16:54] <juliank> I'm still waiting for ignition-transport to be built
[16:56] <juliank> I probably should run global-ben on amd64 too
[16:58] <juliank> the we don't really have to rebuild them thanks to provides, but kind of nice I suppose list: https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble/global-ben.rebuild-for.txt
[16:58] <juliank> you can think these ~roughly correspond to missing armhf builds
[17:00] <juliank> or armhf builds that ran much later :)
[17:01] <juliank> fwiw, possibly we should collect all libraries in the seeds and then add pre-64 ones to Conflicts to ease upgrades
[17:01] <juliank> I can go play around with that, and we can make germinate do that really by feeding it a negative list
[17:01] <juliank> or rather reverse mapping
[17:02] <juliank> for each library that is seeded we should Conflict pre-t64 one
[17:02] <juliank> but also we have u-r-u so meh?
[17:02] <juliank> Just upgrading existing noble will be hard :D
[17:04] <vorlon> juliank: I wanted to do some selective filtering of the i386 autopkgtests but it was too low-yield
[17:04] <vorlon> how do we have 14k amd64 autopkgtests again
[17:04] <vorlon> we were down to 6k
[17:05] <juliank> We were up to 17k yesterday
[17:05] <vorlon> yes, and then bdmurray deleted stuff
[17:05] <vorlon> and then it's back up again
[17:05] <juliank> vorlon: most of them are your requests
[17:06] <vorlon> I'm sure they aren't
[17:06] <vorlon> when I was done requesting, we were at max 12k, *before* bdmurray pruned
[17:07] <vorlon> I do see britney queuing multiple redundant tests
[17:07] <vorlon> pmount {"triggers": ["pmount/0.9.23-7.1"], "submit-time": "2024-03-24 00:53:58"}
[17:07] <vorlon> pmount {"triggers": ["pmount/0.9.23-7.1"], "submit-time": "2024-03-24 02:12:10"}
[17:07] <juliank> In [7]: sum(1 if "vorlon" in item else 0 for item in q["ubuntu"]["noble"]["amd64"])
[17:07] <juliank> In [7]: sum(1 if "vorlon" in item else 0 for item in q["ubuntu"]["noble"]["amd64"])
[17:07] <juliank> Out[7]: 12464
[17:07] <vorlon> hmm
[17:07] <vorlon> I don't know why that count didn't come down, then
[17:08] <vorlon> pmount {"triggers": ["pmount/0.9.23-7.1"], "submit-time": "2024-03-24 09:59:24"}
[17:08] <vorlon> ffs britney
[17:08] <juliank> I also sadly don't have access to the infrastructure anymore to do queue manipulation
[17:08] <vorlon> pmount {"triggers": ["pmount/0.9.23-7.1"], "submit-time": "2024-03-24 11:20:43"}
[17:08] <juliank> or maybe I don't have the key here
[17:08] <juliank> but I should
[17:08] <vorlon> don't you? I do, so if you see a pattern that I should kill...
[17:09] <vorlon> right so the other 5k may be the same 30 tests being requeued over and over again :P
[17:09] <vorlon> I'll run a amqp-filter-dupes at least
[17:09] <juliank> we can drop *2* tests by merging triggers
[17:10] <juliank> so I don't think there are dupes in there
[17:10] <juliank> Or my script to count merging is wrong
[17:10] <juliank> :D
[17:10] <juliank> it loads all queues, groups by package being tested, then iterates over all requests, does trigger union, and appends it to an output list
[17:10] <vorlon> well per the above, a number of tests are being triggered by britney in a loop
[17:11] <juliank> ok my script is broken i think
[17:12] <vorlon> bah we only have filter-amqp-dupes-upstream
[17:12] <vorlon> I thought there was one for !upstream
[17:12] <vorlon> nevermind, not futzing with this now, they're so far down in the queue
[17:13] <juliank> Yes sorry
[17:13] <juliank> There are only 7k if we merge triggers
[17:13] <vorlon> really?
[17:13] <juliank> itertools.groupby() needs an ordered input
[17:13] <juliank> But it merges all-proposed and not all-proposed
[17:13] <vorlon> oh
[17:14] <vorlon> yeah I need a negative filter to delete the !all-proposed ones
[17:14] <juliank> If that's fine I can give you a list of all requests with all triggers merged and all-proposed set
[17:14] <juliank> and the script to verify the logic
[17:15] <juliank> or you can I guess delete the queues
[17:15] <juliank> and then do retry-autopkgtest-regressions --state=RUNNING
[17:15] <juliank> and you have the same effect
[17:15] <vorlon> do you account for migration-reference/0
[17:15] <juliank> not yet, sorry
[17:15] <vorlon> then not that :)
[17:15] <juliank> let's see
[17:15] <vorlon> there are some in the queue that are not --state=RUNNING
[17:16] <vorlon> I'm not going to spend much attention on this right now, the bigger problem has certainly been the lack of *progress* on the queues which it doesn't seem like bdmurray has quite sorted yet
[17:18] <doko> vorlon: so, when you're delaying that work, I'd like to go on with libevent
[17:18] <vorlon> doko: delaying what work?
[17:19] <vorlon> I'm saying that manipulating the amd64 test queue right now is titanic-deckchair-rearranging
[17:19] <vorlon> doko: how many packages have to be rebuilt for libevent?
[17:19] <juliank> i386: 9739 -> 2852
[17:20] <vorlon> juliank: by merging triggers?
[17:20] <vorlon> that one I'll happily do
[17:20] <juliank> yeah
[17:20] <juliank> and amd64: 14180 -> 7638
[17:20] <vorlon> juliank: flush queue && retrigger --state=RUNNING?
[17:21] <juliank> vorlon: this is the script that did the merging: https://gist.github.com/julian-klode/2785b07e76abaed78d34242a39d9bf0b
[17:22] <juliank> vorlon: so if i386 has no requestor, than flush and retrigger --state=RUNNIGN should work too
[17:22] <juliank> otherwise the coolest move is to add amqplib support to the script and have it just write the merged queue items after flushing the queue
[17:22] <juliank> or patching it to produce run-autopkgtest commands
[17:23] <vorlon> I'd rather reimport from update_excuses, that also filters out any obsolete triggers/requests as a side benefit
[17:23] <vorlon> anyway, flushed && now requeuing
[17:24] <juliank> Do you remember what you retried yesterday to retry those again?
[17:24] <juliank> :D
[17:24] <vorlon> I didn't retry things on i386
[17:24] <juliank> ah
[17:24] <doko> vorlon: ~120
[17:25] <juliank> vorlon: Oh I guess all your tests may simply be scheduled twice, so really do the dupes filtering
[17:26] <juliank> Did filter-amqp-dupes not survive to ps5 sigh
[17:26] <vorlon> probably not if it wasn't committed
[17:27] <vorlon> doko: ick.  I don't suppose you have insight into how long it will take to get them all built in launchpad?
[17:27] <vorlon> doko: to me it sounds like a risk that it will delay getting the current transition done
[17:28] <doko> it's three levels, like canberra.
[17:28] <doko> ok
[17:32] <vorlon> to frame this, by my EOD Monday I am going to put armhf to break_arches in britney if we don't otherwise have a solution already.  So other churn on packages in the entangled set, affecting migratability on arches other than armhf, will slow things down at that point
[17:33] <juliank> dupes are 14182 - 8057 = 6125 tests in the amd64 queues
[17:34] <vorlon> teeny tiny queue on i386 now https://autopkgtest.ubuntu.com/running
[17:34] <vorlon> uh I don't think that's what 'huge' means https://autopkgtest.ubuntu.com/running#queue-huge-noble-amd64
[17:35] <arraybolt3> Huge: adj. large in size.
[17:36]  * arraybolt3 goes back to coding rather than being annoying
[17:37] <doko> vorlon: so maybe set the queue accept to manual for a day?
[17:37] <juliank> vorlon: So merge-queues-for-arch.py in https://gist.github.com/julian-klode/2785b07e76abaed78d34242a39d9bf0b now prints run-autopkgtest commands (and it reads from autopkgtest.ubuntu.com/queues.json); so you could run it, record the output (which will be a shell script then), flush amd64 and run the script
[17:38] <juliank> it does preserve any migration-reference/0
[17:38] <juliank> oh you are retriggering i386 over http? that is ... slow
[17:40] <juliank> I can encode urls too
[17:41] <juliank> Just need to know :)
[17:41] <juliank> avoiding 6k tests sounds like a good idea
[17:44] <juliank> Ah my output misses the name of the package to test
[17:46] <juliank> Well I updated it stealing from retry-autopkgtest-regressions for run-autopkgtest :)
[17:50] <juliank> vorlon: Script now also does URLs based on the retry-autopkgtest-regressions code
[17:51] <juliank> vorlon: are we missing i386? you last scheduled 6 minutes ago, but we only have 463 requests
[17:52] <juliank> Well I guess it got to vim so that's all?
[17:53] <juliank> certainly there were only a handful of retries on i386
[18:01] <juliank> I guess britney could also consult queued.json from autopkgtest.ubuntu.com as an additional safety factor to see if a test is pending before scheduling it
[18:04] <juliank> Oh I guess the retry with --state=RUNNING dropped all the RUNNING-ALWAYSFAIL
[18:06] <juliank> jak@jak-t14-g3:~/Projects/Ubuntu/ubuntu-archive-tools:main$ ./retry-autopkgtest-regressions --state=RUNNING-ALWAYSFAIL | grep i386 | wc -l
[18:06] <juliank> 4025
[18:06] <juliank> jak@jak-t14-g3:~/Projects/Ubuntu/ubuntu-archive-tools:main$ ./retry-autopkgtest-regressions --state=RUNNING | grep i386 | wc -l
[18:06] <juliank> 462
[18:06] <juliank> yup
[18:06] <juliank> Imagine 90% of i386 tests we normally run are not regression blockers
[18:08] <juliank> amd64: 10891 running and only 369 running-alwaysfail
[18:08] <juliank> much better
[18:08] <juliank> Should we think about killing i386 autopkgtests for 24.10
[18:09] <juliank> $ ./retry-autopkgtest-regressions --state=RUNNING | grep armhf | wc -l
[18:09] <juliank> 951
[18:09] <juliank> should we trigger those again?
[18:09] <juliank> armhf is empty
[18:11] <juliank> I guess we just killed a ton of ppc64el and s390x
[18:11] <juliank> they are both at about 6300 tests in RUNNING state
[18:11] <juliank> despite empty queues
[18:16] <juliank> building ignition-gui and ignition-sensors now, ignition-transport finally published
[18:17] <juliank> sigh
[18:18] <juliank>  i libignition-rendering6-6 : Depends: libignition-common4-4 (>= 4.5.0+ds) but it is not installable
[18:18] <juliank>                             Depends: libignition-common4-graphics4 (>= 4.5.0+ds) but it is not installable
[18:18] <juliank>  libignition-rendering6-ogre1-6 : Depends: libignition-common4-4 (>= 4.5.0+ds) but it is not installable
[18:18] <juliank>                                   Depends: libignition-common4-events4 (>= 4.5.0+ds) but it is not installable
[18:18] <juliank>                                   Depends: libignition-common4-graphics4 (>= 4.5.0+ds) but it is not installable
[18:18] <juliank>                                   Depends: libogre-1.9.0v5 (>= 1.9.0+dfsg1-9~) but it is not installable[1~
[18:18] <juliank> not sure but I guess ignition-rendering needs a rebuild, and maybe ignition-common
[18:18] <doko> mutter ... not running tests on anything than amd64, and then becoming uninstallable when the amd64 tests fail ...
[18:20] <juliank> ok yeah ignition-common seems fine according to global-ben but ignition-rendering needsa  build
[18:21] <juliank> which fails with /<<PKGBUILDDIR>>/src/BoundingBox.cc:48:18: error: ‘exchange’ is not a member of ‘std’
[18:26] <juliank> /<<PKGBUILDDIR>>/include/ignition/rendering/GraphicsAPI.hh:31:55: error: found ‘:’ in nested-name-specifier, expected ‘::’
[18:26] <juliank>    31 |     enum class IGNITION_RENDERING_VISIBLE GraphicsAPI : uint16_t
[18:26] <juliank> This doesn't make it better
[18:26] <vorlon> juliank: Brian and I have talked about fixing britney to not schedule (and wait for) i386 tests that it shouldn't.  I don't want to lose the i386 autopkgtest coverage that actually matters
[18:29] <juliank> hmm maybe export DEB_CPPFLAGS_MAINT_APPEND = -DIGNITION_RENDERING_VISIBLE=
[18:29] <juliank> ignition-* should be killed
[18:29] <juliank> the last update was in 22.04 and it's not building?
[18:30] <juliank> it uses undefined macros...
[18:30] <vorlon> I need someone to figure out why rsync is failing to pick up new update_output_notest files :/
[18:31] <vorlon> eh no in this case the file hasn't been updated on the server
[18:31] <juliank> Do I need to build with c++14?
[18:32] <vorlon> https://ubuntu-archive-team.ubuntu.com/proposed-migration/log/noble/2024-03-24/17:07:01.notest.log producing no output :/
[18:34] <vorlon> juliank: "should be killed" is valid
[18:34] <juliank> vorlon: I think we should RM sdformat ignition-cmake ignition-common ignition-fuel-tools ignition-gazebo ignition-gui ignition-launch ignition-math ignition-msgs ignition-physics ignition-plugin ignition-rendering ignition-sensors ignition-tools ignition-transport ignition-utils
[18:34] <juliank> Or demote them to proposed
[18:35] <juliank> vorlon: sdformat is the reverse-depends of one of the ignition ones
[18:35] <vorlon> demote to proposed> nack
[18:35] <juliank> I'll file removal bug?
[18:35] <vorlon> removal> with pleasure
[18:35] <vorlon> is there a ftbfs bug anywhere in Debian already?
[18:35] <juliank> vorlon: It#s not packaged there
[18:36] <juliank> vorlon: or not fully
[18:36] <vorlon> what seriously
[18:36] <juliank> the one that is failing is https://launchpad.net/ubuntu/+source/ignition-rendering/ and the stack down from that
[18:36] <juliank> that is 6.1.0+ds-0ubuntu2
[18:36] <vorlon> juliank: ok please file a removal bug on that one yeah
[18:37] <juliank> yeah but that fails everything else except I think sensors and common
[18:37] <vorlon> fwiw ROS upstream has also been talking to our robotics team and wants these packages removed
[18:37] <juliank> What do I say ignition-sensors is also depending on ignition-rendering
[18:37] <vorlon> if they're Ubuntu-specific and unmaintained then yes please, nuke from orbit
[18:38] <juliank> I can only say the entire set is self-contained but figuring out which parts we can pull is much harder
[18:39] <vorlon> a removal bug on the ftbfs package saying "and all its recursive revdeps" is sufficient in this case
[18:39] <juliank>  OK found them all by filtering for 0ubuntu :)
[18:40] <juliank> and that set is self-contained too
[18:41] <juliank> vorlon: https://bugs.launchpad.net/ubuntu/+source/ignition-sensors/+bug/2058851
[18:41] -ubottu:#ubuntu-release- Launchpad bug 2058851 in ignition-sensors (Ubuntu) "RM: ignition-gazebo ignition-gui ignition-launch ignition-rendering ignition-sensors" [Undecided, New]
[18:52] <doko> removing ...
[18:53] <doko> ahh, you're already doing
[18:59] <juliank> I'm just do it faster I should eat dinner
[18:59] <juliank> I probably should take a swap day next weekend
[19:05] <doko> you can take as many swap days on weekends as you want =)
[19:06] <juliank> jbicha: mutter FTBFS https://launchpadlibrarian.net/720986950/buildlog_ubuntu-noble-amd64.mutter_46.0-1ubuntu2_BUILDING.txt.gz
[19:06] <juliank> doko: well around the weekend :)
[19:06] <doko> yes, see -1ubuntu3
[19:07] <juliank> ooh
[19:07] <juliank> that was hidden
[19:07] <juliank> :D
[19:07] <juliank> thanks
[19:07] <juliank> can we remove the courier stack?
[19:07] <juliank> :D
[19:07] <mwhudson> good morning
[19:07] <juliank> on armhf
[19:08] <juliank> mwhudson: investigate what we need to remove for courier on armhf ? :D
[19:08] <mwhudson> juliank: can do in a bit
[19:08] <mwhudson> need to shuffle children around a bit first
[19:08] <mwhudson> have we removed the osmo stack yet?
[19:09] <juliank> I do not know
[19:10] <juliank> just remove all universe/hamradio :D
[19:10] <juliank> I still see osmo-bts
[19:11] <juliank> currently we are removing the old jammy ignition stack
[19:11] <juliank> vorlon: has notest ever produced output?
[19:12] <juliank> couple crash reports yesterday that got gzipped, but otherwise, always 89 bytes
[19:20] <vorlon> juliank: no; that's identical output in the log, no errors shown and no output file
[19:22] <vorlon> *this* time the file was copied correctly
[19:24] <juliank> I feel like I should write a removal set calculator and then add it to ubuntu-archive-tools
[19:25] <juliank> you feed it "remove foo" and it calculates what reverse dependencies need removing too
[19:25] <vorlon> I would just like a reverse-depends tool that was reliable
[19:25] <vorlon> handled provides
[19:25] <juliank> That comes soon :)
[19:25] <vorlon> didn't occasionally have false-positives
[19:25] <juliank> removal-candidates basically is too safe right now
[19:26] <juliank> But it can do reverse-depends too in theory
[19:26] <juliank> But since it tracks Tasks and Provides fully it is too safe
[19:26] <juliank> it refuses to remove anything providing notification-daemon
[19:26] <juliank> or in reverse-depends mode (which is not public) would tell you everything depending on that
[19:27] <juliank> I think the answer is when we look at dependencies
[19:27] <juliank> we should only consider dependencies that have our package we want to "remove" as the single solution
[19:28] <vorlon> https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt looks like we're starting to get somewhere (but of course, not monotonically improving :/)
[19:28] <vorlon> ignition gunk removed
[19:28] <juliank> ta
[19:29] <juliank> If you have a x Depends: a | b and you do reverse-depends b, do you want to see x?
[19:29] <juliank> or not because a also satisfies it?
[19:29] <juliank> This gets fancy when you consider recursion
[19:29] <vorlon> I want to see x and also see that a is an alternative
[19:30] <juliank> And probably it would make sense to combine this with edos-distcheck
[19:30] <vorlon> this is what we do now on https://ubuntu-archive-team.ubuntu.com/nbs.html IIRC but that has other limitations
[19:30] <juliank> i.e. you remove the packages from the data set and see if new uninstallabilities appeart
[19:30] <vorlon> (i.e. https://ubuntu-archive-team.ubuntu.com/nbs.html still does not distinguish between Depends and Recommends)
[19:30] <juliank> I sort of wrote my own nbs report
[19:31] <juliank> Well part of global-ben's log :D
[19:32] <juliank> I think for a provides we should show Reverse-Depends: < 5000 packages depending on notification-daemon>
[19:32] <vorlon> well, libcanberra rebuilds set cinnamon back again
[19:32] <juliank> and then you need to either say I don't care or run reverse-depends notification-daemon
[19:32] <juliank> (assuming there are other providers hence that example)
[19:32] <vorlon> it is what it is, but I can't actually get a reliable view on armhf until the other archs are zeroed wrt installability regressions
[19:32] <juliank> (if we are the only provider, reverse dependencies of the provide are ours)
[19:33] <vorlon> juliank: ignition-transport-cli wasn't on your removal list, it has "unsatisfiable dependency"
[19:34] <juliank> new one should be fine
[19:34] <juliank> 11.0.0+ds-4build3
[19:34] <juliank> uploaded 4 hours ago
[19:34] <juliank> that was the libignition-msgs8-8-protobuf32t64 rebuilds
[19:35] <vorlon> ok
[19:35] <vorlon> yeah I see it now on a refresh
[19:36] <vorlon> not sure why that didn't get solved in the current notest tho, riscv64 built 3 hours ago
[19:36] <juliank> vorlon: Launchpad Runs slowly
[19:37] <juliank> It took about 5 hours or so for the first package to be published
[19:37] <vorlon> libsoup-3.0-tests is uninstallable because flask because flask-babel, which was fixed weeks ago in the release pocket and I've scheduled a retest 12 hours ago but of course it hasn't run yet :/
[19:37] <juliank> The ignition-msgs build
[19:37] <vorlon> juliank: um that's not acceptable? if it's taking that long we need to escalate to the launchpad team
[19:37] <vorlon> I was complaining about any launchpad publisher run taking longer than *15 minutes*
[19:38] <juliank> We can double check, but it's certainly hours
[19:38] <vorlon> it was 30 minutes last I looked
[19:38] <vorlon> hours would also not be consistent with the progress I've made on the coq stack ftr
[19:38] <juliank> I look at rmadison  and it takes hours for builds to appear
[19:38] <juliank> And you said it syncs from internal every 15 mins or so?
[19:39] <vorlon> ok, rmadison is not the yardstick either though, it does pull from ftpmaster.internal but there are other potential mirroring/propagation delays there
[19:39] <vorlon> and I don't want to shave an rmadison yak today
[19:40] <vorlon> britney itself is closer to the source, as are the launchpad builds, and I haven't seen evidence of hour+ publication delays
[19:40] <vorlon> something boost-pythony regressed
[19:41] <vorlon> python3-columbus, python3-cv-bridge, python3-minieigen, python3-opencamlib, python3-py3exiv2, python3-pythonmagick, python3-tagpy,
[19:42] <vorlon> seems to be because boost1.83 is being considered and it wasn't before?
[19:43] <vorlon> blocking boost1.83, I haven't seen anywhere else that it's a requirement and no-change rebuilds of revdeps haven't happened yet
[19:43] <juliank> vorlon: we just talked about it weeks ago, I was trying building something depending on another upload and it certainly didn't clear within an hour, I waited many
[19:43] <vorlon> erm
[19:44] <juliank> That was the thread on launchpad mattermost
[19:44] <vorlon> what I was seeing was 40 minutes from the time of the start of the publisher run to when indices were published
[19:44] <juliank> Where I asked if rmadison was accurate
[19:44] <juliank> Because I tried rebuilding after an hour or so and it failed
[19:44] <juliank> And then I was what do I wait for?
[19:45] <juliank> And I just retried more and more
[19:45] <vorlon> if it shows up on rmadison, it should be reliable that it works in launchpad builders
[19:45] <vorlon> but rmadison *is* slower
[19:46] <vorlon> it should be faster than waiting for archive.ubuntu.com
[19:47] <vorlon> ok boost-python rebuilds safe to upload, no built packages in -proposed that will be reset
[19:49] <vorlon>  speech-dispatcher-kali : Depends: speech-dispatcher (< 0.12.0~rc1.0~) but 0.12.0~rc2-2build1 is to be installed
[19:49] <vorlon> doko: ^ so no, speech-dispatcher-contrib is not compatible :P
[19:50] <vorlon> removing
[19:51] <vorlon> ubuntukylin also appears to be in a bad way
[19:51] <vorlon>  ukui-themes : Conflicts: ubuntukylin-theme but 3.0.4 is to be installed
[19:59] <vorlon> uploaded ukui-session-manager to revert unexplained dropping of the alternative dep
[20:00] <vorlon> ok need to figure out what is responsible for copying proposed-migration/output/noble/output_notest.txt to public_html/proposed-migration/noble/update_output_notest.txt because it's inappropriately delayed
[20:04] <vorlon> meh it's only the main britney runs that copy output_notest to the public_html directory, as I feared. fixing
[20:08] <vorlon> the last piece here then is freeipa+sssd
[20:08] <vorlon> which I may just have to remove (on armhf) despite it being non-trivial to do so
[20:10] <vorlon> things converging now, though; the current list of arm64 uninstallables is congruous with the previous run's list of s390x uninstallables, only yade added and that's handled via boost-python already (depends on python3-minieigen)
[20:14] <vorlon> just removing yade from the release pocket for now
[20:15] <vorlon> coq will take a while yet on account of riscv64 taking 11 hours on riscv64, looking at some surgical binary removals there as well
[20:25] <juliank> Ooh I wonder now if I can use the snapshot service to get a latest archive view ahead of mirrors
[20:25] <juliank> It should talk directly to launchpad db
[20:25] <juliank> Should be "live"
[20:27] <vorlon> ok coq binary removals done (armhf and arm64 for some in addition to riscv64), and kicked a build loop again, afk now for a bit
[20:27] <vorlon> and still no clue why sssd tests pass when I run them by hand :/
[20:28] <mwhudson> i think to remove the courier stack you need to delete the binaries from these source packages: https://paste.ubuntu.com/p/Z24hdxCZym/ (and no others -- there are some rdebps but they are in alternations afaics)
[20:28] <juliank> Confirmed
[20:29] <juliank> this gives me the latest view https://snapshot.ubuntu.com/ubuntu/99990101T000000Z/dists/noble-proposed/InRelease
[20:29] <juliank> am I evil? maybe!
[20:29] <juliank> I don't know if Launchpad team tested with future timestamps and this might mess up caching logic
[20:31] <juliank> otherwise I can make my reports use that and get much faster feedback
[20:34] <mwhudson> juliank: shame we can't copy from the mid april 2024 snapshot
[20:35] <juliank> heh
[20:36] <juliank> curl -s  https://snapshot.ubuntu.com/ubuntu/99990101T000000Z/dists/noble-proposed/InRelease | grep Date
[20:36] <juliank> Date: Sun, 24 Mar 2024 20:22:26 UTC
[20:36] <juliank> but this is nice
[20:36] <juliank> and yes this is about 30 mins ahead of archive.ubuntu.com, vorlon
[20:45] <juliank> ugh
[20:45] <juliank>   * swi-prolog-odbc depends on conflicting packages: swi-prolog-core=9.0.4+dfsg-3ubuntu1 vs swi-prolog-core=9.0.4+dfsg-3.1ubuntu2
[20:45] <juliank>     - chain 1: swi-prolog-nox:armhf (= 9.0.4+dfsg-3.1ubuntu2) -> swi-prolog-core:armhf (= 9.0.4+dfsg-3.1ubuntu2) -> libswipl9:armhf | libswipl9:armhf
[20:45] <juliank>     - chain 2: swi-prolog-nox:armhf (= 9.0.4+dfsg-3.1ubuntu2) -> swi-prolog-core:armhf (= 9.0.4+dfsg-3.1ubuntu2)
[20:45] <juliank> I think one of them is Provides :)
[20:45] <juliank> Ah no it isn't
[20:45] <juliank> So this is funny
[20:46] <juliank> libswipl9 is provided by old swi-prolog-nox
[20:46] <juliank> libswipl9t64 by new one
[20:46] <juliank> New one still has Depends on old name
[20:46] <juliank> That's showing up quite a bit in distcheck report
[20:47]  * juliank digging
[20:47] <vorlon> ah yes there we go, that's one of the virtual packages I forgot
[20:47] <juliank> Oh god this is annyoing
[20:47] <juliank> They keep the t64_provides as libswipl9 on 64-bit archs
[20:48] <juliank> so it needs different shlibs per bitness
[20:48] <juliank> Nevermind
[20:48] <juliank> I'm stupid
[20:48] <juliank> fixing
[20:51] <mwhudson> if access to packages via snapshot is earlier, can we configure builders to use it??
[20:51] <juliank> heh
[20:52] <juliank> So looking at https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/proposed-binaries.only-regressions.txt is a good way to spot some missed shlib bumps and other conflicting dependency chains
[20:52] <mwhudson> i mean if i want access to the debs earlier i can get them from the build page
[20:52] <mwhudson> i guess it lets you analyze transition progress a bit sooner
[20:53] <juliank> We can save 30 mins by talking to snapshot service vs archive.ubuntu.com
[20:54] <juliank> Note that in the proposed-binaries report; this is filtered for installability issues for binary packages that are in the release pocket, there also is an unfiltered one, but that one is pretty ugly (i.e. all depends on amd64 only packages and so on)
[20:54] <juliank> Also note that many issues may just be missing builds, e.g. xca
[20:55] <juliank> the prolog one also is the last "trivial conflict"; so we seemingly fixed all hardcoded dependencies for everything that has transitioned to t64
[20:57] <juliank> libevent-2.1-7 Reverse-Depends: apt-cacher-ng bitlbee dnsproxy farpd fstrm fvwm3 gearmand getstream groonga kamailio ladvd libcamera libevhtp libmemcached libopensmtpd libverto links2 lldpd lua-event mediaconch memcached moonshot-trust-router netatalk nsd ocproxy openbgpd openbsd-inetd opencu openiked opensmtpd pgbouncer pgqd php-pecl-http poolcounter qt6-webengine
[20:57] <juliank> qtwebengine-opensource-src remctl rtpengine scanssh seafile sslsplit sstp-client suricata tcpbench telegram-cli tgl tmate tmate-ssh-server tor transmission tvoe unbound unworkable ustreamer watchcatd webdis [grok] [libevent] [trickle] [zabbix]
[20:57] <juliank> ^ global-ben calculation of the libevent transition
[20:58] <juliank> We still have plenty of libglib2.0 reverse dependencies missing builds
[20:58] <juliank> as well as qt5
[20:59] <juliank> I think I need a reverse view of global-ben, currently it's: this library needs these packages to transition
[20:59] <juliank> but I also want: this package is blocking these transitions
[21:00] <mwhudson> $ show_untransitioned libglib2.0-0 | wc -l
[21:00] <mwhudson> 99
[21:00] <mwhudson> so yeah
[21:00] <mwhudson> (probably some false positives in there)
[21:03] <mwhudson> all the haskell-gi-* packages are hosed. a bunch are blocked on the folks ftbfs. there are some that build-depend on libglib2.0-0 still
[21:05] <juliank> here is the reverse view https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.reverse.txt
[21:06] <juliank> oh it's not alphabetical
[21:06] <juliank> Probably sort by number of blocking, name
[21:08] <juliank> Now we have a good view
[21:08] <juliank> i.e. the top package blocks the most transitions
[21:08] <juliank> (it doesn't check if there is a version in release though, I don't think, but it may not migrate the proposed one anyway because then that means that one is broken)
[21:09] <doko> gnome packaging is insane
[21:09] <doko> ackage: libfolks26
[21:09] <doko> Architecture: any
[21:09] <doko> Depends: folks-common (= ${source:Version}),
[21:09] <mwhudson> libgnatcoll-db is ada, all that needs to go
[21:09] <doko> folks-common being binary-all
[21:10] <doko> mwhudson: I'll care about gnat tomorrow, basically removing the non-building packages
[21:11] <mwhudson> yeah, just don't want anyone else to waste time looking at it
[21:11] <juliank> Should reverse report also put packages with uploads in proposed in []?
[21:12] <vorlon> mwhudson: snapshots is earlier than archive.ubuntu.com, it's not earlier than ftpmaster.internal that the builders already use
[21:12] <mwhudson> let's have a look at ukui-control-center shall we
[21:14] <juliank> OK I put [] around everything missing a build in proposed, or being from a NBS release build
[21:14] <juliank> Maybe NBS release builds should be hidden harder
[21:14] <vorlon> temporarily doubling the frequency of the notest runs (30m vs 1h)
[21:16] <mwhudson>     long tmit;   // the time -- This is a time_t sort of
[21:16] <mwhudson> uhh
[21:16] <juliank> I think I want to rewrite global-ben from scratch essentially for the polished version
[21:16] <vorlon> doko: Arch: any -> Arch: all dependencies using (= ${source:Version}) is correct, though?
[21:17] <juliank> It should start with the Sources files for proposed and Release and then go to the binaries from there
[21:17] <vorlon> "a time_t sort of" lol
[21:18] <vorlon> I still get uninstallables reported for riscv64 on https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt that I can't reproduce with chdist + update-output-helper
[21:18] <doko> vorlon: not when the amd64 build fails and other builds succeed
[21:18] <vorlon> doko: that's a transitional issue <shrug>
[21:18] <vorlon> it doesn't make it insane
[21:18] <vorlon> using debian/shlibs.local in 2024, now *that's* insane
[21:18] <juliank> lots of them
[21:18] <doko> you have a deadline, which is before jbicha's end of vacation ;p
[21:20] <mwhudson> uploaded ukui-control-center but i wouldn't be suprised if there are more issues i guess
[21:23] <juliank> noble.armhf reports now use the snapshot service hack for much faster report times
[21:25] <mwhudson> is it worth trying to work out what is breaking folks?
[21:26] <vorlon> oh you mean the package folks
[21:26] <mwhudson> haha yes
[21:28] <vorlon> (as opposed to the folks who package)
[21:29] <doko> we should write up a report on general findings when the transition is done ...
[21:30] <juliank> all is horrible, let's not do this again?
[21:30] <vorlon> "software is terrible and we should plant potatoes"
[21:31] <juliank> What I want to do is cleanup my ad-hoc tools into a nice comprehensive suite of reports to run on archive-reports.ubuntu.com or something
[21:31] <doko> potatoe is EOL
[21:32] <mwhudson> +1 vorlon
[21:33] <vorlon> juliank: please work out how to integrate improvements into the existing reports first as a priority; e.g. replacing ubuntu-archive-tools/checkrdepends which underpins the NBS report
[21:33] <mwhudson> well unsurprisingly folks is vala nonsense
[21:34] <juliank> vorlon: my scripts all heavily use apt_pkg whereas u-a-t seems to avoid it
[21:34] <vorlon> juliank: that's because apt_pkg is inscrutable
[21:34] <vorlon> :P
[21:35] <vorlon> but if someone else implements it I would accept it
[21:35] <juliank> which is also how I handle provides because apt_pkg does those for me
[21:35] <juliank> i.e. I just iterate over dependencies and ask apt_pkg for all targets that can satisfy it
[21:36] <juliank> Doesn't work nicely for build-depends, I manually need to look at cache[name].provides_list in addition to cache[name].version_list instead of dep.all_targets()
[21:36] <juliank> but that's reasonably ok
[21:36] <vorlon> (I will OTOH not accept more ocaml code)
[21:37] <juliank> I can also ship a C++ tool directly in src:apt
[21:37] <vorlon> no thanks
[21:37] <juliank> apt-reports transitions --unstable noble-proposed --testing noble
[21:37] <juliank> would be nice
[21:37] <vorlon> higher barrier to maintenance
[21:38] <vorlon> hmm well doubling the frequency of notest doesn't help, the current report started at :07 is still running
[21:38] <juliank> the logical place would be to avoid python3-apt again and move everything into germinate
[21:39] <juliank> i.e. germinate pretty much does similar things to global-ben in spanning dependency trees
[21:39] <juliank> or I guess subsume germinate
[21:40] <vorlon> I think there's zero overlap in purpose with germinate, I don't see merging these to be a good idea either
[21:40] <juliank> the code is awkwardly related but doesn't translate well
[21:40] <vorlon> more transitive deps of ssreflect popping up, blah
[21:42] <juliank> I might want to write my own bad dose-distcheck
[21:42] <juliank> dose-distcheck is one of the Ocaml codebases :D
[21:42] <vorlon> well, https://ubuntu-archive-team.ubuntu.com/transitions/html/coq.html looks like a lie
[21:42] <juliank> yes ben is broken
[21:42] <juliank> broken for a week at least
[21:43] <doko> not like just that, all of the transitions
[21:43] <juliank> that's why I wrote global-ben
[21:43] <vorlon> juliank: is this the cause or result of the proposal to upgrade it?
[21:43] <juliank> I do not know
[21:43] <juliank> I just know I needed a ben tool and this was broken
[21:43] <juliank> doko said sil2100 was planning to update it
[21:43] <vorlon> yeah, sil2100 and ginggs were talking about updating it to jammy
[21:44] <juliank> If you have a transition I can add it to global-ben for armhf (and amd64)
[21:44] <doko> it was updated, and it didn't help
[21:44] <juliank> I just need old binary names (provides I suppose) removed at least
[21:44] <juliank> Or or how about I track all provides removed too
[21:45] <juliank> Oh I can't do that easily I'm afraid
[21:49] <vorlon> the notest stuff was broken out to make sure it could always be up-to-date even if britney was slow, but when everything is blocked because of autopkgtests it's the opposite, heh
[21:49] <juliank> ooh uninstallable tests I don't have in global-ben lol
[21:51] <mwhudson> afk for a bit
[21:51] <vorlon> what's particularly surprising about the ben breakage is that the dependency levels on https://ubuntu-archive-team.ubuntu.com/transitions/html/coq.html are just wrong
[21:51] <vorlon> I don't like the dependency level representation anyway but I wouldn't expect that to have randomly regressed?
[21:52] <doko> up to now, I only noticed that the "whats bad" information is wrong, and replaced by an empty field
[22:00] <cjwatson> juliank: if you want current state from snapshot.ubuntu.com, you can just leave out the timestamp segment rather than making up a fictitious future one, FYI
[22:03] <vorlon> more garbage tests being queued by britney on i386
[22:05] <cjwatson> juliank: the future-segment hack "works" but it's a bit harder on the database for no benefit
[22:09] <juliank> cool
[22:09] <juliank> vorlon: global-ben now has learnt about Provides, e.g. lots of Rust transitions in there
[22:09] <juliank> enjoy?
[22:10] <juliank> The rule is quite simple: It only considers virtual package where our package is the only provider
[22:10] <juliank> So e.g. if your package is a notification-daemon but no longer is in proposed, that is not a transition
[22:11] <juliank> but if it is a libswipl9 in release and a libswipl9t64 in proposed, that is
[22:11] <juliank> libswipl9 (rebuild-for libswipl9t64) Reverse-Depends: ppl swi-prolog
[22:11] <juliank> hooray
[22:12] <juliank> virtual package transition detection is in beta ;)
[22:12] <vorlon> https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt pffft telling me about the uninstallables on i386, useless
[22:14] <doko> vorlon: is there anything to do about i386? removals, new builds? not now, but tomorrow for me
[22:14] <vorlon> doko: not that I'm aware of
[22:15] <vorlon> having i386 in the notest report is useless specifically because it only shows a small subset of the issues I already know about (flask, sssd)
[22:18] <juliank> cjwatson: that was really helpful, I changed my script now to just use snapshot.ubuntu.com, so happy
[22:20] <cjwatson> :-) I can't speak (any more) for whether builders can/should ultimately use it
[22:20] <juliank> heh
[22:20] <vorlon> AssertionError: '77build1' != '77'
[22:20] <vorlon> >:|
[22:20] <juliank> sounds right
[22:21] <juliank> So if you want uninstallable dependencies, I can also generate a binary dose-distcheck report for amd64 instead of just armhf, maybe that cheers you up
[22:32] <juliank> I know have written an apt installability checker...
[22:32] <juliank> I don't know how long it takes to run
[22:32] <juliank> So it marks all essential packages for install
[22:33] <juliank> then for each package it forks, marks it for install, and then logs to output if it failed and what is broken
[22:33] <juliank> obviously this could use parallel processing but is doing it sequentially
[22:34] <juliank> It tells me chibi-scheme-images is not installable in armhf
[22:34] <juliank> which is true, but not a regression :)
[22:34] <juliank> but at least it works, sort of
[22:35] <juliank> it forks because I'm too lazy to restore state ;)
[22:39] <juliank> you can get it at https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/apt-distcheck.py (where I ran testing :D)
[22:40] <juliank> Soon I will write apt-britney which will calculate installability of proposed updates with apt lol
[22:41] <juliank> ah good the new apt solver design should be able to produce the error message which 2 chains of dependencies conflict with each other
[22:42] <juliank> so apt-distcheck can reach feature parity with dose-distcheck
[22:43] <juliank> it *should* be able to play britney installation set calculation too
[22:43] <juliank> but it's not fast it at
[22:57] <juliank> dm-writeboost-dkms: BAD: cinnamon-desktop-environment
[22:57] <juliank> so weird
[22:58] <juliank> I realize I miss too much solver state in python-apt to render which dependency is broken
[23:04] <mwhudson> vorlon, juliank, doko: where would be most useful for me to point myself?
[23:04] <mwhudson> (apart from at the coffee machine)
[23:05] <juliank> there are a bunch of uninstallable packages in https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/proposed-binaries.txt due to conflicting dependency chains
[23:05] <juliank> it's possible there's fixes in proposed that ftbfs
[23:06] <juliank> well look at https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/proposed-binaries.only-regressions.txt
[23:07] <juliank> it only contains uninstallabilities for packages that are currently in the release pocket
[23:07] <juliank> hmm
[23:08] <juliank> though I guess if it's not in the release pocket it may need fixing anyhow, unless it's an Architecture:all binary
[23:08] <juliank> but these are not usually conflicts but missing depends
[23:08] <juliank>   * alsamixergui depends on conflicting packages: libasound2t64=1.2.11-1build1 vs libasound2=1.2.10-3build1
[23:08] <juliank>     - chain 1: libasound2t64:armhf (>= 1.0.16)
[23:08] <juliank>     - chain 2: alsa-utils:armhf -> libasound2:armhf (>= 1.2.6.1) | libasound2:armhf (>= 1.2.6.1)
[23:08] <juliank> to take this first one
[23:09] <juliank> So we know alsa-utils needs an update
[23:09] <juliank> we see in proposed https://launchpad.net/ubuntu/+source/alsa-utils/1.2.9-1ubuntu2
[23:09] <juliank> but it fully ftbfs
[23:10] <juliank> I expect you end working on the same stuff, whether you go on this report, missing builds on update-excuses, or look at [ ] packages in global-ben output
[23:11] <juliank> e.g. `[alsa-utils]: libasound2 libatopology2` is in https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.reverse.txt too
[23:11] <juliank> Going that file from top to bottom and resolving build failures probably makes sense
[23:12] <juliank> Ignoring the haskell and rust stuff, the package involved in the most transitions seems to be
[23:12] <juliank> krita]: libimath-3-1-29 libopencolorio2.1 libpng16-16 libpoppler-qt5-1 libpython3.12 libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5 libqt5printsupport5 libqt5sql5 libqt5widgets5 libqt5xml5
[23:13] <juliank> you can see from the [krita] that it has a missing build in proposed
[23:14] <juliank> Or going bottom up may be easier, as you'll untangle some transitions along the way allowing the super entangled packages to build, I don't know for sure
[23:15] <mwhudson> oh ukui-control-center built, nice
[23:16] <juliank> I added empty lines between packages now, making the global-ben.reverse.txt easier to read
[23:16] <mwhudson> juliank: have you or anyone else done some work to find packages that directly build-depend on packages that have been renamed?
[23:17] <juliank> I have not yet added that to global-ben
[23:18] <vorlon> 3 more packages picked up for coq
[23:31] <juliank> mwhudson: Tracking now https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.txt, see Reverse-Build-Depends
[23:32] <juliank> Wasn't hard to write
[23:32] <juliank> I see coq now too in global-ben.txt
[23:32] <juliank> libcoq-mathcomp-ssreflect-kper2 Reverse-Depends: coquelicot mathcomp-bigenough mathcomp-finmap [coq-interval] [mathcomp-analysis] [mathcomp-multinomials] [mathcomp-real-closed]
[23:32] <juliank> this is the worst one :)
[23:34] <juliank> mwhudson: I track Build-Depends, Build-Depends-Arch and also Build-Depends-Indep (i.e. the policy is not actually arch specific)
[23:34] <juliank> Well to some extend it is, if you Build-Depends-Indep on a virtual package only provided on amd64, we ignore it
[23:35] <juliank> i.e. we don't see if a virtual package on amd64 changed when inspecting armhf
[23:36] <juliank> Oh yes I think it parses architecture restrcitions for armhf
[23:39] <juliank> I'd ignore the rust ones fwiw, they may be broken reporting
[23:39] <juliank> I don't know their packaging structure enough to figure out if the provides being changed are sensible
[23:41] <juliank> libxmlada-unicode12-dev Reverse-Build-Depends: src:alire
[23:41] <juliank> this is valid as an example
[23:42] <juliank> libxmlada-unicode-dev is the new one
[23:42] <juliank> BUT *Rust* I don't trust
[23:42] <juliank> probably needs more magic
[23:43] <juliank> libclang1-17 (rebuild-for libclang1-17t64) Reverse-Build-Depends: src:linux-aws src:linux-azure src:linux-gcp src:linux-ibm src:linux-lowlatency src:linux-nvidia src:linux-oracle src:linux-raspi
[23:43] <juliank> this is crap
[23:43] <juliank> Talk to kernel team
[23:44] <juliank> gtg almost 1am
[23:47] <juliank> I stayed up to write build-depends tracking for mwhudson :D