That's why the test timeout on riscv64 is double that of other architectures:

Unfortunately in many cases, the performance difference seems a lot more
than a factor of two.

Take rust-gix for example, looking at the results for testing migration
tests I see

18-28m on amd64
53-59m on arm64
33-47m on armel
33-48m on armhf
1h59m-2h2m on i386
49m-1h37m on ppc64el
23m-55m on s390x

on riscv64 it was timing out after over 8 hours. To unblock things I modified it
to only test a single feature configuration. It then passed in 29 minuites.

If we assume all feature configurations take the same time (very rough) then
that suggests running the full set of tests on riscv64 would take of the order
of 23 hours. Over 10 times worse than the next-slowest architecture.

So this hints at missing *versioned* dependencies.

It seems to me that britney's autopkgtest scheduler sometimes fails to pick
up that stuff needs to go in together. Even though the main part of britney
knows that they do.

The end result of this is frequently that the fallback dependency solver
gets triggered and autopkgtest tries to run the tests from testing against
the package from unstable. This often results in a "crate directory not
found" error. In other cases the fallback depsolver is not invoked or
doesn't succeed and the testsuite fails with a "fail badpkg" error.

Why this is happening I'm not entirely sure. Though I have some theories

In some cases I suspect it happens because the dependencies are indirect.
or even involve going down the tree and back up again.

In some cases I suspect it happens because riscv64 testing is currently
a basket case, so the packages are already uninstallable in testing.

In some cases I suspect it happens due to the special treatment of arch
all packages (rust team packages are arch any, but Jonas's packages
are arch all). For example if we look at the migration page for
rust-event-listener, it seems britney has done the right thing on amd64
and arm64 (where arch all packages are required to be installable) but
not done the right thing on architectures where arch all packages are
not required to be installable.

Reply via email to