On Sun, Aug 4, 2024 at 10:27 PM Jeremy Bícha <jeremy.bi...@canonical.com> wrote:
> That is not the actual contents of the .deb. Download the .deb and > open it in file-roller or something to check for yourself. Or look at > the build log. > > https://buildd.debian.org/status/package.php?p=rust-async-broadcast > > Some Rust autopkgtests take a very long time to complete which is > especially noticeable on riscv64 which I think may be the slowest > autopkgtest infrastructure. > > Some rust autopkgtests have additional trouble because > 1. No riscv64 packages are in Testing yet > 2. The Debian Rust team sets skip-not-installable by default. That > means the migration-reference autopkgtest will always show as neutral > since the dependencies are uninstallable when migration-reference is > the only trigger. I think skip-not-installable by default is bad for > other reasons but I think this situation makes it worse. > > See for instance > https://ci.debian.net/packages/r/rust-gtk4/testing/riscv64/ which > passes once in a while. But I don't believe riscv64 is delaying the > rust-zbus transition. > Is that the same reason why we see https://ci.debian.net/packages/r/rust-async-broadcast/testing/riscv64/ being retried over and over again without progress? In contrast to the rust-gtk5/testing/risc64 example, in rust-async-broadcast/testing/riscv64 failures have logfiles that indicate that the actual tests don't even run, still it is being counted as a failure. Also, looking at the description of "skip-not-installable": This restrictions may cause a test to miss a regression due to installability issues, so use with caution. If one only wants to skip certain architectures, use the ``Architecture`` field for that. This test might have test dependencies that can't be fulfilled in all suites or in derivatives. Therefore, when apt-get installs the test dependencies, it will fail. Don't treat this as a test failure, but instead treat it as if the test was skipped. I need some help to understand how skipped tests lead to delaying the package migration to testing. My naive understanding is that this flag would rather allow issues to go through to testing? Changing that would be a one-liner to https://salsa.debian.org/rust-team/debcargo/-/blob/master/src/debian/control.rs?ref_type=heads#L149, but before proposing that, I'd need to understand your concern better. My question is basically: what needs to be done so that https://tracker.debian.org/pkg/rust-event-listener can actually migrate testing? -- regards, Reinhard