+1 maintenance report

[Robie Basak]

I was surprised to see Vladimir's report since I didn't know that there
was another person also assigned the same week and we hadn't
communicated. But fortunately it looks like we haven't collided with
each other.

Handover notes:

I think the rust-gix cluster can be resolved by focusing on excuses for
rust-cookie and rust-cookie-store.

Running notes:

find-proposed-cluster gave me:

rust-gix 16
linux-restricted-modules 5
libgnatcoll-db 4
rust-pprof 3
rust-prometheus-client 3

Starting with rust-gix lead me to rust-gix-hashtable -> rust-hashbrown
-> rust-dashmap. Passed on amd64 but failed on other archs. I see in
some previous failures:

301s   = note: aarch64-linux-gnu-gcc: fatal error: environment variable
'DPKG_BUILDPACKAGE_PACKAGE_ARCH' not defined

So is this something to do with the recent changes to dpkg regarding
metadata in ELF binaries? The dates of the failures don't make it
obvious that a retry has been attempted after the most recent fixes, for
example dpkg 1.22.6ubuntu14 was prepared on 21 June and landed 30 June
and that's after the most recent dep8 failures for rust-dashmap on
arm64. Reproducing locally would be on amd64 so another complicating
factor. Easiest to retry on arm64 and I see the queues currently have
availability. Retry submitted. This promptly failed with a different
error also seen before, but those parameters didn't actually lead to the
DPKG_BUILDPACKAGE_PACKAGE_ARCH error from before. So retried again with
all-proposed=1 as liushuyu-011 had tried previously, but hopefully the
newer dpkg will help now. Indeed it passed, so that suggests any
failures of this class can be retried effectively. Ran through
retry-autopkgtest-regressions. Most of these succeeded. rust-rowan/s390x
failed with "erroneous package: rules extract failed with exit code 1"
which is puzzling. Tried another retry for that. This succeeded.

rust-hashbrown is now a valid candidate but makes a bunch of packages
uninstallable on arm64. For example librust-indexmap-dev depends on
librust-hashbrown-0.12+raw-dev but now librust-hashbrown-dev provides
librust-hashbrown-0.14.5+raw-dev instead. Digging into this far more
deeply, I found that rust-gvdb needs a rebuild to depend on the newest
librust-quick-xml-dev instead and uploaded a no change rebuild. This
took quite a bit of time to figure out, but it's starting to feel like a
common pattern "what needs rebuilding to make these uninstallable
package installable again"? Some heuristics might be need to
appropriately guess how dependencies will change following a rebuild,
but that doesn't seem insurmountable to have some rules that will work
in most cases. Is there such a tool? Is anyone planning on writing one?

While we're waiting to see if that worked, I looked at the next cluster,
libgnatcoll-db. Looks like work on this is in progress. Thanks Simon,
and to Jeremy for linking the bug which made it easy for me to see that
it's already being worked on.

Looking at further rust issues, rust-chrono seems blocked on some
regressions in dep8 for rust-schemars and rust-serde-with. It looks like
some test runs at least are running out of disk space now, so I prepared
and submitted a merge proposal for these to be added to the big_packages
list.

11/7 1315: Launchpad is taking >30 seconds to load pages and sometimes
timing out, making it difficult to make any progress.

rust-ashpd depwait -> rust-zbus depwait -> rust-zvariant specifically
librust-zvariant-3+enumflags2-dev (>= 3.15.0-~~) previously synced from
experimental version 4.0.0-1 provides librust-zvariant-4+enumflags2-dev.
Looks like there were a bunch of things synced from experimental in late
February that are now causing hold ups because other depending packages
have autosynced and still require an older version. Looks like this is
likely to shake itself out in time as packages are published into
unstable in Debian, so it's perhaps not worth chasing this further
without something we need that is being blocked by it.

packages.debian.org is also timing out now.

Back to rust-gix, migrating rust-hashbrown et al will cause
librust-cookie-store-dev to become uninstallable because it depends on
an older version of librust-indexmap-dev. Looks like rust-cookie and
rust-cookie-store need fixing as part of this cluster but they are held
up by dep8 failures. rust-reqwest looks like it has never passed.
Previously people have tried migration-reference/0 for them, but these
return neutral because of a dependency issue. I think this needs badtest
hinting.