[00:18] <vorlon> mwhudson: flask is now a candidate, but by itself does not migrate; next notest report (post 2024.03.25 22:39:40) might show some new flask-related uninstallables
[00:43] -queuebot:#ubuntu-release- New binary: singularity-container [amd64] (noble-proposed/universe) [4.1.1+ds2-1] (no packageset)
[01:01] <vorlon> mwhudson: had a thought while I was afk that oh, the only thing stopping flask from being a candidate before was tests... so it was already on notest... but not included in the mass hint because of a net increase in uninstallables.  So we actually do have to resolve those revdeps
[01:01] <vorlon> trying: flask onionshare flask-security
[01:01] <vorlon> afk dinner
[01:01] <vorlon>     * amd64: python3-fava
[01:07] -queuebot:#ubuntu-release- New binary: singularity-container [s390x] (noble-proposed/universe) [4.1.1+ds2-1] (no packageset)
[01:08] -queuebot:#ubuntu-release- New binary: singularity-container [armhf] (noble-proposed/universe) [4.1.1+ds2-1] (no packageset)
[01:11] <mwhudson> vorlon: i'm almost done for now too
[01:17] -queuebot:#ubuntu-release- New: accepted singularity-container [amd64] (noble-proposed) [4.1.1+ds2-1]
[01:17] -queuebot:#ubuntu-release- New: accepted singularity-container [s390x] (noble-proposed) [4.1.1+ds2-1]
[01:17] -queuebot:#ubuntu-release- New: accepted singularity-container [armhf] (noble-proposed) [4.1.1+ds2-1]
[01:18] <mwhudson> vorlon: remove fava from release? it is gone from testing and has no rdeps. looks like an upstream update may fix it but well
[01:25] <vorlon> mwhudson: ack
[01:26] <vorlon> mwhudson: fava removed
[01:27] -queuebot:#ubuntu-release- New binary: singularity-container [arm64] (noble-proposed/universe) [4.1.1+ds2-1] (no packageset)
[01:28] -queuebot:#ubuntu-release- New: accepted singularity-container [arm64] (noble-proposed) [4.1.1+ds2-1]
[01:40] -queuebot:#ubuntu-release- New binary: singularity-container [ppc64el] (noble-proposed/universe) [4.1.1+ds2-1] (no packageset)
[01:42] -queuebot:#ubuntu-release- New: accepted singularity-container [ppc64el] (noble-proposed) [4.1.1+ds2-1]
[01:47] <vorlon> gtk4/armhf autopkgtest fails
[01:51] -queuebot:#ubuntu-release- New binary: singularity-container [riscv64] (noble-proposed/universe) [4.1.1+ds2-1] (no packageset)
[02:04] -queuebot:#ubuntu-release- New: accepted singularity-container [riscv64] (noble-proposed) [4.1.1+ds2-1]
[03:05] -queuebot:#ubuntu-release- New binary: ubuntukylin-default-settings [amd64] (noble-proposed/universe) [24.04] (ubuntukylin)
[03:11] -queuebot:#ubuntu-release- New: accepted ubuntukylin-default-settings [amd64] (noble-proposed) [24.04]
[06:12] <vorlon> rolled back gnome-shell to 46.0-0ubuntu2 in -proposed; 46.0-0ubuntu3 is a rebuild against mutter which is otherwise separable from the rest of the transition from what I see
[06:19] <vorlon> only 87  new armhf leaf packages for removal in the lastest notest report
[06:22] <vorlon> and filing bug reports for 8 of those which have new versions built in -proposed but not an armhf
[06:24] <vorlon> oops correction 3 new bug reports
[06:27] <vorlon> glib-networking autopkgtests seem to have a real regression on amd64
[06:38] <vorlon> haha noooo casper has an autopkgtest using losetup
[06:46] <vorlon> 863s  python-flask-restful-doc : Depends: sphinx (= 7.2.6-4)
[06:46] <vorlon> what
[07:56] <vorlon> tsimonq2: lubuntu has neofetch seeded, which recommends jp2a, which ftbfs on all archs in Ubuntu (no reported failure in Debian); so I'm removing it
[07:58] <vorlon> 668s Mar 26 06:54:23 autopkgtest-lxd-xtxlvz nginx[1467]: 2024/03/26 06:54:23 [emerg] 1467#1467: module "/usr/share/nginx/modules/ngx_http_auth_pam_module.so" is not binary compatible in /etc/nginx/modules-enabled/50-mod-http-auth-pam.conf:1
[07:58] <vorlon> ... what do you mean "/usr/share"
[08:12] <juliank> Ah good amd64 queues are going down now, I can see the graph trending down
[08:15] <juliank> But like 2k items / day
[08:16] <juliank> Error rate is down a lot
[08:16] <juliank> Very happy
[08:34] <LocutusOfBorg> athos, I stolen your pacemaker merge. Turned out the FTBFS fix patch coming from Debian was better than mine
[08:34] <LocutusOfBorg> so, I grabbed it and reuploaded
[09:46] <juliank> several tests were inadvertently dropped on non-amd64 architectures, QA has rescheduled python tests for ppc64el and s390x, and scheduling of non-python tests is WIP. These are being queued into huge queue to allow you to do targeted retries of important blockers for the time_t transition, please don't abuse that
[09:46] <juliank> I am watching
[09:55] <adrien> going up the chain of dependencies, I'm going to look at pipewire and slurm-wlm for readline, and ngircd (missing build), libp11, gnutls28 for gnutls28 and for nettle; that's a lot so feel free to pick some of that
[09:56] <adrien> btw, I think diffoscope on armhf is high-reward too
[10:00] -queuebot:#ubuntu-release- New binary: mathgl [riscv64] (noble-proposed/universe) [8.0.1-7.1] (no packageset)
[10:14] <Skia> requeuing of non python tests is done for ppc64el and s390x. Please note that they were requeued without all-proposed, compared to britney asking them **with** all-proposed
[10:20] <juliank> Skia: oh no, I guess I forgot that, that was not intentional
[10:20] <Skia> yeah, and I realized that after it run
[10:21] <juliank> Skia: so without all-proposed they'll fail too much to be useful I suppose
[10:22] <juliank> Skia: I think we ought to purge the huge queues again and redo the same dance with all-proposed
[10:22] <Skia> fine, I'll work on that
[10:22] <juliank> Skia: Sorry
[10:22] <Skia> no prob' :-)
[10:23] <adrien> when doing that, are you also dropping other tests?
[10:23] <adrien> also, if there's a window of opportunity to sneak in tests at the front of the queue, let me know...
[10:24] <adrien> but since you're putting stuff in the huge queue, that's fine actually
[10:25] <juliank> :)
[10:25] <juliank> The good thing is - one can just purge the huge queues and issue RUNNING tests again
[10:25] <juliank> it's not possible to lose tests that way
[10:27] <Skia> python scheduling in progress
[10:32] <juliank> ooh I really need a KPI for size of -proposed
[10:32] <adrien> my rewriter tells me this: Processed 7234 migrations; 2267 issues, 4673 blocked, 294 waiting.
[10:33] <juliank> Now do the past 30 days :)
[10:33] <adrien> my shell scrollback doesn't go back that far :P
[10:33] <juliank> I could actually talk to the snapshot service and figure that out
[10:33] <adrien> and I didn't even add these stats at the beginning of the scrollback ;-)
[10:33] <adrien> but does that look like what you'd be after?
[10:34] <juliank> more than what I'm after
[10:34] <juliank> I was looking for the first number only :D
[10:34] <juliank> but this is more informative
[10:34] <adrien> issues is test issues, blocked is Depends: on "not considered" packages, and 294 is britney attempting migration
[10:36] <adrien> March 22 morning, I had Processed 6842 migrations.
[10:36] <juliank> ok
[10:36] <adrien> and evening: Processed 7256 migrations; 3104 issues, 4005 blocked, 150 waiting.
[10:37] <adrien> 23rd early afternoon I guess: Processed 7258 migrations; 2287 issues, 4773 blocked, 198 waiting.
[10:38] <adrien> and yesterday evening: Processed 7269 migrations; 2210 issues, 4853 blocked, 206 waiting.
[10:42] <Skia> non-python scheduling in progress
[10:48] <juliank> I'm not sure we'll make progress, it seems a lot of tests are just running in the release pocket due to infrastructure issues
[10:49] <juliank> Regardless of any triggers, all-proposed flags, they don't necessarily do anything right now
[11:19] <handsome_feng> Hi, Release team, please approve ukui-settings-daemon, ukui-control-center, ukui-power-manager, ukui-panel, ukui-media, peony from noble proposed. Thanks!
[11:22] <schopin> handsome_feng: the migration is automatic, but currently pretty much all of -proposed is blocked due to the time_t migration. See https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#ukui-settings-daemon
[11:23] <handsome_feng> schopin: Got it, thanks!
[11:32] <schopin> ubuntu-archive: please RM confget, nsca, nsca-client binaries from armhf. confget is blocking perl on armhf (and nsca is its sole relevant rdep)
[11:33] <seb128> schopin, removed
[11:35] <slyon> hey ubuntu-archive! May I ask for armhf binaries of "dante" in Noble? https://bugs.launchpad.net/ubuntu/+source/dante/+bug/2059104
[11:35] -ubottu:#ubuntu-release- Launchpad bug 2059104 in dante (Ubuntu) "Please remove dante armhf binaries from Noble" [Undecided, New]
[11:38] <seb128> slyon, hey, removed
[11:39] <slyon> thanks!
[11:40] <seb128> np!
[11:41] <slyon> seb128: did you leave out dante-client on purpose? I think it should go as well
[11:49] <seb128> slyon, it's an arch all binary
[11:50] <slyon> ah, sure!
[11:50] <slyon> nvm
[11:50] <seb128> :)
[12:02] -queuebot:#ubuntu-release- New: accepted nobodd [source] (noble-proposed) [0.4-0ubuntu1]
[12:04] -queuebot:#ubuntu-release- New binary: nobodd [amd64] (noble-proposed/none) [0.4-0ubuntu1] (no packageset)
[12:07] <juliank> All test results since the 20th outside of armhf are wrong, so we are in the process of sorting this out with QA
[12:08] <juliank> Only armhf was actually using proposed
[12:08] <juliank> Current proposal is to hack up the autopkgtest.db to change their exit code from 0 to 20 (pass to error), deleete britney's cache and have it repopulate it from the db
[12:09] <ahasenack> > All test results since the 20th outside of armhf are wrong
[12:09] <ahasenack> what?
[12:09] <ahasenack> I just connected and don't have chat history
[12:09]  * ahasenack checks irc logs
[12:10] <juliank> ahasenack: This is just my PSA
[12:11] <ahasenack> might be worth an update to https://discourse.ubuntu.com/t/autopkgtest-service/34490/2 when someone has some time
[12:12] <juliank> ahasenack: updated
[12:12] <juliank> ahasenack: a simple case is https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386 which has been passing with a version lower than the trigger since the 19th
[12:12] <juliank> not sure when it really started
[12:13] <juliank> it's possibly it was the 18th after all
[12:13] <ahasenack> oh, I reported that in chat, it was not picking up the right version
[12:13] <juliank> yes and that happens for everything
[12:14] <juliank> and britney can only tell for tested package == trigger
[12:14] <juliank> because then it compares version tested against trigger and sees "old result"
[12:14] <ahasenack> talk about perfect storm
[12:14] <juliank> but e.g. stuff triggered by gnupg that's pass actually just tested gnupg in the release pocket
[12:15] <ahasenack> that happening now
[12:15] <juliank> Workers are off, bug is being fixed
[12:43] <juliank> autopkgtest.db has been updated with no-proposed=1 for hopefully most failures caused by the bug
[12:43] <juliank> I think there were oddly unrelated ones
[12:44] -queuebot:#ubuntu-release- New: accepted nobodd [amd64] (noble-proposed) [0.4-0ubuntu1]
[12:45] <juliank> you can see now for example on https://autopkgtest.ubuntu.com/packages/python-apt/noble/s390x
[12:45] <juliank> tests have no-proposed=1
[12:45] <juliank> and error
[12:45] <juliank> the no-proposed=1 flag has been added to all rewritten results
[12:46] <juliank> but like libvpx has a failure to get the latest version before the designated day and I'm not sure what that is about
[12:47] <juliank> we figured the cut-off day based on mojo run days, those happened 13th and 20th
[12:49] -queuebot:#ubuntu-release- Unapproved: ubuntu-unity-backgrounds (mantic-proposed/universe) [23.10-0ubuntu1 => 24.04-0ubuntu1] (no packageset)
[12:50] -queuebot:#ubuntu-release- Unapproved: sagemath (mantic-proposed/universe) [9.5-6ubuntu0.1 => 9.5-6ubuntu0.1.1] (no packageset)
[12:52] <juliank> sil2100, ubuntu-release: with the database now changed, next step is kill britney, mv autopkgtest-results.cache autopkgtest-results.cache.before-the-fiasko and start it again so it repopulates from fresh database
[12:52] <juliank> And I guess monitoring the output to see if it does any weird shenanigans
[12:53] <sil2100> hm, let me try that
[12:54] <sil2100> Shit, I removed the crontab of archive-toolbox by a typo
[12:55] <adrien> oh, I hadn't read a debian bug report well: plenty of R packages to remove :)
[12:55] <adrien> maintainer had asked for removal of a few packages plus only direct dependencies
[12:56]  * adrien curses at debbugs
[13:02] <juliank> sil2100: oops, I suppose it has a backup?
[13:03] <sil2100> ...
[13:03] <sil2100> I'm afraid only Steve knows
[13:04] <juliank> :(
[13:07] <athos> LocutusOfBorg: Thanks
[13:08] <slyon> ubuntu-archive: please remove the pngphoon leaf binary package on Noble/armhf, it FTBFS (on armhf only), due to time_t
[13:13] <adrien> I'll have close to 30 removal requests; shall I pastebin or launchpad that?
[13:14] <juliank> adrien: just pastebinit first and we can see
[13:18] <adrien> thanks
[13:22] <adrien> what about packages that are architecture: all and have their dependencies removed: do they need to be explicitly removed?
[13:26] <juliank> we cannot remove architecture: all binaries from armhf
[13:26] <juliank> you can only remove them from all architectures
[13:31] <adrien> makes sense; is there anything to do to get these out of the way for tests? there are failed ones for them on armhf
[13:39] <doko> jamespage: python3-os-xenapi needs an update for Python 3.12
[13:51] <adrien> ubuntu-archive: on armhf, please remove r-bioc-bsseq r-bioc-dss r-bioc-demixt ; see https://pastebin.ubuntu.com/p/6vTqmmmghG/ for details
[14:07] <jamespage> doko: looking
[14:15] <jamespage> doko: may be able to RM that - just testing now
[14:21] <mitya57> Please reject ubuntu-unity-backgrounds from mantic queue. I didn't notice wrong series when sponsoring (should have been noble).
[14:25] <fheimes> Hi sru-team (ubuntu-sru), I'm aware that we are currently in soft-freeze, but I would nevertheless kindly ask if an sru team member can have a look at socat in focal's unapproved queue:
[14:25] <fheimes> https://launchpad.net/ubuntu/focal/+queue?queue_state=1&queue_text=socat
[14:25] <fheimes> (since this is related to a customer case). Thank you!
[14:26] <ahasenack> what soft freeze?
[14:30] <fheimes> Well, aren't we usually in a kind of a soft-freeze at the end of a dev cycle that effects and impacts resources on other tasks like SRUs? (that is at least what I had in mind, well, if not, even better ;-) )
[14:30] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-unity-backgrounds [source] (mantic-proposed) [24.04-0ubuntu1]
[14:32] <jamespage> doko: confirmed - os-xenapi can be dropped from the archive as all reverse-depends dropped support for xen some time ago
[14:33] <jamespage> i've uploaded fixes for nova, ceilometer and neutron to drop the dependency
[14:34] <doko> jamespage: ta, and vitrage ...
[14:35] <jamespage> yeah we're working on that at the moment
[14:35] <jamespage> watcher also has woes but not directly 3.12 related
[15:22] <slyon> ubuntu-archive: please remove the ruby-sigar leaf binary package on Noble/armhf, it FTBFS (on armhf only), due to time_t and blocks the libtirpc transition
[15:23] <vorlon> juliank: did https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.with-proposed.txt get updated to include seeded things minus meta?
[15:25] <vorlon> slyon: done, can you file a bug about this and tag it time_t?
[15:27] <vorlon> slyon: pngphoon removed; bug also please
[15:28] <vorlon> adrien: arch: all packages with failed tests, a baseline retry will now also fail due to the missing dep, which gives us a record of the -proposed failure not being a regression
[15:28] <slyon> vorlon:, thanks! sure: https://bugs.launchpad.net/ubuntu/+source/ruby-sigar/+bug/2059137 – I tagged it "time-t" as "time_t" is invalid according to Launchpad
[15:28] -ubottu:#ubuntu-release- Launchpad bug 2059137 in ruby-sigar (Ubuntu) "FTBFS on Noble/armhf, blocking libtirpc time_t transition" [Undecided, Fix Committed]
[15:29] <vorlon> slyon: sorry that's what I meant :)
[15:30] <blackboxsw> bdmurray: please also reject cloud-init 24.1.2 in unapproved queues for Focal, Jammy  and Mantic  looks like we've got one other upload for cloud-init 24.1.3 we'd prefer to get out instead of the unapproved 24.1.2.
[15:30] <vorlon> adrien: ooi how do these r-bioc packages come to be on your radar given that they're not in -proposed?
[15:32] <slyon> https://bugs.launchpad.net/ubuntu/+source/pngphoon/+bug/2059139
[15:32] -ubottu:#ubuntu-release- Launchpad bug 2059139 in pngphoon (Ubuntu) "Please remove pngphoon on Noble/armhf" [Undecided, Fix Committed]
[15:40] <sil2100> juliank: ok, should be happening now (with the cache)
[15:45] <jamespage> doko: bug 2059141
[15:45] -ubottu:#ubuntu-release- Bug 2059141 in python-os-xenapi (Ubuntu) "RM: please remove python-os-xenapi from noble development" [Undecided, New] https://launchpad.net/bugs/2059141
[15:46] <adrien> vorlon: r-bioc-demixt blocks r-base: https://objectstorage.prodstack5.canonical.com/swift/v1/AUTH_0f9aae918d5b4744bf7b827671c86842/autopkgtest-noble/noble/armhf/r/r-bioc-demixt/20240326_093034_23dcd@/log.gz and I missed these in a removal request yesterday for other R packages (I blame debbugs)
[15:46] <vorlon> just isolated a time_t bug in softhsm2 (masked because doko disabled blocking on build-time test failures), last real regression for gnutls28 (seen in the libp11 autopkgtest)
[15:53] <doko> vorlon: "because doko disabled blocking on build-time test failures" ???
[15:53] <vorlon> doko: see the softhsm2 changelog
[15:58] <jamespage> we have quite a few openstack packages blocked on autopkgtests on armhf failure due to install issues - I don't want to double up on any general efforts in this area but is there anything my team should be doing to help in this area?
[16:09] <adrien> juliank: I've added statistics on https://adrien.dcln.fr/misc/update_excuses_2.html ; it's the three counts separately but I haven't yet seen a case where summing them didn't give the total count
[16:10] <enr0n> ubuntu-archive: please rm filament (bug 2059145)
[16:10] -ubottu:#ubuntu-release- Bug 2059145 in filament (Ubuntu) "please remove filament from noble" [Undecided, In Progress] https://launchpad.net/bugs/2059145
[16:11] <vorlon> jamespage: can you point me to a specific package at issue, so I can see exactly which bucket it falls into
[16:12] <vorlon> "only" 2108 binary packages rendered uninstallable on armhf
[16:13] <vorlon> and only one of them a candidate for removal according to https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.with-proposed.txt
[16:13] <juliank> vorlon: since yesterday, I didn't check the section but task == name or "ubuntu-" + task  == name
[16:13] <jamespage> let me pick one from the 198 currently needing attention
[16:14] <juliank> sil2100: you mean, britney is repopulating its cache nwo?
[16:14] <vorlon> juliank: ok. unfortunate!
[16:14] <juliank> vorlon: Should I print a log too of packages that are being kept?
[16:15] <juliank> then I can print their reverse deps in the log
[16:15] <vorlon> juliank: (unfortunate that we don't get more candidates for removal)
[16:15] <juliank> Makes it easier to see if something is wrong somewhere
[16:15] <vorlon> juliank: I'm not going to think about that right now
[16:15] <juliank> I'll just do it
[16:15] <vorlon> juliank: if we break 2000 packages, we break 2000 packages
[16:15] <sil2100> juliank: it should, yes
[16:15] <vorlon> and then we'll have https://ubuntu-archive-team.ubuntu.com/proposed-migration/noble_uninst.txt as our post-beta work list
[16:15] <juliank> yeah 225 MB of logs
[16:15] <juliank> for britney
[16:16] <juliank> so that is good
[16:17] <juliank> My adhoc commandline parsers are killing me
[16:17] <jamespage> vorlon: ignore me my view is out-of-date - the by-team report has not been regenerated since 22nd
[16:23] -queuebot:#ubuntu-release- Unapproved: update-manager (jammy-proposed/main) [1:22.04.19 => 1:22.04.20] (core)
[16:26] -queuebot:#ubuntu-release- Unapproved: update-manager (bionic-proposed/main) [1:18.04.11.23 => 1:18.04.12] (core)
[16:28] -queuebot:#ubuntu-release- Unapproved: update-manager (xenial-proposed/main) [1:16.04.21 => 1:16.04.22] (core)
[16:30] <juliank> vorlon: eek the log is 150MB :D
[16:30] <juliank> I guess it prints every package 8 times
[16:30] <juliank> I'll make it smarter
[16:30] <juliank> Let it only print the first iteration
[16:32] -queuebot:#ubuntu-release- Unapproved: update-manager (focal-proposed/main) [1:20.04.10.20 => 1:20.04.10.21] (core)
[16:34] <cmars> Hey y'all, I just noticed this: http://ftp.ubuntu.com/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/ubuntu/
[16:35] <cmars> symlink gone wild?
[16:35] <cmars> thought you should know, hope you're all doing well. bye now!
[16:40] <doko> athos: please could you have a look at https://launchpad.net/ubuntu/+source/php-parser/5.0.2-2/+build/27898903
[16:42] <juliank> vorlon, sil2100 is britney alive, it hasn't written in 10 minutes, but also not finished?
[16:42] <sil2100> Let me see
[16:43] <sil2100> juliank: the process seems alive
[16:43] <arraybolt3> @room: FYI for those who are interested, we now have an Ubuntu Release room on Matrix. https://matrix.to/#/#release:ubuntu.com IRC bridging isn't active yet, but should be in the relatively near future. We already have a port of Queuebot operating in there (written by Nils Büchner a.k.a. ravage), so you can see archive and ISO activity just like in here.
[16:44] <sil2100> juliank: and at least on the instance I see latest logs for the noble run from 2024-03-26T16:43:43+0000
[16:44] <juliank> ok
[16:45] <juliank> sil2100: I can only look at https://ubuntu-archive-team.ubuntu.com/proposed-migration/log/noble/2024-03-26/  I am not powerful enough
[16:47] <juliank> Oh god I should add another info message to britney
[16:47] <juliank> Because we only log matches pending request or not
[16:48] <juliank> but this run doesn't really have pending requests for all of them I suppose
[16:48] <juliank> but still it will record the test result
[16:48] <juliank> but it doesn't log that it did so :)
[16:50] <juliank> I guess the http log is updated by a 10 minutely cron job
[16:50] <juliank> or 15 minute
[16:52] <schopin> arraybolt3: is the release team in that room?
[16:53] <arraybolt3> schopin: I just created it, so until they join, no
[16:53] <arraybolt3> it's just part of getting the Matrix side of the Ubuntu community up-and-running.
[16:53] <arraybolt3> once IRC bridging is on, then everyone will be there.
[16:54] <vorlon> jamespage: ah indeed - I don't know why that's out of date
[16:55] <juliank> britney is requesting a bunch of migration-refernce/0
[16:56] <juliank> amd64: 515
[16:56] <juliank> i386: 45
[16:56] <juliank> ppc64el: 349
[16:56] <juliank> s390x: 633
[16:56] <juliank> armhf: 0
[16:56] <juliank> arm64: 301
[16:56] <juliank> so far
[16:56] <juliank> Only 5 each that are not migration-reference
[16:59] <juliank> I just realized my queued branch is stupid, it iterates the entire queue each time when it wants to send a request. I should just visit the queues at the start and build a dict to then do O(1) lookup for each test I want to send
[16:59] <juliank> Again linear complexity vs more or less quadratic
[17:01] <vorlon> heh we probably want to go through `reverse-depends src:faketime -a source
[17:01] <vorlon> dgit autopkgtest fails because of it. I was just looking at osslsigncode build failure, and find it's on this list.
[17:05] <juliank> keep faketime rdeps=['epoptes', 'src:altos', 'src:debian-reference', 'src:devscripts', 'src:dkim-rotate', 'src:doxygen', 'src:fastdds', 'src:festival', 'src:genometools', 'src:jags', 'src:katarakt', 'src:libgfshare', 'src:macaulay2', 'src:mbedtls', 'src:mcabber', 'src:moon-buggy', 'src:oath-toolkit', 'src:ocl-icd', 'src:osslsigncode', 'src:pandas', 'src:postsrsd', 'src:pyacidobasic',
[17:05] <juliank> 'src:pyscanfcs', 'src:rauc', 'src:reprotest', 'src:sssd', 'src:sympy', 'src:x4d-icons'] may_remove=True
[17:05] <juliank> I wonder if reverse-depends agrees
[17:06] <juliank> probably no fancy provides on there
[17:07] <xypron> Please, drop package licheerv-rtl8723ds-dkms from the 24.04/noble archive. It is not needed anymore. LP #2059151
[17:07] -ubottu:#ubuntu-release- Launchpad bug 2059151 in licheerv-rtl8723ds-dkms (Ubuntu) "Drop package licheerv-rtl8723ds-dkms from 24.04 (Noble)" [Undecided, New] https://launchpad.net/bugs/2059151
[17:08] <juliank> (from the new "keep" log file https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.with-proposed.log)
[17:09] <juliank> (which is not regularly updated but a poc more or less)
[17:10] <juliank> I guess I could make my report a json file and you can query it with jq nicely
[17:11] <juliank> "15MB JSON file as an API"
[17:16] <juliank> vorlon: I guess packages in release pocket that *do not have a version in proposed* could become uninstallable as well, so joining uninstallables with the unfiltered report https://magenta.jak-linux.org/ubuntu-archive/distcheck/noble.armhf/removal-candidates.txt may prove useful?
[17:17] <juliank> or will it always report the package migrating as the uninstallability
[17:27] <doko> why do we have a two year old nvidia-settings package in noble?
[17:27] <juliank> for shits and giggles?
[17:28] <doko> apw: ^^^
[17:28] <apw> doko, good question... will pass that on ...
[17:30] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (mantic-proposed) [24.1.2-0ubuntu1~23.10.1]
[17:31] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (focal-proposed) [24.1.2-0ubuntu1~20.04.1]
[17:31] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (jammy-proposed) [24.1.2-0ubuntu1~22.04.1]
[17:53] <doko> seb128: are there any plans for GTK2 removals, like in Debian?
[17:55] <athos> doko: Yes (looking into php-parser)
[18:01] <seb128> doko, not at the moment, at least it's not something we have been actively looking at
[18:16] <vorlon> juliank: packages in release pocket that do not have a version in proposed are either not candidates for removal because they are *transitively* uninstallable, or they *should* have versions in -proposed.
[18:17] <juliank> Hmm, I agree about the should but I'm not sure they necessarily all do
[18:19] <vorlon> juliank: my point is they should get uploaded to -proposed and then they move to the other list
[18:20] <juliank> But can we find them?
[18:20] <vorlon> if you care to
[18:20] <vorlon> it's not the priority today
[18:20] <vorlon> today the priority is: work through the set of packages that are included in the glib2.0 autohint on https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_output_notest.txt and analyze test failures to make them candidates for real
[18:21] <juliank> ooh britney finished
[18:22] <juliank> vorlon: I'm sure it looks much worse now?
[18:22] <vorlon> what do you mean?
[18:22] <juliank> Waiting for a lot more tests than before we dropped broken passes
[18:22] <vorlon> shrug
[18:23] <juliank> perl looks nice
[18:23] <vorlon> at this point, missing amd64 test results are to be ignored, armhf regressions are to be analyzed
[18:23] <vorlon> i386 regressions are to be yeeted
[18:26] <adrien> so much red
[18:26] <juliank> We dropped 2k tests on ppc64el 30 mins ago, why?
[18:29] <juliank> adrien: So I don't know why that is, it shouldn't treat 'error' as a regression, that's an infrastructure issue?
[18:29] <juliank> Well ok maybe it does
[18:30] <juliank> So we see red but we just tested the wrong version
[18:31] <juliank> This isn't optimal
[18:32] <juliank> Should we consider exit codes 16 (tmpfail) and 20 (error) as regressions? I don't know
[18:32] <vorlon> red means someone needs to manually retry it
[18:32] <juliank> I feel like they should probably be neutral?
[18:32] <vorlon> if the infra isn't going to retry it on its own then this is correct
[18:32] <vorlon> neutral means it does not block migration
[18:33] <juliank> ok?
[18:33] <vorlon> an infra failure is a regression vs a pass!
[18:33] <vorlon> and should not be ignored
[18:34] <juliank> status: amd64: 2206 i386: 78 ppc64el: 1771 s390x: 2199 armhf: 230 arm64: 1913
[18:34] <juliank> #regressions
[18:35] <vorlon> is that the total number of i386 regressions? If so I should retry them all
[18:36] <juliank> vorlon: Normally that is all correct but now it makes it useless we don't see what we tested wrongly vs what actually failed, so we can't dig into the latter failures, and we don't have time for the former
[18:36] <juliank> vorlon: yes it is
[18:36] <vorlon> juliank: uh no we just retry all of them, shrug
[18:37] <juliank> But we need to migrate them before we have the retries done
[18:37] <vorlon> yes
[18:37] <vorlon> we're NOT going to zero the amd64 test queue before tht
[18:37] <vorlon> it's just not possible
[18:38] <juliank> hence why I said if we can see *real regressions* vs our messup, we'd have a better view of what is broken prior to migrating it
[18:38] <vorlon> if you can get the messups moved to 'Test in progress' fine
[18:38] <juliank> If we just ignore the test results, we should cancel them all, and just do migration-reference/0 for everything after migration, and then we can build a migration-reference/0 dashboard
[18:38] <vorlon> but the existing failures shouldn't be treated as neutral
[18:39] <vorlon> we should cancel them all>
[18:39] <vorlon> no
[18:39] <juliank> like nobody is going to see their results if they run after migration
[18:40] <juliank> Due to all-proposed the data quality is subpar too
[18:40] <juliank> queueing migration-reference/0 after migration will have better quality as you have a consistent set
[18:41] <vorlon> let the queues run
[18:41] <vorlon> I'm not going to engage this conversation further, it's a distraction from actually working on analyzing regressions
[18:45] <adrien> juliank: ah, makes sense; in any case it's clearly not differentiating
[18:46] <juliank> adrien: There's nothing we can do anymore, on import every result became PASS/NEUTRAL/FAIL :(
[18:47] <juliank> adrien: But we need to make sure to rerun them all, or run migration-reference/0 after migration on everything to ensure that future -proposed tests don't become "not a regression"
[18:47] <juliank> Because with everything red now due to messup, none of these will be regressions when we force migrated them and they get a new update
[18:48] <juliank> and like I said I prefer after the migration event to cancel the outstanding all-proposed tests and reschedule migration-reference/0 for everything to get an accurate gauge
[18:48] <juliank> or what is actually in the release pocket
[18:48] <vorlon> ok cancelling them AFTER the migration is fine
[18:49] <vorlon> I thought you meant to cancel them now :)
[18:49] <juliank> i don't give a duck now
[18:51] <vorlon> openssl failures analyzed, unblocking
[18:51] <vorlon> at last look that's the last transitive blocker for glib2.0; so britney runs are going to get slower now
[18:52] <vorlon> for a while
[18:52] <juliank> sad britney
[18:52] <vorlon> slower because they're going to have to report on a lot more uninstallables
[18:53] <juliank> vorlon: have you scheduled i386, or should I? I have the list and can just pipe
[18:53] <juliank> it
[18:53] <vorlon> juliank: I had scheduled for openssl only
[18:53] <vorlon> juliank: please go ahead
[18:53] <juliank> on it
[18:54] <juliank> funnily britney also scheduled migration-reference/0 tests for all our messup regressions of course
[18:54] <juliank> i386 retried.
[18:55] <juliank> the migration-reference are not a big issue tbh at least ppc64el and s390x are almost done with them
[18:56] <vorlon> analyzing gtk+3.0 now
[19:01] <vorlon> gtk+3.0 good, unblocking
[19:04] <vorlon> analyzing at-spi2-core
[19:05] <vorlon> at-spi2-core good
[19:07] <vorlon> analyzing cups
[19:12] <vorlon> cups analyzed, unblocking
[19:13] <vorlon> that should be the glib2.0 + gtk2.0 stack unblocked, now the excitement begins
[19:13]  * juliank is more scared than excited
[19:14] <vorlon> the scary part comes tomorrow; this is just making britney output more interesting in the meantime
[19:14] <juliank> vorlon: deadline is EOyourD tomorrow?
[19:14] <juliank> :D
[19:14] <vorlon> yes
[19:15] <vorlon> https://autopkgtest.ubuntu.com/packages/m/mumble/noble/armhf is interesting
[19:15] <vorlon> oh
[19:15] <vorlon> taking qtbase-opensource-src for analysis
[19:15] <vorlon> mumble ^ so basically the package installation never completes? therefore gets marked as badpkg
[19:15] <vorlon> will try to reproduce
[19:15] <juliank> I feel like it crashes somewhere?
[19:16] <juliank> It doesn't hang certainly
[19:16] <juliank> Maybe dpkg segfaults
[19:16] <vorlon> the error says 'context deadline exceeded'
[19:17] <juliank> Yes for the dpkg-query analysis
[19:17] <vorlon> quickly trying to reproduce
[19:17] <vorlon> ah
[19:17] <juliank> But there's no time gap from where it stops installing to where it tries to analyse what is wrong
[19:18] <juliank> ok there is a 20s one
[19:18] <vorlon> well dpkg itself succeeds
[19:18] <juliank> This tampermonkey script from QA folks adds line numbers and it confused me :D
[19:18] <vorlon> confirmed locally
[19:18] <juliank> "context deadline exceeded" is a Go error string, no?
[19:19] <juliank> wth
[19:19] <juliank> And reverse-depends doesn't work for src:mumble
[19:19] <juliank> it has no output
[19:19] <vorlon> fwiw mumble autopkgtest has been failing on armhf since 1.5.517-1
[19:20] <vorlon> so, not a time_t thing and I'm ignoring
[19:20] <vorlon> the binaries are in your removal list
[19:20] <juliank> ah yes
[19:20] <juliank> kill it
[19:20] <juliank> or let it migrate
[19:20] <juliank> i don't care :D
[19:20] <vorlon> not migrate
[19:21] <vorlon> the one in -proposed is broken on ALL archs
[19:21] <vorlon> so killing the binaries
[19:21] <juliank> ack
[19:21] <juliank> I think we just didn't test the other arches
[19:21] <juliank> the
[19:21] <juliank> these are all the infra messup regressions
[19:22] <vorlon> juliank: yeah but there are failure logs on those archs from -1 as well
[19:22] <vorlon> unblocking qtbase-opensource-src
[19:23] <vorlon> taking libpng1.6
[19:23] <juliank> ah yes I see 215s /tmp/autopkgtest.m5y5yl/build.WmN/src/debian/tests/smoke: 41: Syntax error: end of file unexpected (expecting ")")
[19:23] <juliank> breakage
[19:23] <vorlon> libpng1.6 good, unblocking
[19:25] <vorlon> right, afk for food
[19:26] <vorlon> fwiw we have a report pending on the release team side to identify the set of packages that need this kind of analysis and I'm happy to have the analysis delegated to non-release-team members (the actual hinting being releaseteamonly)
[19:40] <vorlon> taking pipewire
[19:43] <vorlon> pipewire good
[19:43] <ahasenack> vorlon: when you say "unblocking <pkg>", what exactly do you mean?
[19:43] <vorlon> taking libcanberra
[19:44] <vorlon> ahasenack: adding a 'force-skiptest' hint to lp:~ubuntu-release/britney/+git/hints-ubuntu so that it will be considered in spite of incomplete or failing test results
[19:44] <vorlon> libcanberra good
[19:44] <vorlon> taking readline
[19:48] <adrien> what are you looking at? just trying to understand better because I saw hundreds of (mis-)reported regressions so that's a lot to go through and you're pretty quick
[19:49] <vorlon> adrien: https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#readline only has 2 :)
[19:49] <vorlon> and danilogondolfo already filed a bug about the one that matters
[19:50] <vorlon> adrien: so far, I am looking at all of the regressions listed for any arch, and quickly pattern-matching on them to see if those particular regressions should be ignored
[19:50] <vorlon> or if bugs need reported
[19:50] <vorlon> (readline good)
[19:50] <vorlon> adrien: if amd64 is "failed" but it's clearly an installability issue, ignore
[19:51] <vorlon> adrien: if i386 is "failed" take a quick look but ultimately it's going to be ignored anyway
[19:51] <vorlon> if armhf, dig in and see if it matches an issue I already know; and if bugs need filed to track the issue after migration
[19:51] <vorlon> if failed on all archs, standard +1 maintenance triage
[19:52] <adrien> thanks; one thing: excuses for readline /had/ two but now there are all the cancelled ones reported too (maybe better don't refresh the page yet :D )
[19:53] <vorlon> and if the cause is mutter, ignore because mutter has a transition staged in -proposed that is not included in the current migration so it's going to be an uninstallable mess
[19:53] <vorlon> adrien: oh lol ok
[19:53] <vorlon> adrien: yes I won't refresh for a while then :D
[19:53] <vorlon> gnome-desktop good
[19:54] <vorlon> the old reports *are* still published, we could work off a previous one for a while
[19:54] <vorlon> taking gst-plugins-good1.0
[19:54] <vorlon> sorry, I mean gst-plugins-base1.0
[19:58] <vorlon> anyway, the risk of real regressions on !armhf directly as a result of time_t is approximately nil, so it's not super important that I review all of the amd64 autopkgtest failures
[20:00] <vorlon> there are some substantive changes with new upstream versions of some libraries (gnome stack), but it's very unlikely these would regress on amd64 but not arm64 (can't rely on ppc64el + s390x because they don't ship a full desktop)
[20:06] <adrien> thanks for all the details, and btw: how do we know there are ongoing transitions? are they recorded somewhere central? I wasn't aware for mutter for example (and that would have been useful)
[20:07] <vorlon> adrien: it was discussed here
[20:07] <vorlon> not otherwise documented
[20:07] <vorlon> no good place to
[20:08] <tsimonq2> vorlon: jp2a> ack, fix coming to archive today, we do need that.
[20:08] <vorlon> here's the list of packages that need analysis of test failures: https://paste.ubuntu.com/p/49cbkr9C3V/
[20:08] <vorlon> tsimonq2: cheers
[20:08] <adrien> ok, hadn't seen it (many IM channels don't help me backlog :'( )
[20:08] <vorlon> so now working these alphabetically
[20:08] <vorlon> taking 389-ds-base
[20:09] <vorlon> oh wait I should finish gst-plugins-base1.0 first
[20:09] <vorlon> 389-ds-base push back :P
[20:11] <tsimonq2> ubuntu-release: https://code.launchpad.net/~arraybolt3/debian-cd/+git/debian-cd/+merge/463159 hi, can this be merged? Ubuntu Unity has no references in debian-cd thus preventing Plymouth from loading.
[20:12] <tsimonq2> ubuntu-release: Also, I plan on merging and uploading this in the next few hours unless there are objections, in light of the busyness with time_t. https://code.launchpad.net/~arraybolt3/casper/+git/casper/+merge/463157
[20:15] <vorlon> gst-plugins-base1.0 good
[20:16] <vorlon> *now* taking 389-ds-base
[20:19] <vorlon> 389-ds-base good
[20:29] <vorlon> taking aac-tactics
[20:29] <vorlon> retrying tests for aac-tactics
[20:34] <vorlon> not hinting aac-tactics for now, moving on
[20:34] <vorlon> taking abseil
[20:35] <adrien> I queued a bunch of coq retries on ppc64el and s390x (I can't tell anymore which failures there were)
[20:35] <vorlon> adrien: thanks :)
[20:37]  * adrien is team OCaml (but that doesn't really help understand coq :P )
[20:38] <vorlon> hinting abseil
[20:38] <vorlon> taking accountsservice
[20:44] <vorlon> hinting accountsservice
[20:46] <vorlon> taking adsys
[20:47] <vorlon> adsys waiting for test results on all archs except armhf where it passes, heh
[20:47] <vorlon> hinting adsys
[20:47] <vorlon> taking aegean
[20:47] <vorlon> hinting aegean
[20:47] <bdmurray> taking aerc
[20:48] <vpa1977> looking at bppsuite (armhf)
[20:48] <vorlon> vpa1977: are you working from this list? https://paste.ubuntu.com/p/49cbkr9C3V/
[20:49] <vpa1977> update-excuses ... will switch to the list
[20:49] <vorlon> vpa1977: you're not because bppsuite isn't on it :-) please work from this list
[20:49] <vorlon> taking afflib
[20:49] <vpa1977> ack =)
[20:49] <vpa1977> looking at aflplusplus
[20:49] <vorlon> hinting afflib
[20:50] <vorlon> taking afterstep
[20:50] <bdmurray> vorlon: so aerc passed on armhf, ppc64el and s390x but is waiting for amd64 and arm64 ... so it could be hinted ocrrect?
[20:50] <vorlon> bdmurray: yes I would hint it
[20:51] <vorlon> hinting afterstep
[20:51] <vpa1977> aflplusplus - has tests queued up, so skipping for now ?
[20:51] <vorlon> taking agenda.app
[20:51] <vorlon> vpa1977: let me see
[20:52] <vorlon> vpa1977: it has one pass on armhf for its autopkgtests, which is good enough for me given that this is a no-change rebuild *for* armhf
[20:53] <vorlon> vpa1977: and for ocaml-afl-persistent, the failures on !armhf are all testbed failures so don't count, and we have a pass on armhf - so I will hint this
[20:53] <bdmurray> vorlon: I'm not seeing your hint changes
[20:53] <vorlon> bdmurray: I'm batching them, do you want a commit per hint?
[20:53] <vorlon> pushed
[20:54] <vorlon> hinting agenda.app
[20:54] <vorlon> I noticed for ocaml-afl-persistent that not all archs showed queued retests, only amd64
[20:54] <bdmurray> vorlon: well, I wanted to add one for aerc. Should I just tell you
[20:55] <vorlon> bdmurray: please go ahead and add
[20:55] <vpa1977> looking at android-platform-frameworks-base
[20:55] <vorlon> bdmurray: using git for merging as necessary, is more efficient than having me be a bottleneck for all commits
[20:56] <vorlon> taking alberta
[20:56] <vorlon> (on mooseback)
[20:56] <vpa1977> android-platform-frameworks-base blocked by diffoscope blocked by wabt which fails to build on all arches
[20:57] <bdmurray> taking allelecount
[20:57] <vorlon> vpa1977: well, one way or another we have to decide how we are going to handle this for the migration
[20:58] <vorlon> vpa1977: options are: a) file bugs and hint, b) remove failing packages in a way that stops them from sneaking back into release pocket, c) remove this package and all its revdeps
[20:58] <vpa1977> it looks like the ftbfs is caused by a difference in clang toolchain - an option our clang does not recognise
[20:58] <vpa1977> I can fix it
[21:01] <vorlon> but we don't have time to fix them all before tomorrow
[21:03] <vorlon> vpa1977: my analysis is: diffoscope/armhf has some passing tests; the test requiring recommends: to be installable is blocked by an issue not in this package; good enough
[21:03] <ahasenack> what happens tomorrow?
[21:04] <vorlon> ahasenack: we unblock the hairball so that we can have a valid beta, regardless of how much armhf we break
[21:04] <vpa1977> vorlon: so I file a bug to remove wabt from proposed and we can resolve the build issue later
[21:04] <vorlon> vpa1977: wabt doesn't need removed from proposed
[21:05] <vorlon> vpa1977: what I can do is remove wabt/armhf binary from the release pocket
[21:05] <vorlon> which is not critical path for tomorrow, but DOES reduce by 1 our count of broken packages on armhf afterwards
[21:05] <vpa1977> vorlon: It is fine in noble, just the latest -proposed version failed to build
[21:05] <vorlon> vpa1977: it's not fine on noble, it has the old ABI and will be uninstallable when libssl migrates
[21:06] <vpa1977> ah true, sorry
[21:06] <vorlon> punting the removal for now though because it has a revdep
[21:07] <vpa1977> looking at android-platform-tools
[21:07] <vorlon> vpa1977: so, hinting android-platform-frameworks-base
[21:07] <vpa1977> yes
[21:07] <dbungert> ansifilter
[21:09] <vorlon> alsa-utils
[21:10] <vorlon> uh what is happening here, it's ftbfs on all archs in -proposed but in the list of packages in the transition
[21:10] <vorlon> ... and shows no test failures of course...
[21:11] <vpa1977> android-platform-tools: has tests queued, armhf passes, the package is no change-rebuild since debian. Hint?
[21:11] <vorlon> vpa1977: yes, thanks
[21:11] <vpa1977> looking at aom
[21:13] <vorlon> hum alsa-utils seems to somehow be in update_excuses.yaml but not yet visible to me on update_excuses.html, probably a proxy cache thing
[21:13] <bdmurray> taking apache2 (he said in a frightened voice)
[21:13] <vorlon> so punting that for now
[21:14] <vorlon> taking android-platform-art
[21:14] <mwhudson> vorlon: i am now at your service
[21:14] <vorlon> mwhudson: take a package from https://paste.ubuntu.com/p/49cbkr9C3V/ ? next is apparmor
[21:15] <mwhudson> ok apparmor for me
[21:15] <vorlon> mwhudson: then look at https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html#$package at the reported autopkgtest regressions
[21:15] <mwhudson> .oO(can i game my progress to not get openssl)
[21:15] <vorlon> mwhudson: then identify any that are real regressions, or real reasons to want to wait for more autopkgtest results
[21:15] <dbungert> ansifilter has a forensicsics-extra test queued that probably will pass?  so that's a hint then?
[21:15] <vorlon> mwhudson: file bugs for the real regressions so we don't lose track, and then ask a release team member to hint
[21:16] <vpa1977> aom - self armhf passes, ffmpeg queued and librust-aom-sys-dev is uninstallable. rust-aom-sys needs no-change rebuild
[21:16] <vorlon> dbungert: why do you say it will probably pass if we've had no successful tests on armhf?
[21:16] <vorlon> dbungert: (so for me this would be 'skip and come back later')
[21:17] <dbungert> k
[21:18] <mwhudson> vorlon: so apparmor tests failed with infra errors and are queued to run again, that's "skip and come back later"?
[21:18] <vorlon> mwhudson: for the package in question are there any passes? what's the status of armhf?
[21:19] <dbungert> appstream
[21:19] <bdmurray> vorlon: so looking at apache2 there is a lot going on there. But I could skip test sub items like ikiwiki-hosting?
[21:19] <mwhudson> vorlon: no not of the version in proposed. armhf passed
[21:19] <vorlon> bdmurray: skiptest applies to apache's migration; to ignore failure of a particular test is badtest which is a bigger hammer
[21:20] <vorlon> 906s fatal: unable to access 'https://gitlab.com/fdroid/ci-test-app.git/': Failed to connect to gitlab.com port 443 after 133803 ms: Couldn't connect to server
[21:20] <vorlon> c'mon, man
[21:21] <vpa1977> aom - mistaken about librust-aom-sys-dev, that was a broken testbed (apt)
[21:21] <bdmurray> okay so looking at ikiwiki-hosting update_excuses say amd64 and arm64 are running but I don't see amd64 in the queue any more. Is it worth requeueing?
[21:22] <vpa1977> aom - skip until ffmpeg test succeeds
[21:22] <mwhudson> i am extremely confused by https://autopkgtest.ubuntu.com/packages/c/content-hub/noble/amd64 -- all the recent runs are reported as "error" but looking at the logs i don't see the problem?
[21:22] <vorlon> mwhudson: britney is failing to show it, but https://autopkgtest.ubuntu.com/packages/a/apparmor says armhf passed and https://autopkgtest.ubuntu.com/packages/a/apparmor/noble/armhf confirms?
[21:22] <vpa1977> mwhudson: they have tagged runs that ran with wrong dependencies as no-proposed/error
[21:22] <bdmurray> mwhudson: that's what we talked about in stand up
[21:22] -queuebot:#ubuntu-release- New binary: jp2a [amd64] (noble-proposed/universe) [1.1.1-2ubuntu1] (lubuntu, ubuntu-mate)
[21:22] -queuebot:#ubuntu-release- New binary: jp2a [s390x] (noble-proposed/universe) [1.1.1-2ubuntu1] (lubuntu, ubuntu-mate)
[21:23] <mwhudson> bdmurray, vpa1977: ah
[21:23] <vorlon> mwhudson: note that these tests are tagged 'error' rather than 'failed'
[21:23] <mwhudson> sorry for not paying attention!
[21:23] <vpa1977> do we have a way to mark packages to "come-back-later" somewhere ?
[21:23] <vorlon> taking apt
[21:23] <juliank> mwhudson: you can see trigger is  content-hub/1.1.1-1build3 but result version is 1.1.1-1
[21:23] -queuebot:#ubuntu-release- New binary: jp2a [arm64] (noble-proposed/universe) [1.1.1-2ubuntu1] (lubuntu, ubuntu-mate)
[21:23] -queuebot:#ubuntu-release- New binary: jp2a [ppc64el] (noble-proposed/universe) [1.1.1-2ubuntu1] (lubuntu, ubuntu-mate)
[21:23] <juliank> I retried the apt block fwiw
[21:24] <arraybolt3> new jp2a binaries are from me fixing the FTBFS failure on all arches
[21:24] <vorlon> vpa1977: "come back later" - if we actually make it all the way through the list, then we can generate a fresh list
[21:24] <juliank> vorlon: I saw odd rule extract failures for apt but I think they're sorted out now
[21:24] <vpa1977> vorlon: ack
[21:24] <vpa1977> taking apache2
[21:24] -queuebot:#ubuntu-release- New binary: jp2a [armhf] (noble-proposed/universe) [1.1.1-2ubuntu1] (lubuntu, ubuntu-mate)
[21:25] <mwhudson> vpa1977: brian took that?
[21:25] <vpa1977> ops, my bad
[21:26] <bdmurray> vpa1977: feel free I'm still working with bos01
[21:26] <vorlon> and it would be REALLY NICE if britney didn't sometimes just RANDOMLY decide to not show the passing tests on one arch
[21:26] <juliank> vorlon: notably, aptitude/0.8.13-5ubuntu4 apt/2.7.14 now passed on ppc64el and s390x retries, and on other architectures with random triggers, which is the first time 2.7.14 passed
[21:26] <vpa1977> mwhudson, bdmurray: ack
[21:26] <mwhudson> +1 vorlon
[21:26] <vorlon> juliank: ack
[21:27] <bdmurray> vpa1977: I mean please take apache2 if it wasn't clear
[21:27] <vpa1977> bdmurray: yes, looking at it
[21:28] <juliank> FWIW, I have identified 2 more bugs with proposed handling, but one only affects apt < 2.0 (binaries with a version different from source package are not pinned correctly, lolz) and the other is meaningless right now (package from release pocket remains installable even if removed in proposed trigger upload)
[21:28] <juliank> Upstream has approved my merge for the 2nd case
[21:28] <vorlon> why does ca-certificates-java need a test called 'can-configure-cross-compilation'!
[21:28] <juliank> heh
[21:29] <juliank> A good question for our Java maintainer
[21:29] <vorlon> I don't want to highlight him and distract him from the actual work ;)
[21:29] <vpa1977> it failed before =)
[21:29] <vpa1977> I will find bug for that in a second
[21:29] <mwhudson> so for apparmor i see no evidence of regression but given the nature of things it would definitely be good to see some more passes...
[21:30] <juliank> mwhudson: s390x and ppc64el are free (well 2 pending), so go nuts there?
[21:30] <juliank> I say free, I ignore the huge queue :)
[21:31] <sil2100> I'll take graphicsmagick if no one took it yet
[21:31] <juliank> That's specifically why I had the tests scheduled in huge so you can take your concerns and resolve them :)
[21:31] <juliank> I'll go disappear again, I'm still recovering from the last couple nights being too long! Good hunting!
[21:31] <sil2100> juliank: o/
[21:32] <vpa1977> vorlon: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043247
[21:32] -ubottu:#ubuntu-release- Debian bug 1043247 in openjdk-21-jdk-headless,ca-certificates-java "openjdk-21-jdk-headless fails foreign installation during ca-certificates-java.postinst" [Normal, Fixed]
[21:32] <vpa1977> when you co-install foreign-arch jdk and native jdk, ca-certificates-java should use native jdk
[21:32] <vorlon> vpa1977: heh. well that test is failing on amd64 with new apt and I'm not blocking on it
[21:34] <vpa1977> vorlon: ah the test is using mmdebstrap which can not setup chroot properly for the test. I will file time-t bug for it
[21:34] <vorlon> bdrung: fwiw devscripts autopkgtest appears to have regressed and it's not the archive's doing
[21:40] <dbungert> ignoring appstream, regressions all look like retest bait (queued) and are non-armhf
[21:40] <dbungert> assuming aptitude entangled with apt, looking at arpack
[21:40] <vorlon> dbungert: aptitude may be entangled with apt but needs hinted separately ftr
[21:40] <vorlon> it's fine for you to pick whatever
[21:40] <dbungert> k
[21:40] <vorlon> we just don't want to collide
[21:42] <vorlon> dbungert: and I'm hinting appstream, none of the failures there are a) anything that points to an armhf regression and b) applying to all archs suggesting there may be a real bug
[21:42] <dbungert> ack
[21:43] -queuebot:#ubuntu-release- New binary: jp2a [riscv64] (noble-proposed/universe) [1.1.1-2ubuntu1] (lubuntu, ubuntu-mate)
[21:49] <vorlon> taking aptitude
[21:49] -queuebot:#ubuntu-release- New: accepted jp2a [amd64] (noble-proposed) [1.1.1-2ubuntu1]
[21:49] -queuebot:#ubuntu-release- New: accepted jp2a [armhf] (noble-proposed) [1.1.1-2ubuntu1]
[21:49] -queuebot:#ubuntu-release- New: accepted jp2a [riscv64] (noble-proposed) [1.1.1-2ubuntu1]
[21:49] -queuebot:#ubuntu-release- New: accepted jp2a [arm64] (noble-proposed) [1.1.1-2ubuntu1]
[21:49] -queuebot:#ubuntu-release- New: accepted jp2a [s390x] (noble-proposed) [1.1.1-2ubuntu1]
[21:49] -queuebot:#ubuntu-release- New: accepted jp2a [ppc64el] (noble-proposed) [1.1.1-2ubuntu1]
[21:49] <mwhudson> ok queued a couple of apparmor tests, onto arpack
[21:49] <vorlon> hinting aptitude
[21:49] <vorlon> taking arqiver
[21:50] <mwhudson> 154s cp: cannot stat '/usr/share/apbs/{tests,examples}': No such file or directory
[21:50] <mwhudson> lol what are you doing
[21:50] <vorlon> and please highlight whenever you want me to add a hint
[21:50] <vorlon> mwhudson: bashisms ftw
[21:50] <bdmurray> arqiver loooked like a regression on armhf
[21:50] <dbungert> mwhudson: imported a bug for that
[21:51] <arraybolt3> mwhudson: I just had jp2a act almost exactly like that, ended up being a build environment difference where the presence of a package caused some files to be saved into other directories than normal
[21:51] <mwhudson> dbungert: oh didn't see your claim
[21:51] <dbungert> no worries
[21:51] <mwhudson> looking at assimp
[21:51] <vorlon> bdmurray: arqiver is just the forensics-extra nonsense that's been requeued?
[21:51] <bdmurray> if only we were using gobby
[21:52] <bdmurray> vorlon: agreed
[21:52] <vorlon> taking astc-encoder
[21:52] <bdmurray> I just noticed we lost some armhf workers too so I'm looking at that
[21:52] <dbungert> yes, arpack is just a regression from unrelated LP: #2059164
[21:52] -ubottu:#ubuntu-release- Launchpad bug 2059164 in apbs (Debian) "apbs: autopkgtest regression: apbs_tester.py': [Errno 2] No such file or directory" [Undecided, New] https://launchpad.net/bugs/2059164
[21:53] <bdmurray> bos01 seems better though
[21:53] <dbungert> asterisk
[21:53] <vorlon> dbungert: so I should hint arpack?
[21:53] <dbungert> vorlon: please
[21:53] <vorlon> done thanks
[21:53] <vorlon> astrometry.net
[21:54] <vorlon> astropy
[21:54] <vorlon> definitely some armhf regressions here
[21:54] <vorlon> priming yeet slingshot
[21:58] <dbungert> 1:20.6.0~dfsg+~cs6.13.40431414-2build3 is a version number all right
[22:00] <mwhudson> vorlon: what was the occt nonsense about in the end?
[22:01] <vorlon> mwhudson: "ok so the issue comes down to the opencascade libraries which would be newly NBS after migration also being uninstallable because of a strict versioned dep on occt-misc.  so in the short term I'll just remove these binaries from the release pocket increasing uninstallability count"
[22:02] <dbungert> vorlon: please hint asterisk for non-armhf test failures unrelated to time_t with queued tests
[22:03] <vorlon> uh blocking pytest rather than skiptesting
[22:03] <dbungert> asymptote
[22:03] <vorlon> (explicitly blocking so someone doesn't accidentally hint it in)
[22:04] <vorlon> dbungert: done thanks
[22:05] <vorlon> pytest in -proposed being incompatible with the world is not helpful
[22:06] <mwhudson> vorlon: i think assimp can be hinted
[22:06] <vorlon> mwhudson: done thanks
[22:06] <mwhudson> atop
[22:07] <vorlon> augustus
[22:08] <mwhudson> vorlon: hint atop pls
[22:08] <vorlon> mwhudson: done
[22:09] <mwhudson> at-spi2-core (oh no)
[22:09] <vorlon> mwhudson: already hinted
[22:09] <mwhudson> oh ok!
[22:09] <mwhudson> autofs
[22:09] <vorlon> mwhudson: (race condition between me having hand-picked it for analysis, and generation of the report)
[22:10] <vorlon> avahi
[22:11] <dbungert> vorlon: please hint asymptote for same reasons
[22:11] <dbungert> avogadrolibs
[22:11] <vorlon> 'comitup' no you misspelled 'vomit' I know the keys are right next to each other hth
[22:11] <vorlon> dbungert: done
[22:15] <vpa1977> apache2 - needs retrying autopkgtests. ./retry-autopkgtest gives 121 urls. Can i submit ?
[22:16] <vorlon> vpa1977: you can
[22:16] <mwhudson> vorlon: hint autofs pls
[22:16] <mwhudson> taking awesome
[22:17] <vorlon> mwhudson: autofs done
[22:17] <vorlon> ayatana-indicator-session
[22:18] <vorlon> babeltrace (nooooo)
[22:19] <vorlon> bacula
[22:19] <vorlon> balsa
[22:20] <vorlon> bamtools
[22:20] <vpa1977> apache2 - requeued tests, skipping
[22:20] <vorlon> vpa1977: are the tests armhf?
[22:21] <vpa1977> vorlon: they include armhf, but the failures are due to the dependency bug
[22:22] <sil2100> Taking graphviz
[22:22] <vpa1977> taking bandage
[22:22] <mwhudson> vorlon: hint awesome
[22:23] <dbungert> vorlon: please hint avogadrolibs
[22:23] <vorlon> blocking bamtools
[22:23] <mwhudson> taking bc
[22:24] <dbungert> bcftools
[22:24] <mwhudson> vorlon: why block bamtools, out of curiosity?
[22:24] <vorlon> mwhudson: it's 101 days old and was hitching a ride on the glib2.0 migration but is not needed or appropriate
[22:24] <vorlon> (s390x regression)
[22:25] <mwhudson> vorlon: fair enough
[22:25] <vorlon> mwhudson, dbungert: awesome and avogadrolibs done
[22:25] <vorlon> mwhudson: and block >> skiptest
[22:25] <vorlon> bear
[22:26] <vorlon> berkeley-express
[22:26] <mwhudson> vorlon: i see you retried eztrace/armhf a bunch. any insights you remember?
[22:26] <vorlon> mwhudson: that'll have been part of some batch, I don't recognize it
[22:26] <mwhudson> fair
[22:27] <mwhudson> uhh dgit failure looks like faketime non-working-ness?
[22:27] <vorlon> yeah faketime is death and ignore it
[22:27] <vpa1977> vorlon: bandage - has miniaamd64 regression due to dependency issue  - retried, depends on qtbase-opensource-src (that has regressions), but package itself installs on armhf from proposed. Hint?
[22:27] <mwhudson> vorlon: badtest dgit/armhf then?
[22:28] <vorlon> mwhudson: maybe worth familiarizing yourself with output of `reverse-depends src:faketime -a source` for the duration
[22:28] <vorlon> mwhudson: I don't like using badtest, and we might fix faketime next week or something
[22:28] <vpa1977> taking bind9
[22:29] <mwhudson> vorlon: is there a reverse-depends for d/tests/control?
[22:29] <vorlon> vpa1977: yes, the 'regression' is simply a bad test
[22:29] <vorlon> mwhudson: yes, -a source shows it
[22:29] <mwhudson> vorlon: ah nice
[22:29] <vorlon> vpa1977: bandage hinted
[22:31] <sil2100> Ok, graphviz has a lot of tests that still are queued, will move on for now to others
[22:31] <vorlon> well, berkeley-express has no passing tests, but its test deps aren't satisfied on armhf and it's a no-change rebuild so hinting
[22:32] <vorlon> sil2100: did you see the master list? (from paride) https://paste.ubuntu.com/p/49cbkr9C3V/
[22:32] <sil2100> vorlon: yes, working from that one
[22:32] <vpa1977> bind9 - has tests queued, skipping
[22:32] <vorlon> sil2100: helpful if you also go alphabetically, so that we can more easily skip the ones one another have claimed
[22:32] <mwhudson> vorlon: hint bc, something odd is going on with eztrace but it's not bc's fault
[22:32] <vpa1977> bind-dyndb-ldap - same, tight dependency on bind9
[22:33] <sil2100> vorlon: ACK, started from the middle not to get in anyone's way, but if we all coordinate here then it should work
[22:33] <mwhudson> lol do i get binutils
[22:33] <sil2100> Taking binwalk o/
[22:33] <mwhudson> vorlon: did you do binutils already by any chance?
[22:33] <vorlon> mwhudson: I did not
[22:33] <vpa1977> taking biometryd
[22:34] <vorlon> vpa1977: "has tests queued" is to me not a skip; hinting bind9
[22:34] <vorlon> vpa1977: (only armhf test there that's not a pass is forensics-extra which is a known issue)
[22:35] <vorlon> biosig
[22:36] <vorlon> bobcat goldthwaite
[22:36] <vpa1977> vorlon: bind-dyndb-ldap - armhf passes, should probably hint to if we hint bind9
[22:36] <vorlon> vpa1977: ack thanks
[22:36] <vorlon> bobcat eeeewww all read
[22:36] <vorlon> *red
[22:36] <mwhudson> oh i bootstrapped bobcat, only reason i've heard of it
[22:37] <vorlon> mwhudson: familiar enough with it to have an opinion on https://autopkgtest.ubuntu.com/packages/f/flexc++/noble/armhf ?
[22:37] <dbungert> vorlon: please hint bcftools
[22:37] <vorlon> dbungert: done
[22:37] <mwhudson> vorlon: heck no
[22:38] <dbungert> sigh boost
[22:38] <dbungert> boost1.74 specifically
[22:39] <liushuyu> Hi ubuntu-release, can someone help me understand if https://bugs.launchpad.net/ubuntu/+source/rustc/+bug/2052985 this FFe needs revising?
[22:39] -ubottu:#ubuntu-release- Launchpad bug 2052985 in rustc (Ubuntu) "[FFe] Upgrade Rust to 1.76.0" [Medium, Incomplete]
[22:39] <vorlon> mwhudson: icmake autopkgtest ALSO dumps core, looks like this wants kicking out of the release pocket
[22:39] <vpa1977> biometryd - blocked on elfutils (already hinted?), tests for lomiri-settings-components pass/requeued. hint?
[22:39] <mwhudson> vorlon: fair enough
[22:39] <vorlon> at least on armhf
[22:40] <mwhudson> vorlon: it has a bit of an rdep chain iirc
[22:40] <vorlon> yeah but it needs doing
[22:40] <vpa1977> taking booth
[22:41] <sil2100> Taking bpfcc now
[22:42] <vpa1977> booth - armhf passes, amd64 requeued, package installable on armhf. hint ?
[22:43] <vorlon> vpa1977: yes done thanks
[22:43] <vpa1977> taking brasero
[22:45] <liushuyu> taking ibus
[22:46] <vorlon> fyi when we get there, cups has just had a new upload fixing a real bug impacting cups-browsed.  hopefully this will build quickly on riscv64 but in the meantime skip it
[22:46] <sil2100> bpfcc I need to wait for some reruns to finish since I don't have reliable info from the current tests, moving on
[22:46] <vorlon> liushuyu: please join us in the 'b' section, if people jump around it will be hard later to keep track of what's already done
[22:46] <dbungert> vorlon: please hint boost1.74
[22:46] <vorlon> liushuyu: regardless of your personal interest in ibus ;)
[22:46] <liushuyu> vorlon: okay
[22:46] <vorlon> dbungert: done
[22:47] <dbungert> taking brlaser
[22:47] <sil2100> Taking brotli
[22:47] <sil2100> eh, brotli still has a lot of tests in progress, skipping
[22:48] <sil2100> Taking budgie-desktop
[22:48] <vpa1977> brasero - package installable on armhf, requeued tests for dependencies. skipping
[22:48] <vpa1977> (all test failed)
[22:48] <vpa1977> taking bustle
[22:48] <sil2100> budgie-desktop - the same, skipping
[22:49] <sil2100> Taking ekhm, butt
[22:50] <vorlon> 'ssh-cron' clearly this is an implementation of the ssh protocol over cronjobs
[22:51] <sil2100> Ok, butt is still running tests but it generally looks green on all others
[22:52] <sil2100> Taking c2esp
[22:52] <vorlon> mwhudson: oh I see bobcat bootstrapping requires icmake which is one of the very packages which fails, um
[22:52] <mwhudson> vorlon: yes
[22:52] <vorlon> mwhudson: I guess I'll leave icmake/armhf in the release pocket for now and make it uninstallable
[22:53] <vorlon> mwhudson: is icmake a poor reinvention of xmkmf?
[22:53] <mwhudson> vorlon: i have no idea
[22:53] <vorlon> then I assert that it is
[22:53] <vorlon> "Originally, it was written to provide a useful tool for  automatic program maintenance and system administrative tasks on MS-DOS platforms."
[22:54] <vorlon> what are you even DOING
[22:54] <mwhudson> vorlon: these are good questions
[22:54] <vorlon> sil2100: c2esp: note there's an open update-excuses bug on this
[22:54] <vorlon> cairo
[22:56] <sil2100> vorlon: oh, I don't see that on update_excuses
[22:57] <vorlon> sil2100: update_excuses is a bit out of date...
[22:58] <vpa1977> bustle - depends on libpcap, which needs tests queued. dependency tests (dbus-test-runner) pass. Package installable on armhf. Hint ?
[22:58] <sil2100> Okay, moving on then, since I'd like the test results for the actual package we have in -proposed
[22:59] <vorlon> vpa1977: not necessary to mention armhf installability, fwiw
[22:59] <vorlon> vpa1977: but yes hinting
[23:01] <sil2100> hum, so cups 2.4.7-1.2ubuntu2 is not yet published huh
[23:01] <vpa1977> libpcap retry-autopkgtest-regression returns 81 urls. Should I queue ?
[23:01] <mwhudson> vorlon: ok binutils is waiting on lots of tests but i see no evidence of regression and the diff between release and proposed looks pretty innocuous, hint pls
[23:01] <liushuyu> taking black
[23:01] <vorlon> juliank, bdmurray: based on discussions I would have expected to see a requeued test for https://autopkgtest.ubuntu.com/packages/g/gnome-shell-pomodoro/noble/amd64 but there wasn't one (now queuing)
[23:01] <sil2100> I'll revisit and queue tests when ubuntu2 is available in -proposed
[23:01] <vorlon> mwhudson: done
[23:01] <liushuyu> re-queued autopkgtests for black
[23:01] <mwhudson> liushuyu: black isn't on the list?
[23:02] <mwhudson> which is here https://paste.ubuntu.com/p/49cbkr9C3V/
[23:02] <sil2100> Taking calf
[23:02] <mwhudson> taking cassiopee
[23:02] <liushuyu> taking castle-game-engine
[23:04] <vpa1977> taking ccls
[23:04] <mwhudson> vorlon: hint cassiopee pls
[23:04] <vorlon> mwhudson: done
[23:05] <mwhudson> taking cdebconf ... :(
[23:05] <sil2100> calf skiptested, moving on
[23:05] <liushuyu> castle-game-engine tests re-queued, the tests could pass
[23:05] <liushuyu> taking cdebootstrap
[23:05] <sil2100> Taking cdo
[23:05] <liushuyu> (hmm)
[23:06] <mwhudson> liushuyu: i was going to but ...
[23:06] <mwhudson> vorlon: cdebconf is waiting on a million tests but has several passes on armhf and the change is a no-change rebuild -- hint?
[23:06] <vorlon> yeah
[23:06] <vorlon> done
[23:07] <sil2100> Okay, cdo FTBFS on many arches, taking a quick look
[23:07] <vorlon> (we should remove cdebconf anyway really)
[23:07] <mwhudson> vorlon: how do you feel about cdebootstrap!!
[23:07] <mwhudson> taking cdeboostrap btw
[23:07] <vpa1977> ccls -all tests in progress, had a failure on vim-youcomplete, skipping (?)
[23:07] <vorlon> haha
[23:08] <dbungert> skipping brlaser due to cups relation
[23:08] <vpa1977> (afk blood test)
[23:08] <dbungert> taking cdrkit
[23:09] <liushuyu> cdebootstrap tests requeued
[23:09] <vorlon> poppler seems to have regressed i386 testability, shrug
[23:09] <liushuyu> cdebootstrap vs xen-tools might need attention
[23:10] <liushuyu> taking ceph
[23:10] <mwhudson> liushuyu: i bet xen-tools is deb822 soources
[23:10] <liushuyu> ceph might need hinting: itself passed, blocked by google-perftools oath-toolkit openssl python3.12
[23:10] <liushuyu> mwhudson: correct
[23:12] <vorlon> liushuyu: hi, let me repost something I said earlier before you came in, to make sure we're all on the same page wrt priorities
[23:12] <vorlon> one way or another we have to decide how we are going to handle this for th
[23:12] <vorlon> one way or another we have to decide how we are going to handle [each of these packages] for the migration [tomorrow]
[23:13] <vorlon> options are: a) file bugs and hint, b) remove failing packages in a way that stops them from sneaking back into release pocket, c) remove this package and all its revdeps
[23:14] <vorlon> liushuyu: ^^ requeuing tests is fine, but that's also something we can do as a batch across all packages.  The priority is figuring out the course of action for the package wrt armhf and letting it migrate tomorrow
[23:14] <vorlon> 4) if there are test failures showing it's broken on !armhf, we should block the package and remove armhf binaries
[23:14] <vorlon> but we should NOT assume that we will get a second pass at the list
[23:14] <liushuyu> Okay, so if the tests have a high-probability of passing (the tests passed but overriden to error) choose (a)?
[23:15] <vorlon> liushuyu: yes please
[23:15] <liushuyu> Understood
[23:15] <vorlon> liushuyu: to be clear, "tests passed but overridden to error" means it was never a valid test at all.  but if the test passed on another arch, then that's usually enough reason to skiptest
[23:15] <liushuyu> Okay
[23:16] <mwhudson> vorlon: hint cdeboostrap please, xen-tools tests are busted but cdeboostrap seems to be ok
[23:17] <vorlon> mwhudson: I see you spell it the same way I do
[23:17] <vorlon> mwhudson: cdeboo[t]strap hinted
[23:17] <mwhudson> vorlon: heh upils does it too
[23:18] <mwhudson> taking cfitsio
[23:19] <vorlon> taking certmonger
[23:20] <vorlon> taking cgal
[23:20] <sil2100> eh, cdo FTBFS for arm64, ppc64el and riscv64 because it depends (implicitly it seems) on a new magics++ which also fails on those architectures
[23:21] <vorlon> sil2100: cdo only has amd64 binaries in the release pocket
[23:21] <sil2100> vorlon: hm, no, it has arm64, ppc64el and riscv64 according to launchapd. Did someone remove the others?
[23:22] <sil2100> https://launchpad.net/ubuntu/+source/cdo/2.3.0-1
[23:22] <vorlon> sil2100: they were *built* but they have since been removed
[23:22] <vorlon> sil2100: that shows you that they were built not that they were currently published; cf. rmadison
[23:22] <sil2100> vorlon: ...my bad!
[23:22]  * sil2100 trusted too much in webbrowser
[23:22] <vorlon> kids these days
[23:23] <liushuyu> castle-game-engine: needs hinting (passed on other arch)
[23:23] <vorlon> liushuyu: done
[23:23] <mwhudson> vorlon: hint cfitsio, passes on enough arches to be ok
[23:24] <liushuyu> also I should file an accompanying bug on LP with time-t tag?
[23:24] <mwhudson> taking chatty
[23:24] <sil2100> Taking chealpix
[23:24] <vorlon> liushuyu: for what issue?
[23:24] <liushuyu> vorlon: for hinting? a) file bugs and hint > this one?
[23:25] <vorlon> liushuyu: sorry - that's meant to be, file bugs for any regressions that we are ignoring to let this package in
[23:25] <liushuyu> vorlon: Ah, okay. I misunderstood something you said in the standup
[23:26] <mwhudson> vorlon: hint chatty, autopkgtest is trivial anyway
[23:26] <liushuyu> taking "cheese"
[23:26] <vorlon> mwhudson: done
[23:26] <mwhudson> taking c-icap-modules
[23:27] <vorlon> hinting cgal, but I'm not happy about it
[23:27] <sil2100> Taking cinnamon
[23:27] <vorlon> (1 armhf pass, 1 ppc64el pass, 1 s390x pass, 1 armhf failure due to tests and a whole bunch of invalid)
[23:28] <mwhudson> vorlon: hint c-icap-modules, no change rebuild and passes on armhf
[23:28] <vorlon> mwhudson: done
[23:28] <mwhudson> cinnamon-control-center
[23:28] <vorlon> cinnamon-desktop
[23:28] <mwhudson> vorlon: hint cinnamon-control-center
[23:29] <mwhudson> cinnamon-menus
[23:29] <vorlon> mwhudson: done
[23:29] <vorlon> cinnamon-session
[23:30] <mwhudson> vorlon: hint cinnamon-menus
[23:30] <vorlon> mwhudson: done
[23:30] <liushuyu> "cheese" tested incorrect package version and currently in-queue for testing
[23:30] <mwhudson> cinnamon-settings-daemon
[23:30] <vorlon> liushuyu: were there any passing tests on other archs, and is it ok on armhf?
[23:30] <vorlon> cjs
[23:31] <liushuyu> vorlon: no, should test cheese/44.1-1build3 but tested cheese/44.1-1 on all arch
[23:31] <vorlon> liushuyu: oh but it did pass on armhf. 'No test results' is britney speak for a 'neutral' test
[23:31] <vorlon> liushuyu: so I'll hint it
[23:31] <liushuyu> vorlon: thanks!
[23:32] <liushuyu> taking clamav
[23:32] <vorlon> claws-mail
[23:32] <sil2100> Ok, cinnamon hinted, moving on
[23:33] <sil2100> Taking clazy
[23:33] <vorlon> click
[23:33] <liushuyu> clamav needs hinting, tests passed on !amd64 (failed on amd64 due to c-icap-mod-urlcheck)
[23:33] <dbungert> so diffoscope vs cdrkit failed for libssl3 installability, I'm thinking we need to come back to that one
[23:34] <vorlon> dbungert: we've been ignoring diffoscope
[23:34] <mwhudson> vorlon: hint cinnamon-settings-daemon
[23:34] <dbungert> k
[23:34] <liushuyu> taking cloudflare-ddns
[23:34] <mwhudson> taking cluster-glue
[23:34] <liushuyu> cloudflare-ddns is safe to hint
[23:35] <mwhudson> vorlon: hint cluster-glue
[23:35] <mwhudson> (it's nice to get easy ones)
[23:35] <mwhudson> taking clutter-gst-3.0
[23:35] <sil2100> Taking cmake
[23:35] <liushuyu> taking cockpit
[23:35] <mwhudson> sil2100: commiserations
[23:35] <sil2100> ummm
[23:35] <vorlon> dbungert: I actually don't know how https://autopkgtest.ubuntu.com/packages/d/diffoscope/noble/ppc64el passed given that pytest breaks things in -proposed and blocks the armhf test
[23:36] <sil2100> Maybe I'll take ekhm, something else
[23:36] <vorlon> mwhudson: c-s-d and cluster-glue done
[23:36] <sil2100> cmake is SO MUCH in progress
[23:36] <liushuyu> vorlon: cockpit is safe to hint
[23:36] <dbungert> taking coin3
[23:36] <sil2100> Taking coinor-ipopt
[23:37] <liushuyu> taking colord
[23:37] <vorlon> oh click again meh
[23:37] <mwhudson> vorlon: hint clutter-gst
[23:37] <vorlon> mwhudson: done
[23:38] <mwhudson> taking compiz
[23:38] <vorlon> blocking click
[23:39] <mwhudson>   * Apply patches from debian/patches since this is not a 3.0 (quilt) package
[23:39] <mwhudson> best changelog
[23:40] <vorlon> liushuyu: please highlight be my name when you want a hint added (almost missed cloudflare-ddns)
[23:40] <liushuyu> vorlon: okay, will do
[23:40] <vorlon> liushuyu: cockpit hinted
[23:40] <liushuyu> vorlon: colord needs hinting
[23:41] <vorlon> liushuyu: colord done
[23:41] <liushuyu> taking conky
[23:41] <vorlon> taking conmon
[23:42] <sil2100> Taking content-hub
[23:42] <liushuyu> vorlon: conky needs hinting (passed on armhf, error on others)
[23:42] <vorlon> coq
[23:42] <vorlon> liushuyu: done
[23:43] <vorlon> uh maybe just let me work coq*
[23:43] <liushuyu> so skip the coq-* cluster?
[23:43] <vorlon> yeah
[23:43] <liushuyu> taking coquelicot
[23:43] <mwhudson> vorlon: did sssd get removed on armhf?
[23:43] <vorlon> because honestly if they're installable then they're good
[23:43] <vorlon> mwhudson: ask rmadison, I can't remember if it made it out
[23:44] <mwhudson> fair enough
[23:44] <vorlon> mwhudson: I remember I *worked* on removing it :)
[23:44] <liushuyu> Okay coquelicot is also a coq package
[23:45] <vorlon> yes
[23:45] <mwhudson> yeah ok it's gone
[23:45] <liushuyu> vorlon: can I give coquelicot to you?
[23:45] <vorlon> liushuyu: yes
[23:45] <mwhudson> vorlon: hint compiz then
[23:45] <vorlon> mwhudson: done
[23:45] <liushuyu> taking coreutils
[23:45] <mwhudson> taking corosync
[23:46] <cpete> I'm here for the fun. Taking courier-authlib
[23:47] <vorlon> cpete: thanks! have you been following along enough to get the flow?
[23:47] <liushuyu> vorlon: coreutils needs hinting (many tests were overriden to error, but the rest is good)
[23:47] <mwhudson> vorlon: hint corosync
[23:48] <mwhudson> talking cowsql
[23:48] <vorlon> liushuyu, mwhudson: done
[23:48] <vorlon> cpdb-backend-cups, my old nemesis
[23:49] <dbungert> vorlon: please hint coin3
[23:49] <liushuyu> cpete: tl;dr: > options are: a) hint if the tests could pass; file a bug if a real regression, b) remove failing packages in a way that stops them from sneaking back into release pocket, c) remove this package and all its revdeps
[23:49] <vorlon> dbungert: done
[23:49] <mwhudson> vorlon: hint cowsql
[23:49] <mwhudson> taking a break for a bit
[23:49] <dbungert> cpdb-libs
[23:49] <mwhudson> (lunch and some other bits)
[23:50] <liushuyu> taking cpl
[23:51] <vorlon> cpl-plugin-amber
[23:52] <cpete> vorlon: I think so? Just read through the logs but might take me a couple to get going. ex. courier-authlib is broken on !armhf, so you could you block it + remove the armhf binaries?
[23:52] <cpete> liushuyu: thanks! Saves me the scrolling haha
[23:52] <vorlon> cpete: broken, or has test failures reported due to the infra stuff?
[23:52] <vorlon> cpl-plugin-giraf
[23:52] <vorlon> cpl-plugin-uves
[23:52] <vorlon> cpl-plugin-vimos
[23:52] <vorlon> cpl-plugin-xshoo
[23:52]  * cpete checking
[23:53] <sil2100> Taking crac (not literally)
[23:53] <vorlon> cpete: do they actually show as failures for you? the one in my browser (after a refresh) says Test in progress
[23:54] <cpete> vorlon: looks like infra
[23:54] <vorlon> cpete: ok - so this we want to hint
[23:54] <vorlon> cpete: (done)
[23:54] <cpete> Ack, thanks!
[23:54] <vorlon> taking createrepo-c
[23:54] <cpete> taking cryptsetup
[23:55] <liushuyu> vorlon: no valid tests result (all errors) for cpl, I am unsure if we should hint this one
[23:55] <vorlon> skipping cups as mentioned ^
[23:55] <dbungert> vorlon: please hint cpdb-libs
[23:55] <vorlon> liushuyu: do https://autopkgtest.ubuntu.com/packages/e/esorex/noble/armhf and https://autopkgtest.ubuntu.com/packages/p/python-cpl/noble/armhf not show for you on update_excuses?
[23:55] <vorlon> dbungert: done
[23:56] <vorlon> liushuyu: also, britney is failing to provide a link to https://autopkgtest.ubuntu.com/packages/c/cpl-plugin-giraf/noble/armhf but it's a pass
[23:57] <liushuyu> vorlon: They do show in the page, but none of the non-error tests seem to test cpl/7.3.2+ds-1build2
[23:58] <sil2100> Taking cura-engine
[23:58] <vorlon> liushuyu: I see references to that version on https://autopkgtest.ubuntu.com/packages/p/python-cpl/noble/armhf and https://autopkgtest.ubuntu.com/packages/e/esorex/noble/armhf
[23:58] <dbungert> taking cypari2
[23:58] <vorlon> liushuyu: also if it's 'all-proposed' we know that it's (supposed to have) taken the version of cpl from -proposed
[23:58] <liushuyu> vorlon: ah, okay, then let's hint that
[23:58] <vorlon> liushuyu: done
[23:59] <liushuyu> taking cyrus-imapd