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. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
