On Sat, May 16, 2026 at 06:08:13PM +0200, Paul Gevers wrote:
> Source: python-ase
> Version: 3.26.0-3
> Severity: serious
> User: [email protected]
> Usertags: flaky
> 
> Dear maintainer(s),
> 
> I looked at the results of the autopkgtest of your package. I noticed that
> it regularly fails. To check I scheduled 10 tests on ppc64el and 2 out of
> those failed. The failure happens on other architecture too though.
> 
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.

I see that the error happens while building the package on ppc64el.

Strangely, all tests pass, but the test runner (pytest) exits with
error because of a resource cleanup issue after the tests finish.

There is a new upstream release in salsa, but not uploaded yet, so
maybe we should try that before addressing the build failures on ppc64el.

Cc: Andrius who prepared such new upstream.


Related to this, I have a question for Paul:

We currently build Arch:all packages in amd64 autobuilders, and
because of that, some people downgrade bugs about "Package foo which
is Arch:all FTBFS on arm64".

I think that's contrary to the DFSG and therefore wrong (if we require
that package in stable must be buildable in stable, we should also
require that packages in arm64 should be buildable in arm64).

However, this bug that you reported now means in practice that this
package, which is Arch:all like many python packages, is actually
required to be buildable on ppc64el.

So, the question: How far are we from actually requiring Arch:all
packages (not just by debian policy, but by release policy) to be
buildable on all architectures on which they are supported, or at
least on the same architectures where autopkgtests regressions are RC,
like (if I remember well) arm64?

I think that would be an important and necessary step towards DFSG
compliance.

Thanks.

Reply via email to