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
OpenPGP_signature.asc
Description: OpenPGP digital signature
