Re: towards a reproducible forky
On 2025-09-27 16:56:57 +0200, Paul Gevers wrote:
> Hi Release Team colleagues,
>
> While tests.reproducible-builds.org has been doing a great job in
> bootstrapping the reproducibility problem in Debian, it does so by building
> twice in a row with different build environments. What we are actually
> interested in is if the binaries that we ship can be reproduced. Because of
> that, I haven't enabled the ReproduciblePolicy in britney2 to influence the
> migration yet. However, recently reproduce.debian.net [1] has started to try
> to rebuild the packages as built on the buildds. As the data from there is
> now (nearly) usable, I'd like to discuss whether my plan aligns with your
> views.
>
> My ambition: packages in forky must build reproducible.
>
>
> My plan
> =======
>
> 1.a Switch the ReproduciblePolicy in britney2 to the reproduce.d.n. API
>
> 1.b There's one delta in the new version of the policy with respect to the
> current version: I didn't implement checking for regressions, see
> "Exceptions" below.
>
> 1.c Start with checking arch:all and arch:amd64 binaries. Currently the
> other architectures are not yet fully tested. I believe this is just work in
> progress to setup and assign workers, but until their number of unknown
> binaries gets close to zero, I don't think it's useful to add them. My
> expectation is this is a matter of days or weeks, not months.
>
> 1.d show reproducible status "for info" in the excuses, as we currently do.
>
> 2. Once we've convinced ourselves that the service is fast and reliable
> enough and the last structural sources have been dealt with (see "standing
> issues" below), I want to switch to penalties for packages that ship
> binaries that are not reproducible. I propose we start with 10 days for
> this. I liked what we did during the introduction of AutopkgtestPolicy:
> slowly increase the penalty over time. Maybe something like 1 day extra per
> week?
>
> 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.
>
> Exceptions
> ==========
>
> Obviously there are binaries that currently are not reproducible. Some
> statistics can be seen on the front page of reproduce.d.n [1] (showing
> forky). My intention is to create and maintain a list of (unversioned) hints
> for source or binary packages that are not reproducible in testing once we
> enable penalties. I'll be filing bugs at that time to warn these packages of
> their status (first at severity important, to be raised to serious later
> on). I expect there will be packages that we can't miss and will be hard to
> make reproducible, we can handle that via hints as long as we must.
>
> 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?
Cheers
--
Sebastian Ramacher
Reply to: