On Mon, 5 Aug 2024 12:57:27 +0100 Peter Green
<plugwash-urg...@p10link.net> wrote:
> > 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.
>
Converting the librust-* packages to arch:all is wrong anyway since this
can break crosscompling in some cases, but that's only part of the
problem here.
From #debian-release:
"jochensp werdahias: rust-async-channel breaks
rust-async-executor/1.12.0-3 and rust-mpris-server/0.7.0-1 and probably
more, if I get it right"
rust-libseccomp migrated but rust-async-broadcast can't migrate due to
rust-event-listener which seems to be missing a B+R.
best,
werdahias
