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

Reply via email to