/srv/irclogs.ubuntu.com/2024/03/24/#ubuntu-release.txt

-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:02
-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
vorlonboo, freeipa *just* got reuploaded and built because sssd hadn't been removed yet; that would've worked nicely00:03
-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:04
-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
vorlonok, badtesting gdm3/armhf rather than unwinding sssd right now00:05
vorlongst-plugins-good1.0 ftbfs on arm64 with a test timeout, retrying00:08
vorloncoqlib abi changed on no-change rebuild, poking its revdeps00:10
vorlonjuliank: your rebuild of ignition-msgs appears to have changed the Provides: field of libignition-msgs8-800:14
vorlonthus breaking e.g. libignition-fuel-tools-dev00:15
vorlonrust-nix is entangled and has a new upstream version in -proposed00:16
vorlonjbicha: ^^ 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 way00:20
vorlonwhole lot of coq build failures, I guess they need built in series00:26
vorlonjbicha: 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 now00:29
vorlonjbicha: by "fixed" I mean "synced"00:29
vorlonand some desktop rust stuff that needs working through. rust-zvariant-derive -> rust-zvariant -> rust-zbus-names -> rust-zbun00:35
vorlon*zbus00:35
vorlonrust-zvariant-derive has an unclear build failure wrt rust-proc-macro-crate00:36
vorlonok, too new rust-proc-macro-crate in -proposed00:37
vorlonright, 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 chain00:41
jbichavorlon: if you need rust-nix cleared out, then you may need to take out the whole rust GNOME stack in noble-proposed00:53
vorlonjbicha: nah, priorities. I'm nuking the other stuff that's not ready for rust-nix 0.2700:53
vorlonjust did a bunch, letting that cook to get a fresh look after dinner00:53
jbichaok, yeah the priorities are why I didn't get around to finishing the rust GNOME 46 transition in noble yet either00:54
vorlonrust-zbus, rust-erbium-net and revdeps are now gone00:54
jbichaok, thanks00:54
vorlonand rust-calloop now built00:55
=== chris14_ is now known as chris14
vorlonjbicha: the build-dep chain for gnome-online-accounts -> libadwaita-1 on i386 is rather deep.  Can goa build without libadwaita?03:01
vorlonhmm it can if we disable goabackend03:02
vorlonno revdeps on the backend03:02
-queuebot:#ubuntu-release- Packageset: 30 entries have been added or removed03:07
-queuebot:#ubuntu-release- Packageset: Added appstream to i386-whitelist in noble03:22
-queuebot:#ubuntu-release- Packageset: Added gnome-desktop to i386-whitelist in noble03:22
-queuebot:#ubuntu-release- Packageset: Added rust-ouroboros-macro to i386-whitelist in noble03:22
vorlonfixing openmpi on i386 (missing patchelf transitive build-dep), needed for the glib2.0 cluster03:26
vorlonvia polymake -> lrslib03:27
vorlon527s 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.2ubuntu303:32
vorlon>:|03:32
-queuebot:#ubuntu-release- Packageset: Removed appstream from i386-whitelist in noble03:37
-queuebot:#ubuntu-release- Packageset: Removed gnome-desktop from i386-whitelist in noble03:37
-queuebot:#ubuntu-release- Packageset: Removed libadwaita-1 from i386-whitelist in noble03:37
-queuebot:#ubuntu-release- Packageset: Removed python-cryptography from i386-whitelist in noble03:37
-queuebot:#ubuntu-release- Packageset: Removed rust-asn1 from i386-whitelist in noble03:37
-queuebot:#ubuntu-release- Packageset: Removed rust-asn1-derive from i386-whitelist in noble03:37
-queuebot:#ubuntu-release- Packageset: Removed rust-foreign-types-shared from i386-whitelist in noble03:37
-queuebot:#ubuntu-release- Packageset: Removed rust-openssl from i386-whitelist in noble03:37
-queuebot:#ubuntu-release- Packageset: Removed rust-openssl-sys from i386-whitelist in noble03:37
-queuebot:#ubuntu-release- Packageset: Removed rust-ouroboros from i386-whitelist in noble03:37
-queuebot:#ubuntu-release- Packageset: Removed rust-ouroboros-macro from i386-whitelist in noble03:37
-queuebot:#ubuntu-release- Packageset: Removed rust-paste from i386-whitelist in noble03:37
-queuebot:#ubuntu-release- Packageset: Removed rust-pem from i386-whitelist in noble03:38
-queuebot:#ubuntu-release- Packageset: Removed rust-proc-macro2 from i386-whitelist in noble03:38
-queuebot:#ubuntu-release- Packageset: Removed rust-pyo3 from i386-whitelist in noble03:38
-queuebot:#ubuntu-release- Packageset: Removed rust-pyo3-macros from i386-whitelist in noble03:38
-queuebot:#ubuntu-release- Packageset: Removed rust-pyo3-macros-backend from i386-whitelist in noble03:38
-queuebot:#ubuntu-release- Packageset: Removed rust-quote from i386-whitelist in noble03:38
-queuebot:#ubuntu-release- Packageset: Removed rust-syn from i386-whitelist in noble03:38
-queuebot:#ubuntu-release- Packageset: Removed rust-unicode-ident from i386-whitelist in noble03:38
-queuebot:#ubuntu-release- Packageset: Added patchelf to i386-whitelist in noble03:38
Eickmeyerubuntu-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.04:38
vorlonjbicha: 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 stack05:26
vorlongood correlation with other packages currently rendered uninstallable, tho05:29
vorlonjbicha: ah rust-wayland-backend still depends on old rust-nix, so nuking this bunch as well05:31
vorlonopenmpi/i386 sorted05:32
vorlonfrown, can't reproduce any of the current uninstallabilities with update-output-helper07:20
-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:33
-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:34
-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:35
-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:36
-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]07:38
vorlonalright, 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 night08:04
vorlonretrying coq* and akonadi* builds every 2 hours until they're done08:06
juliank<vorlon> juliank: your rebuild of ignition-msgs appears to have changed the Provides: field of libignition-msgs8-808:22
juliankvorlon: peculiar08:22
juliankIs this some magic ABI thing08:22
juliankUh it tries to encode protobuf ABI I suppose08:25
juliankBut I guess it failed because it doesn't expect t64 so protobuf32 became just protobuf08:25
juliankvorlon: yeah so that is eyaxtl what happened  and we probably ought to fix Debian/rules to pick up the t64 in there08:27
juliankBut it can be done later08:28
vorlonjuliank: well ignition* are currently uninstallable, do you want rebuilds against the current virtual package, or08:30
juliankYeah we need to the virtual package is the full ABI08:30
vorlonthat'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:30
juliankThen I should fix the virtual package first08:31
vorlonok08:31
vorlonalrighty, really going to bed now :)08:31
juliankack, will upload and rebuild stuff08:32
dokojuliank: I think openscap-daemon is a wrong positive in your list09:43
juliankdoko: Depends:09:45
juliank dbus,09:45
juliank libopenscap25,09:45
juliank^ there it is09:46
juliankFixing libignition-msgs8-8-protobuf32 -> libignition-msgs8-8-protobuf32t64 provides now09:55
juliankah09:56
juliankso the pattern (libfuse[[:alnum:].-]+) doesn't translate to libprotobuf09:57
juliankneed (libprotobuf[0-9][[:alnum:].-]*)09:57
julianklibprotobuf-dev also depends libprotobuf-lite3209:57
juliankProbably always the safest choice to require [0-9] after the prefix09:57
dokoyes, and  libopenscap25 is a provides, provided by the new openscap t64 library10:09
juliankdoko: on !armhf, yes, but of course not on armhf10:13
juliankdoko: this is the generic pattern, libfoo1t64 provides libfoo1 on 64-bit architectures10:14
juliankI guess you need a break :)10:14
juliankI 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:15
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 ) | ts10:16
juliankmuhaha10:16
-queuebot:#ubuntu-release- New binary: libcanberra [amd64] (noble-proposed/main) [0.30-10ubuntu8] (i386-whitelist, ubuntu-desktop)10:16
juliankheh messed up caribou because it has a control.in10:21
juliankand freeipa because it has a control.common10:24
juliankgst-plugins-good0.1 has libsoup2.4-1 (>= 2.48) | libsoup-3.0-0, so it would install the libsoup-3.0-0 now10:28
juliankCould bump the first one to libsoup-2.4-1 too10:29
juliank*1.0 not 0.110:30
-queuebot:#ubuntu-release- New binary: libcanberra [arm64] (noble-proposed/main) [0.30-10ubuntu8] (i386-whitelist, ubuntu-desktop)10:31
-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
juliankdone10:32
dokothe globus packages: libglobus-common0 (>= 15) | libglobus-common0t64 (>= 15)10:33
juliankheh10:34
juliankI guess they checked which symbols were used10:35
juliankand determined no time_t used so hardcoded alternatives10:35
juliankdoko: 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:42
juliankdoko: Eww, launchpad now published the deleted libcanberra 0.30-12.2ubuntu1 libraries, global-ben just picked up that transition, too early :(10:44
dokofile a bug in Debian ...10:44
dokoI removed the 0.30-12.2ubuntu1 versions just an hour ago10:45
juliankso we should wait for the new libcanberra ones to be published before triggering the build10:45
juliank:)10:45
juliankbut plenty of rebuilds needed10:45
dokoyes, and I don't know how many more merges are missing for the desktop ...10:46
juliank:(10:46
juliankdoko: We could have a report on missing t64 libraries, but it mayn ot be accurate some have been reverted after all10:53
dokobut there are not so many that are reverted, and we can check that with package history.10:55
juliankdoko: https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.missing-t64.txt10:57
juliankdoko: there we go10:57
juliankdoko: This checks vorlon's override map for new names and checks whether any source package in release or proposed builds the new names10:58
juliankProbably worth adding source package names10:58
dokoyes, source names would be helpful11:00
-queuebot:#ubuntu-release- New binary: libcanberra [riscv64] (noble-proposed/main) [0.30-10ubuntu8] (i386-whitelist, ubuntu-desktop)11:01
juliankdoko: Added11:01
juliankShould I order them by source package maybe11:02
-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
dokoyeah for libevent ...11:03
juliankLet me change syntax a bit11:04
juliankdoko: Now it has `source old new`, ordered by source package11:04
julianke.g. src:e2fsprogs is fine11:05
juliankthe libraries were not transitioned just libext2fs211:05
juliankBut I think we could skip them now and try to get the rest migrating first and then do them after the initial stuff went through11:06
dokoyes. can you annotate that list, which ones are not wanted? e.g. binutils11:07
dokopython3.10, 3.1111:07
dokopam reverted11:08
dokomrpt can be removed, new upstream11:10
juliankadded those to ignore list11:10
juliankwhich is hardcoded in the code lol11:10
dokoruby3.1 obsolete11:12
juliankI'm sending an email to ubuntu-devel with the full list11:13
julianksent11:15
jbichavorlon: 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
jbichanothing else uses goa on i38611:25
dokojbicha: any idea about the folks test failures (during build)?12:52
dokovorlon: can speech-disaptcher-contrib ~rc1 work with speech-dispatcher ~rc2?13:16
juliankheh my "until" loop was in the wrong directory, uploaded all ignition rebuilds now14:48
juliankdoko: 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 name14:50
dokoyes14:54
dokowondering if I should do libevent as well, before the work week starts ...14:56
juliankI'm wondering if we should try to migrate with "misbuilt" libevent14:56
juliankbecause this will overflow the queues14:56
juliankI suppose14:56
dokonot more rebuilds than canberra14:57
doko~12014:57
juliankdoko: this one is incomplete: https://launchpad.net/ubuntu/+source/deepin-movie-reborn/5.10.8-2ubuntu1 - you missed libdmr0.114:58
juliankhmm https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.rebuild-for.txt only shows 55 for canberra14:58
dokook, fixing14:58
juliankpresumably the rest are not built on armhf in release pocket14:58
juliankheh global-ben is triggered by gnutls-bin (>= 3.6.6) | libgnutls30 (<< 3.6.0)15:00
julianksigh15:00
dokouploading it, not accepting from NEW15:07
juliankok so we need to sort out libignition-*15:10
juliankI think they need to be built in a particular order maybe15:10
juliankigntion-sensors fails with libignition-transport11-11 : Depends: libignition-msgs8-8-protobuf3215:10
juliankI did not rebuilt libignition-transport I suppose15:11
juliankOh maybe *partially* which is broken now15:12
juliankgazebo needs gui and sensors15:12
juliankso we have so far gazebo > gui and sensors > transport15:12
-queuebot:#ubuntu-release- New binary: libevent [amd64] (noble-proposed/main) [2.1.12-stable-9ubuntu1] (core, i386-whitelist)15:13
-queuebot:#ubuntu-release- New binary: libevent [i386] (noble-proposed/main) [2.1.12-stable-9ubuntu1] (core, i386-whitelist)15:14
julianklaunch needs gazebo and ignition-fuel-tools15:14
juliankso we have so far launch > gazebo + fuel-tools > gui and sensors > transport15:14
-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
juliankhope that's it15:15
julianktransport builds, and I think fuel-tools too15:16
juliankonce transport is published, can build gui and sensors, then gazebo, then launch15:17
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
vorlonwell that's new15:24
dokothat's very old cruft15:25
juliankdoko: found 13 more canberra rebuilds by running the script and checking the changelogs whether you touched them :)15:25
juliankdoko: inclined to upload them https://dpaste.com/36S43BUJ615:26
juliankgnome and kde stuff really15:26
vorlonjbicha: 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
vorlondoko: speech-dispatcher-contrib> no idea but the previous one sure couldn't!15:27
juliankwill go ahead and upload the 13 additional rebuilds!15:27
juliankI checked every changelog and spot checked the control files :)15:27
vorlondoko: very old cruft which confuses and breaks britney.  I'll try to remove it now15:27
juliankOK this should be all the rebuilds so far that I see15:29
vorlonand 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 incorporated15:29
juliankvorlon: should we do libevent now?15:29
juliankYou can have an opinion on that first :)15:29
vorlonjuliank: you already asserted not to on the mailing list, so I'm not sure why the question15:29
juliankwell doko uploaded them but did not approve them15:30
juliankSo you are the tie breaker :)15:30
vorlonbtw 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 today15:30
juliankack15:30
vorlonthere are annotations there about e.g. the kde packages15:30
juliankYeah it's based only on the map15:31
vorlonand uw-imap15:31
vorlonI will double check that the annotation on uw-imap doesn't use any inappropriate language15:31
juliankheh15:31
-queuebot:#ubuntu-release- New binary: libevent [riscv64] (noble-proposed/main) [2.1.12-stable-9ubuntu1] (core, i386-whitelist)15:37
vorlonanother few coq packages needing uploaded for a coq-elpi ABI change rather than libstd-coq; done15:59
juliankI also uploaded gbrainy, fixing broken libcanberra-gtk-3-0 build-depends16:01
juliankNow it uses libcanberra-gtk-3-dev :)16:02
dokomaybe rename it nobrainy ...16:03
julianklol16:06
juliankI think we did get some good work done these past days :)16:11
juliankI wonder if we will need to end up force-skiptest */amd6416:12
juliankor say bye bye to i386 autopkgtests16:15
juliankWe'd at least get double the throughput16:16
juliankBut 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 first16:17
-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:24
julianktrying to dist-upgrade noble with proposed I get:16:29
juliankThe 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-common16:29
juliankinteresting16:29
juliankOnly python3-ipywidgets is not installable, though16:30
juliankpython3-ipywidgets : Depends: jupyter-nbextension-jupyter-js-widgets (= 8.1.1-3) but 8.1.1-2 is to be installed16:30
juliankSo I guess apt solver limitations16:30
juliankI should take a solver dump16:31
juliank  Holding Back google-perftools:amd64 rather than change libgoogle-perftools4t64:amd6416:32
julianksigh16:32
juliankProbably need to inject random conflicts to get the scores correct16:33
juliankah good that ipywidgets is fixed16:37
juliankta doko16:37
dokono, removed package, but the references to the removed packages where not removed :-/16:37
dokowhat is that about google-perftools?16:38
juliankit's fine16:39
juliankthe solver is not happy to remove libgoogle-perftools416:39
juliankUnless you tell it manually16:39
juliankIt's not the smartest solver16:40
juliankWe'll end up having to hint it a bit in u-r-u presumably16:40
juliankfeed 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 algorithm16:40
juliankthe more Conflicts: oldname you have, the more likely apt is to execute the transition rather than hold packages back16:41
juliankSo adding a google-perftools Conflicts: libgoogle-perftools4 may also help16:42
dokothe upgrade still wants to remove some of the desktop, plus ubuntu-release-upgrader =)16:42
juliankgoogle-perftools Conflicts: libgoogle-perftools4 (<< 2.15-3~), libtcmalloc-minimal4 (<< 2.15-3~) makes it happy to upgrade it16:45
juliankdoko: oh I see yes16:46
juliankhinting the solver with `ubuntu-desktop gnome-shell gir1.2-webkit-6.0` makes it happier16:47
juliankthat only removes cheese, orca, rhythmbox, and totem16:48
julianklet's add them to the list16:48
juliankyup, apt dist-upgrade -tnoble -s ubuntu-desktop gnome-shell gir1.2-webkit-6.0 orca cheese rhythmbox totem basically only removes libraries16:49
juliankSo it's all installable, just apt too stupid16:49
juliankPossibly with an apt upgrade && apt dist-upgrade it becomes better, but not sure16:49
juliank# Rebuilding mandos due to mandos-client 1.8.16-1ubuntu1 depending on {'libgnutls30'} - should be {'libgnutls30t64'}16:52
juliankhmm16:52
juliankah yes that was the or group16:53
julianksorry16:53
juliankI think all rebuilds have been done or failed to build16:53
juliankor are in depwait16:54
juliankthe 3 remaining in https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.rebuild-for.txt are just noise16:54
juliankSo 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 step16:54
juliankI'm still waiting for ignition-transport to be built16:54
juliankI probably should run global-ben on amd64 too16:56
juliankthe 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.txt16:58
juliankyou can think these ~roughly correspond to missing armhf builds16:58
juliankor armhf builds that ran much later :)17:00
juliankfwiw, possibly we should collect all libraries in the seeds and then add pre-64 ones to Conflicts to ease upgrades17:01
juliankI can go play around with that, and we can make germinate do that really by feeding it a negative list17:01
juliankor rather reverse mapping17:01
juliankfor each library that is seeded we should Conflict pre-t64 one17:02
juliankbut also we have u-r-u so meh?17:02
juliankJust upgrading existing noble will be hard :D17:02
vorlonjuliank: I wanted to do some selective filtering of the i386 autopkgtests but it was too low-yield17:04
vorlonhow do we have 14k amd64 autopkgtests again17:04
vorlonwe were down to 6k17:04
juliankWe were up to 17k yesterday17:05
vorlonyes, and then bdmurray deleted stuff17:05
vorlonand then it's back up again17:05
juliankvorlon: most of them are your requests17:05
vorlonI'm sure they aren't17:06
vorlonwhen I was done requesting, we were at max 12k, *before* bdmurray pruned17:06
vorlonI do see britney queuing multiple redundant tests17:07
vorlonpmount {"triggers": ["pmount/0.9.23-7.1"], "submit-time": "2024-03-24 00:53:58"}17:07
vorlonpmount {"triggers": ["pmount/0.9.23-7.1"], "submit-time": "2024-03-24 02:12:10"}17:07
juliankIn [7]: sum(1 if "vorlon" in item else 0 for item in q["ubuntu"]["noble"]["amd64"])17:07
juliankIn [7]: sum(1 if "vorlon" in item else 0 for item in q["ubuntu"]["noble"]["amd64"])17:07
juliankOut[7]: 1246417:07
vorlonhmm17:07
vorlonI don't know why that count didn't come down, then17:07
vorlonpmount {"triggers": ["pmount/0.9.23-7.1"], "submit-time": "2024-03-24 09:59:24"}17:08
vorlonffs britney17:08
juliankI also sadly don't have access to the infrastructure anymore to do queue manipulation17:08
vorlonpmount {"triggers": ["pmount/0.9.23-7.1"], "submit-time": "2024-03-24 11:20:43"}17:08
juliankor maybe I don't have the key here17:08
juliankbut I should17:08
vorlondon't you? I do, so if you see a pattern that I should kill...17:08
vorlonright so the other 5k may be the same 30 tests being requeued over and over again :P17:09
vorlonI'll run a amqp-filter-dupes at least17:09
juliankwe can drop *2* tests by merging triggers17:09
juliankso I don't think there are dupes in there17:10
juliankOr my script to count merging is wrong17:10
juliank:D17:10
juliankit loads all queues, groups by package being tested, then iterates over all requests, does trigger union, and appends it to an output list17:10
vorlonwell per the above, a number of tests are being triggered by britney in a loop17:10
juliankok my script is broken i think17:11
vorlonbah we only have filter-amqp-dupes-upstream17:12
vorlonI thought there was one for !upstream17:12
vorlonnevermind, not futzing with this now, they're so far down in the queue17:12
juliankYes sorry17:13
juliankThere are only 7k if we merge triggers17:13
vorlonreally?17:13
juliankitertools.groupby() needs an ordered input17:13
juliankBut it merges all-proposed and not all-proposed17:13
vorlonoh17:13
vorlonyeah I need a negative filter to delete the !all-proposed ones17:14
juliankIf that's fine I can give you a list of all requests with all triggers merged and all-proposed set17:14
juliankand the script to verify the logic17:14
juliankor you can I guess delete the queues17:15
juliankand then do retry-autopkgtest-regressions --state=RUNNING17:15
juliankand you have the same effect17:15
vorlondo you account for migration-reference/017:15
julianknot yet, sorry17:15
vorlonthen not that :)17:15
julianklet's see17:15
vorlonthere are some in the queue that are not --state=RUNNING17:15
vorlonI'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 yet17:16
dokovorlon: so, when you're delaying that work, I'd like to go on with libevent17:18
vorlondoko: delaying what work?17:18
vorlonI'm saying that manipulating the amd64 test queue right now is titanic-deckchair-rearranging17:19
vorlondoko: how many packages have to be rebuilt for libevent?17:19
julianki386: 9739 -> 285217:19
vorlonjuliank: by merging triggers?17:20
vorlonthat one I'll happily do17:20
juliankyeah17:20
juliankand amd64: 14180 -> 763817:20
vorlonjuliank: flush queue && retrigger --state=RUNNING?17:20
juliankvorlon: this is the script that did the merging: https://gist.github.com/julian-klode/2785b07e76abaed78d34242a39d9bf0b17:21
juliankvorlon: so if i386 has no requestor, than flush and retrigger --state=RUNNIGN should work too17:22
juliankotherwise the coolest move is to add amqplib support to the script and have it just write the merged queue items after flushing the queue17:22
juliankor patching it to produce run-autopkgtest commands17:22
vorlonI'd rather reimport from update_excuses, that also filters out any obsolete triggers/requests as a side benefit17:23
vorlonanyway, flushed && now requeuing17:23
juliankDo you remember what you retried yesterday to retry those again?17:24
juliank:D17:24
vorlonI didn't retry things on i38617:24
juliankah17:24
dokovorlon: ~12017:24
juliankvorlon: Oh I guess all your tests may simply be scheduled twice, so really do the dupes filtering17:25
juliankDid filter-amqp-dupes not survive to ps5 sigh17:26
vorlonprobably not if it wasn't committed17:26
vorlondoko: ick.  I don't suppose you have insight into how long it will take to get them all built in launchpad?17:27
vorlondoko: to me it sounds like a risk that it will delay getting the current transition done17:27
dokoit's three levels, like canberra.17:28
dokook17:28
vorlonto 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 point17:32
juliankdupes are 14182 - 8057 = 6125 tests in the amd64 queues17:33
vorlonteeny tiny queue on i386 now https://autopkgtest.ubuntu.com/running17:34
vorlonuh I don't think that's what 'huge' means https://autopkgtest.ubuntu.com/running#queue-huge-noble-amd6417:34
arraybolt3Huge: adj. large in size.17:35
* arraybolt3 goes back to coding rather than being annoying17:36
dokovorlon: so maybe set the queue accept to manual for a day?17:37
juliankvorlon: 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 script17:37
juliankit does preserve any migration-reference/017:38
juliankoh you are retriggering i386 over http? that is ... slow17:38
juliankI can encode urls too17:40
juliankJust need to know :)17:41
juliankavoiding 6k tests sounds like a good idea17:41
juliankAh my output misses the name of the package to test17:44
juliankWell I updated it stealing from retry-autopkgtest-regressions for run-autopkgtest :)17:46
juliankvorlon: Script now also does URLs based on the retry-autopkgtest-regressions code17:50
juliankvorlon: are we missing i386? you last scheduled 6 minutes ago, but we only have 463 requests17:51
juliankWell I guess it got to vim so that's all?17:52
juliankcertainly there were only a handful of retries on i38617:53
juliankI 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 it18:01
juliankOh I guess the retry with --state=RUNNING dropped all the RUNNING-ALWAYSFAIL18:04
juliankjak@jak-t14-g3:~/Projects/Ubuntu/ubuntu-archive-tools:main$ ./retry-autopkgtest-regressions --state=RUNNING-ALWAYSFAIL | grep i386 | wc -l18:06
juliank402518:06
juliankjak@jak-t14-g3:~/Projects/Ubuntu/ubuntu-archive-tools:main$ ./retry-autopkgtest-regressions --state=RUNNING | grep i386 | wc -l18:06
juliank46218:06
juliankyup18:06
juliankImagine 90% of i386 tests we normally run are not regression blockers18:06
juliankamd64: 10891 running and only 369 running-alwaysfail18:08
juliankmuch better18:08
juliankShould we think about killing i386 autopkgtests for 24.1018:08
juliank$ ./retry-autopkgtest-regressions --state=RUNNING | grep armhf | wc -l18:09
juliank95118:09
juliankshould we trigger those again?18:09
juliankarmhf is empty18:09
juliankI guess we just killed a ton of ppc64el and s390x18:11
juliankthey are both at about 6300 tests in RUNNING state18:11
juliankdespite empty queues18:11
=== alucardromero2 is now known as alucardromero
juliankbuilding ignition-gui and ignition-sensors now, ignition-transport finally published18:16
julianksigh18:17
juliank i libignition-rendering6-6 : Depends: libignition-common4-4 (>= 4.5.0+ds) but it is not installable18:18
juliank                            Depends: libignition-common4-graphics4 (>= 4.5.0+ds) but it is not installable18:18
juliank libignition-rendering6-ogre1-6 : Depends: libignition-common4-4 (>= 4.5.0+ds) but it is not installable18:18
juliank                                  Depends: libignition-common4-events4 (>= 4.5.0+ds) but it is not installable18:18
juliank                                  Depends: libignition-common4-graphics4 (>= 4.5.0+ds) but it is not installable18:18
juliank                                  Depends: libogre-1.9.0v5 (>= 1.9.0+dfsg1-9~) but it is not installable[1~18:18
julianknot sure but I guess ignition-rendering needs a rebuild, and maybe ignition-common18:18
dokomutter ... not running tests on anything than amd64, and then becoming uninstallable when the amd64 tests fail ...18:18
juliankok yeah ignition-common seems fine according to global-ben but ignition-rendering needsa  build18:20
juliankwhich fails with /<<PKGBUILDDIR>>/src/BoundingBox.cc:48:18: error: ‘exchange’ is not a member of ‘std’18:21
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_t18:26
juliankThis doesn't make it better18:26
vorlonjuliank: 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 matters18:26
juliankhmm maybe export DEB_CPPFLAGS_MAINT_APPEND = -DIGNITION_RENDERING_VISIBLE=18:29
juliankignition-* should be killed18:29
juliankthe last update was in 22.04 and it's not building?18:29
juliankit uses undefined macros...18:30
vorlonI need someone to figure out why rsync is failing to pick up new update_output_notest files :/18:30
vorloneh no in this case the file hasn't been updated on the server18:31
juliankDo I need to build with c++14?18:31
vorlonhttps://ubuntu-archive-team.ubuntu.com/proposed-migration/log/noble/2024-03-24/17:07:01.notest.log producing no output :/18:32
vorlonjuliank: "should be killed" is valid18:34
juliankvorlon: 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-utils18:34
juliankOr demote them to proposed18:34
juliankvorlon: sdformat is the reverse-depends of one of the ignition ones18:35
vorlondemote to proposed> nack18:35
juliankI'll file removal bug?18:35
vorlonremoval> with pleasure18:35
vorlonis there a ftbfs bug anywhere in Debian already?18:35
juliankvorlon: It#s not packaged there18:35
juliankvorlon: or not fully18:36
vorlonwhat seriously18:36
juliankthe one that is failing is https://launchpad.net/ubuntu/+source/ignition-rendering/ and the stack down from that18:36
juliankthat is 6.1.0+ds-0ubuntu218:36
vorlonjuliank: ok please file a removal bug on that one yeah18:36
juliankyeah but that fails everything else except I think sensors and common18:37
vorlonfwiw ROS upstream has also been talking to our robotics team and wants these packages removed18:37
juliankWhat do I say ignition-sensors is also depending on ignition-rendering18:37
vorlonif they're Ubuntu-specific and unmaintained then yes please, nuke from orbit18:37
juliankI can only say the entire set is self-contained but figuring out which parts we can pull is much harder18:38
vorlona removal bug on the ftbfs package saying "and all its recursive revdeps" is sufficient in this case18:39
juliank OK found them all by filtering for 0ubuntu :)18:39
juliankand that set is self-contained too18:40
juliankvorlon: https://bugs.launchpad.net/ubuntu/+source/ignition-sensors/+bug/205885118: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:41
dokoremoving ...18:52
dokoahh, you're already doing18:53
juliankI'm just do it faster I should eat dinner18:59
juliankI probably should take a swap day next weekend18:59
dokoyou can take as many swap days on weekends as you want =)19:05
juliankjbicha: mutter FTBFS https://launchpadlibrarian.net/720986950/buildlog_ubuntu-noble-amd64.mutter_46.0-1ubuntu2_BUILDING.txt.gz19:06
juliankdoko: well around the weekend :)19:06
dokoyes, see -1ubuntu319:06
juliankooh19:07
juliankthat was hidden19:07
juliank:D19:07
juliankthanks19:07
juliankcan we remove the courier stack?19:07
juliank:D19:07
mwhudsongood morning19:07
juliankon armhf19:07
juliankmwhudson: investigate what we need to remove for courier on armhf ? :D19:08
mwhudsonjuliank: can do in a bit19:08
mwhudsonneed to shuffle children around a bit first19:08
mwhudsonhave we removed the osmo stack yet?19:08
juliankI do not know19:09
juliankjust remove all universe/hamradio :D19:10
juliankI still see osmo-bts19:10
juliankcurrently we are removing the old jammy ignition stack19:11
juliankvorlon: has notest ever produced output?19:11
juliankcouple crash reports yesterday that got gzipped, but otherwise, always 89 bytes19:12
vorlonjuliank: no; that's identical output in the log, no errors shown and no output file19:20
vorlon*this* time the file was copied correctly19:22
juliankI feel like I should write a removal set calculator and then add it to ubuntu-archive-tools19:24
juliankyou feed it "remove foo" and it calculates what reverse dependencies need removing too19:25
vorlonI would just like a reverse-depends tool that was reliable19:25
vorlonhandled provides19:25
juliankThat comes soon :)19:25
vorlondidn't occasionally have false-positives19:25
juliankremoval-candidates basically is too safe right now19:25
juliankBut it can do reverse-depends too in theory19:26
juliankBut since it tracks Tasks and Provides fully it is too safe19:26
juliankit refuses to remove anything providing notification-daemon19:26
juliankor in reverse-depends mode (which is not public) would tell you everything depending on that19:26
juliankI think the answer is when we look at dependencies19:27
juliankwe should only consider dependencies that have our package we want to "remove" as the single solution19:27
vorlonhttps://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
vorlonignition gunk removed19:28
juliankta19:28
juliankIf you have a x Depends: a | b and you do reverse-depends b, do you want to see x?19:29
juliankor not because a also satisfies it?19:29
juliankThis gets fancy when you consider recursion19:29
vorlonI want to see x and also see that a is an alternative19:29
juliankAnd probably it would make sense to combine this with edos-distcheck19:30
vorlonthis is what we do now on https://ubuntu-archive-team.ubuntu.com/nbs.html IIRC but that has other limitations19:30
julianki.e. you remove the packages from the data set and see if new uninstallabilities appeart19:30
vorlon(i.e. https://ubuntu-archive-team.ubuntu.com/nbs.html still does not distinguish between Depends and Recommends)19:30
juliankI sort of wrote my own nbs report19:30
juliankWell part of global-ben's log :D19:31
juliankI think for a provides we should show Reverse-Depends: < 5000 packages depending on notification-daemon>19:32
vorlonwell, libcanberra rebuilds set cinnamon back again19:32
juliankand then you need to either say I don't care or run reverse-depends notification-daemon19:32
juliank(assuming there are other providers hence that example)19:32
vorlonit is what it is, but I can't actually get a reliable view on armhf until the other archs are zeroed wrt installability regressions19:32
juliank(if we are the only provider, reverse dependencies of the provide are ours)19:32
vorlonjuliank: ignition-transport-cli wasn't on your removal list, it has "unsatisfiable dependency"19:33
julianknew one should be fine19:34
juliank11.0.0+ds-4build319:34
juliankuploaded 4 hours ago19:34
juliankthat was the libignition-msgs8-8-protobuf32t64 rebuilds19:34
vorlonok19:35
vorlonyeah I see it now on a refresh19:35
vorlonnot sure why that didn't get solved in the current notest tho, riscv64 built 3 hours ago19:36
juliankvorlon: Launchpad Runs slowly19:36
juliankIt took about 5 hours or so for the first package to be published19:37
vorlonlibsoup-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
juliankThe ignition-msgs build19:37
vorlonjuliank: um that's not acceptable? if it's taking that long we need to escalate to the launchpad team19:37
vorlonI was complaining about any launchpad publisher run taking longer than *15 minutes*19:37
juliankWe can double check, but it's certainly hours19:38
vorlonit was 30 minutes last I looked19:38
vorlonhours would also not be consistent with the progress I've made on the coq stack ftr19:38
juliankI look at rmadison  and it takes hours for builds to appear19:38
juliankAnd you said it syncs from internal every 15 mins or so?19:38
vorlonok, rmadison is not the yardstick either though, it does pull from ftpmaster.internal but there are other potential mirroring/propagation delays there19:39
vorlonand I don't want to shave an rmadison yak today19:39
vorlonbritney itself is closer to the source, as are the launchpad builds, and I haven't seen evidence of hour+ publication delays19:40
vorlonsomething boost-pythony regressed19:40
vorlonpython3-columbus, python3-cv-bridge, python3-minieigen, python3-opencamlib, python3-py3exiv2, python3-pythonmagick, python3-tagpy,19:41
vorlonseems to be because boost1.83 is being considered and it wasn't before?19:42
vorlonblocking boost1.83, I haven't seen anywhere else that it's a requirement and no-change rebuilds of revdeps haven't happened yet19:43
juliankvorlon: 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 many19:43
vorlonerm19:43
juliankThat was the thread on launchpad mattermost19:44
vorlonwhat I was seeing was 40 minutes from the time of the start of the publisher run to when indices were published19:44
juliankWhere I asked if rmadison was accurate19:44
juliankBecause I tried rebuilding after an hour or so and it failed19:44
juliankAnd then I was what do I wait for?19:44
juliankAnd I just retried more and more19:45
vorlonif it shows up on rmadison, it should be reliable that it works in launchpad builders19:45
vorlonbut rmadison *is* slower19:45
vorlonit should be faster than waiting for archive.ubuntu.com19:46
vorlonok boost-python rebuilds safe to upload, no built packages in -proposed that will be reset19:47
vorlon speech-dispatcher-kali : Depends: speech-dispatcher (< 0.12.0~rc1.0~) but 0.12.0~rc2-2build1 is to be installed19:49
vorlondoko: ^ so no, speech-dispatcher-contrib is not compatible :P19:49
vorlonremoving19:50
vorlonubuntukylin also appears to be in a bad way19:51
vorlon ukui-themes : Conflicts: ubuntukylin-theme but 3.0.4 is to be installed19:51
vorlonuploaded ukui-session-manager to revert unexplained dropping of the alternative dep19:59
vorlonok 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 delayed20:00
vorlonmeh it's only the main britney runs that copy output_notest to the public_html directory, as I feared. fixing20:04
vorlonthe last piece here then is freeipa+sssd20:08
vorlonwhich I may just have to remove (on armhf) despite it being non-trivial to do so20:08
vorlonthings 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:10
vorlonjust removing yade from the release pocket for now20:14
vorloncoq will take a while yet on account of riscv64 taking 11 hours on riscv64, looking at some surgical binary removals there as well20:15
juliankOoh I wonder now if I can use the snapshot service to get a latest archive view ahead of mirrors20:25
juliankIt should talk directly to launchpad db20:25
juliankShould be "live"20:25
vorlonok coq binary removals done (armhf and arm64 for some in addition to riscv64), and kicked a build loop again, afk now for a bit20:27
vorlonand still no clue why sssd tests pass when I run them by hand :/20:27
mwhudsoni 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
juliankConfirmed20:28
juliankthis gives me the latest view https://snapshot.ubuntu.com/ubuntu/99990101T000000Z/dists/noble-proposed/InRelease20:29
juliankam I evil? maybe!20:29
juliankI don't know if Launchpad team tested with future timestamps and this might mess up caching logic20:29
juliankotherwise I can make my reports use that and get much faster feedback20:31
mwhudsonjuliank: shame we can't copy from the mid april 2024 snapshot20:34
juliankheh20:35
juliankcurl -s  https://snapshot.ubuntu.com/ubuntu/99990101T000000Z/dists/noble-proposed/InRelease | grep Date20:36
juliankDate: Sun, 24 Mar 2024 20:22:26 UTC20:36
juliankbut this is nice20:36
juliankand yes this is about 30 mins ahead of archive.ubuntu.com, vorlon20:36
juliankugh20: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.1ubuntu220: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:armhf20: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
juliankI think one of them is Provides :)20:45
juliankAh no it isn't20:45
juliankSo this is funny20:45
julianklibswipl9 is provided by old swi-prolog-nox20:46
julianklibswipl9t64 by new one20:46
juliankNew one still has Depends on old name20:46
juliankThat's showing up quite a bit in distcheck report20:46
* juliank digging20:47
vorlonah yes there we go, that's one of the virtual packages I forgot20:47
juliankOh god this is annyoing20:47
juliankThey keep the t64_provides as libswipl9 on 64-bit archs20:47
juliankso it needs different shlibs per bitness20:48
juliankNevermind20:48
juliankI'm stupid20:48
juliankfixing20:48
mwhudsonif access to packages via snapshot is earlier, can we configure builders to use it??20:51
juliankheh20:51
juliankSo 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 chains20:52
mwhudsoni mean if i want access to the debs earlier i can get them from the build page20:52
mwhudsoni guess it lets you analyze transition progress a bit sooner20:52
juliankWe can save 30 mins by talking to snapshot service vs archive.ubuntu.com20:53
juliankNote 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
juliankAlso note that many issues may just be missing builds, e.g. xca20:54
juliankthe prolog one also is the last "trivial conflict"; so we seemingly fixed all hardcoded dependencies for everything that has transitioned to t6420:55
julianklibevent-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-webengine20:57
juliankqtwebengine-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 transition20:57
juliankWe still have plenty of libglib2.0 reverse dependencies missing builds20:58
juliankas well as qt520:58
juliankI think I need a reverse view of global-ben, currently it's: this library needs these packages to transition20:59
juliankbut I also want: this package is blocking these transitions20:59
mwhudson$ show_untransitioned libglib2.0-0 | wc -l21:00
mwhudson9921:00
mwhudsonso yeah21:00
mwhudson(probably some false positives in there)21:00
mwhudsonall the haskell-gi-* packages are hosed. a bunch are blocked on the folks ftbfs. there are some that build-depend on libglib2.0-0 still21:03
juliankhere is the reverse view https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.reverse.txt21:05
juliankoh it's not alphabetical21:06
juliankProbably sort by number of blocking, name21:06
juliankNow we have a good view21:08
julianki.e. the top package blocks the most transitions21: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:08
dokognome packaging is insane21:09
dokoackage: libfolks2621:09
dokoArchitecture: any21:09
dokoDepends: folks-common (= ${source:Version}),21:09
mwhudsonlibgnatcoll-db is ada, all that needs to go21:09
dokofolks-common being binary-all21:09
dokomwhudson: I'll care about gnat tomorrow, basically removing the non-building packages21:10
mwhudsonyeah, just don't want anyone else to waste time looking at it21:11
juliankShould reverse report also put packages with uploads in proposed in []?21:11
vorlonmwhudson: snapshots is earlier than archive.ubuntu.com, it's not earlier than ftpmaster.internal that the builders already use21:12
mwhudsonlet's have a look at ukui-control-center shall we21:12
juliankOK I put [] around everything missing a build in proposed, or being from a NBS release build21:14
juliankMaybe NBS release builds should be hidden harder21:14
vorlontemporarily doubling the frequency of the notest runs (30m vs 1h)21:14
mwhudson    long tmit;   // the time -- This is a time_t sort of21:16
mwhudsonuhh21:16
juliankI think I want to rewrite global-ben from scratch essentially for the polished version21:16
vorlondoko: Arch: any -> Arch: all dependencies using (= ${source:Version}) is correct, though?21:16
juliankIt should start with the Sources files for proposed and Release and then go to the binaries from there21:17
vorlon"a time_t sort of" lol21:17
vorlonI 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-helper21:18
dokovorlon: not when the amd64 build fails and other builds succeed21:18
vorlondoko: that's a transitional issue <shrug>21:18
vorlonit doesn't make it insane21:18
vorlonusing debian/shlibs.local in 2024, now *that's* insane21:18
julianklots of them21:18
dokoyou have a deadline, which is before jbicha's end of vacation ;p21:18
mwhudsonuploaded ukui-control-center but i wouldn't be suprised if there are more issues i guess21:20
julianknoble.armhf reports now use the snapshot service hack for much faster report times21:23
mwhudsonis it worth trying to work out what is breaking folks?21:25
vorlonoh you mean the package folks21:26
mwhudsonhaha yes21:26
vorlon(as opposed to the folks who package)21:28
dokowe should write up a report on general findings when the transition is done ...21:29
juliankall is horrible, let's not do this again?21:30
vorlon"software is terrible and we should plant potatoes"21:30
juliankWhat 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 something21:31
dokopotatoe is EOL21:31
mwhudson+1 vorlon21:32
vorlonjuliank: 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 report21:33
mwhudsonwell unsurprisingly folks is vala nonsense21:33
juliankvorlon: my scripts all heavily use apt_pkg whereas u-a-t seems to avoid it21:34
vorlonjuliank: that's because apt_pkg is inscrutable21:34
vorlon:P21:34
vorlonbut if someone else implements it I would accept it21:35
juliankwhich is also how I handle provides because apt_pkg does those for me21:35
julianki.e. I just iterate over dependencies and ask apt_pkg for all targets that can satisfy it21:35
juliankDoesn'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
juliankbut that's reasonably ok21:36
vorlon(I will OTOH not accept more ocaml code)21:36
juliankI can also ship a C++ tool directly in src:apt21:37
vorlonno thanks21:37
juliankapt-reports transitions --unstable noble-proposed --testing noble21:37
juliankwould be nice21:37
vorlonhigher barrier to maintenance21:37
vorlonhmm well doubling the frequency of notest doesn't help, the current report started at :07 is still running21:38
juliankthe logical place would be to avoid python3-apt again and move everything into germinate21:38
julianki.e. germinate pretty much does similar things to global-ben in spanning dependency trees21:39
juliankor I guess subsume germinate21:39
vorlonI think there's zero overlap in purpose with germinate, I don't see merging these to be a good idea either21:40
juliankthe code is awkwardly related but doesn't translate well21:40
vorlonmore transitive deps of ssreflect popping up, blah21:40
juliankI might want to write my own bad dose-distcheck21:42
juliankdose-distcheck is one of the Ocaml codebases :D21:42
vorlonwell, https://ubuntu-archive-team.ubuntu.com/transitions/html/coq.html looks like a lie21:42
juliankyes ben is broken21:42
juliankbroken for a week at least21:42
dokonot like just that, all of the transitions21:43
juliankthat's why I wrote global-ben21:43
vorlonjuliank: is this the cause or result of the proposal to upgrade it?21:43
juliankI do not know21:43
juliankI just know I needed a ben tool and this was broken21:43
juliankdoko said sil2100 was planning to update it21:43
vorlonyeah, sil2100 and ginggs were talking about updating it to jammy21:43
juliankIf you have a transition I can add it to global-ben for armhf (and amd64)21:44
dokoit was updated, and it didn't help21:44
juliankI just need old binary names (provides I suppose) removed at least21:44
juliankOr or how about I track all provides removed too21:44
juliankOh I can't do that easily I'm afraid21:45
vorlonthe 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, heh21:49
juliankooh uninstallable tests I don't have in global-ben lol21:49
mwhudsonafk for a bit21:51
vorlonwhat'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 wrong21:51
vorlonI don't like the dependency level representation anyway but I wouldn't expect that to have randomly regressed?21:51
dokoup to now, I only noticed that the "whats bad" information is wrong, and replaced by an empty field21:52
cjwatsonjuliank: 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, FYI22:00
vorlonmore garbage tests being queued by britney on i38622:03
cjwatsonjuliank: the future-segment hack "works" but it's a bit harder on the database for no benefit22:05
juliankcool22:09
juliankvorlon: global-ben now has learnt about Provides, e.g. lots of Rust transitions in there22:09
juliankenjoy?22:09
juliankThe rule is quite simple: It only considers virtual package where our package is the only provider22:10
juliankSo e.g. if your package is a notification-daemon but no longer is in proposed, that is not a transition22:10
juliankbut if it is a libswipl9 in release and a libswipl9t64 in proposed, that is22:11
julianklibswipl9 (rebuild-for libswipl9t64) Reverse-Depends: ppl swi-prolog22:11
juliankhooray22:11
juliankvirtual package transition detection is in beta ;)22:12
vorlonhttps://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt pffft telling me about the uninstallables on i386, useless22:12
dokovorlon: is there anything to do about i386? removals, new builds? not now, but tomorrow for me22:14
vorlondoko: not that I'm aware of22:14
vorlonhaving 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:15
juliankcjwatson: that was really helpful, I changed my script now to just use snapshot.ubuntu.com, so happy22:18
cjwatson:-) I can't speak (any more) for whether builders can/should ultimately use it22:20
juliankheh22:20
vorlonAssertionError: '77build1' != '77'22:20
vorlon>:|22:20
julianksounds right22:20
juliankSo if you want uninstallable dependencies, I can also generate a binary dose-distcheck report for amd64 instead of just armhf, maybe that cheers you up22:21
juliankI know have written an apt installability checker...22:32
juliankI don't know how long it takes to run22:32
juliankSo it marks all essential packages for install22:32
juliankthen for each package it forks, marks it for install, and then logs to output if it failed and what is broken22:33
juliankobviously this could use parallel processing but is doing it sequentially22:33
juliankIt tells me chibi-scheme-images is not installable in armhf22:34
juliankwhich is true, but not a regression :)22:34
juliankbut at least it works, sort of22:34
juliankit forks because I'm too lazy to restore state ;)22:35
juliankyou can get it at https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/apt-distcheck.py (where I ran testing :D)22:39
juliankSoon I will write apt-britney which will calculate installability of proposed updates with apt lol22:40
juliankah good the new apt solver design should be able to produce the error message which 2 chains of dependencies conflict with each other22:41
juliankso apt-distcheck can reach feature parity with dose-distcheck22:42
juliankit *should* be able to play britney installation set calculation too22:43
juliankbut it's not fast it at22:43
juliankdm-writeboost-dkms: BAD: cinnamon-desktop-environment22:57
juliankso weird22:57
juliankI realize I miss too much solver state in python-apt to render which dependency is broken22:58
mwhudsonvorlon, juliank, doko: where would be most useful for me to point myself?23:04
mwhudson(apart from at the coffee machine)23:04
juliankthere are a bunch of uninstallable packages in https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/proposed-binaries.txt due to conflicting dependency chains23:05
juliankit's possible there's fixes in proposed that ftbfs23:05
juliankwell look at https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/proposed-binaries.only-regressions.txt23:06
juliankit only contains uninstallabilities for packages that are currently in the release pocket23:07
juliankhmm23:07
juliankthough I guess if it's not in the release pocket it may need fixing anyhow, unless it's an Architecture:all binary23:08
juliankbut these are not usually conflicts but missing depends23:08
juliank  * alsamixergui depends on conflicting packages: libasound2t64=1.2.11-1build1 vs libasound2=1.2.10-3build123: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
juliankto take this first one23:08
juliankSo we know alsa-utils needs an update23:09
juliankwe see in proposed https://launchpad.net/ubuntu/+source/alsa-utils/1.2.9-1ubuntu223:09
juliankbut it fully ftbfs23:09
juliankI 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 output23:10
julianke.g. `[alsa-utils]: libasound2 libatopology2` is in https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.reverse.txt too23:11
juliankGoing that file from top to bottom and resolving build failures probably makes sense23:11
juliankIgnoring the haskell and rust stuff, the package involved in the most transitions seems to be23:12
juliankkrita]: libimath-3-1-29 libopencolorio2.1 libpng16-16 libpoppler-qt5-1 libpython3.12 libqt5core5a libqt5dbus5 libqt5gui5 libqt5network5 libqt5printsupport5 libqt5sql5 libqt5widgets5 libqt5xml523:12
juliankyou can see from the [krita] that it has a missing build in proposed23:13
juliankOr 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 sure23:14
mwhudsonoh ukui-control-center built, nice23:15
juliankI added empty lines between packages now, making the global-ben.reverse.txt easier to read23:16
mwhudsonjuliank: have you or anyone else done some work to find packages that directly build-depend on packages that have been renamed?23:16
juliankI have not yet added that to global-ben23:17
vorlon3 more packages picked up for coq23:18
juliankmwhudson: Tracking now https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/global-ben.txt, see Reverse-Build-Depends23:31
juliankWasn't hard to write23:32
juliankI see coq now too in global-ben.txt23:32
julianklibcoq-mathcomp-ssreflect-kper2 Reverse-Depends: coquelicot mathcomp-bigenough mathcomp-finmap [coq-interval] [mathcomp-analysis] [mathcomp-multinomials] [mathcomp-real-closed]23:32
juliankthis is the worst one :)23:32
juliankmwhudson: I track Build-Depends, Build-Depends-Arch and also Build-Depends-Indep (i.e. the policy is not actually arch specific)23:34
juliankWell to some extend it is, if you Build-Depends-Indep on a virtual package only provided on amd64, we ignore it23:34
julianki.e. we don't see if a virtual package on amd64 changed when inspecting armhf23:35
juliankOh yes I think it parses architecture restrcitions for armhf23:36
juliankI'd ignore the rust ones fwiw, they may be broken reporting23:39
juliankI don't know their packaging structure enough to figure out if the provides being changed are sensible23:39
julianklibxmlada-unicode12-dev Reverse-Build-Depends: src:alire23:41
juliankthis is valid as an example23:41
julianklibxmlada-unicode-dev is the new one23:42
juliankBUT *Rust* I don't trust23:42
juliankprobably needs more magic23:42
julianklibclang1-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-raspi23:43
juliankthis is crap23:43
juliankTalk to kernel team23:43
juliankgtg almost 1am23:44
juliankI stayed up to write build-depends tracking for mwhudson :D23:47

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!