[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#1077958: nmu: rust-async-broadcast_0.7.1-1





On Sun, Aug 4, 2024 at 10:27 PM Jeremy Bícha <jeremy.bicha@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

Reply to: