[Debichem-devel] Bug#1136861: python-ase: flaky autopkgtest: Exception ignored while calling deallocator

[Paul Gevers]

Hi Santiago,

On 6/14/26 13:45, Santiago Vila wrote:
> 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".


Some source packages that build arch:all binaries (or even arch:any 
binaries) lack Build-Depends on some architectures [1]. Some arch:all 
binaries can't be installed on architectures [2]. Some arch:any packages 
FTBFS on architectures where all their B-D are available. Should all 
those cases be RC too in your book? If not, why special case arch:all? I 
think that having some package not build-able is unfortunately on some 
architecture, but more or less in line with what we have to accept on 
those other fronts. Also, do you have a proposal what maintainers should 
do in those cases (assuming they can't find a solution to get it to 
build)? Add a fake B-D that can't be fullfilled on those architectures 
just to document the fact? Would that fix your RC bug? What if later it 
starts to work (maybe they were toolchain issues), we'd then never know. 
I think adding such a fake B-D is worse than filing a bug report and 
leaving it open. (Not hiding problems, but I can see how maintainers 
choose to spend their time elsewhere. Pinging the porters is of course 
great).

[1] https://qa.debian.org/dose/debcheck/src_testing_main/
[2] https://qa.debian.org/dose/debcheck/testing_main/

> 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).


See below on the DFSG, but otherwise I agree. (But I don't see a 
practical way out here, so let's file the bugs but not at RC level).

> 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.


No. Because it can mark the test to be skipped on ppc64el, we even have 
a field for that: "Architecture: !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 hope I answered above, I think it's not the right tradeoff at this moment.

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

I miss a point here I think. The DFSG doesn't say anything about 
building. All the rules about how to build packages came after the DFSG 
and are policy territory, so more an ever advancing bar as we learn to 
do better. I think you aim at something worthwhile, I just don't think 
it's time yet to have the bar at that level.

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debichem-devel/attachments/20260615/a4a77d38/attachment.sig>