Hi, On 27-09-2025 17:10, Sebastian Ramacher wrote:
3. Once we've got the hang of this, block the migration of packages that build non-reproducible binaries.If they not-reproducability is treated as RC bugs, I think this should only block migration if unstable regressed in comaparison to the version in testing.
That's effectively the same as what I propose to do with the hints. I mean, contrary to autopkgtest that can regress in a source package in testing without a change to said source package, reproducibility doesn't (or maybe to be totally correct I should say shouldn't) change. So, I can statically create these hints once and that should cover your concern.
The new version of the policy checks the source on a per binary/arch level and the hints can be either per binary or per source and can be architectured.What do we gain from binary level hints if packages only migrate on source package basis?
Because we can now prevent regression on a per binary basis. E.g. we can allow gcc-13 to keep shipping gcc-13-test-results while otherwise mandating that it has to build reproducible (bad example as I think gcc-13 currently is on a deny list, but I hope you catch what I mean).
On IRC Sebastian also brought up that we'd need to agree on what we'd expect the environment of r.d.n to look like. Obviously CPU, RAM, hostname and exact build times will be different from the buldds, but most other things we'd expect the same, like umasks, timezones and locale settings. Are those the same across all buildds? A point of attention is the packages installed on the buildds which aren't specified in the build dependencies and thus not logged in the buildinfo files: apt, openssl, ca-certificates and fakeroot (the latter depending on Rules-Requires-Root: binary-targets if I get it right).
Paul
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature