Re: Potential MBF: packages failing to build twice in a row
On Wed, 2023-08-09 at 22:10:51 +0200, Johannes Schauer Marin Rodrigues wrote:
> Quoting Guillem Jover (2023-08-09 20:55:17)
> > I think I've mentioned this before, but dpkg-source is supposed to be
> > generating reproducible source packages since around the time dpkg-deb
> > has been generating reproducible binary packages. If that's not the case
> > in some circumstance I'd consider that a bug worth fixing (or at least
> > pondering whether it makes sense to support :).
> I ran diffoscope on the differing debian.tar.xz files and got:
>
> --- ../hello_2.10-3.debian.tar.xz.bak
> +++ ../hello_2.10-3.debian.tar.xz
> │┄ Format-specific differences are supported for XZ compressed files but no file-specific differences were detected; falling back to a binary diff. file(1) reports: XZ compressed data, checksum CRC64
>
> I suspect that different versions of xz produce differently compressed
> archives?
As Sven mentions this is probably due to the new parallel xz execution,
but…
> In any case, I have no time for a more thorough analysis right now but this was
> an example that makes my point: passing --source to sbuild might overwrite your
> existing source package with something different and thus it's not trivial
> anymore to assure that what you built really came from those exact same sources
> as the source that the built was done from was not bit-by-bit identical to the
> source produced by sbuild --source. In fact the .buildinfo file produced by
> sbuild will reference the *new* dsc and that was not the dsc that the built was
> done from. So my point stands: avoid running sbuild with --source.
…the same constraints would apply to dpkg-source as they would when
building binary packages, as in, it can produce reproducible source as
long as the environment described in the .buildinfo file is the same
(or equivalent functionality wise).
So this works even ignoring the .buildinfo, as long as the source is
regenerated close enough in time to when it was first created.
Otherwise if it gets regenerated at any other future time then it
might fail to reproduce, yes, and trying to honor the .buildinfo and
use an up-to-date build environment seems would be in conflict. So I
guess your recommendation makes sense if this was intended to be used
unconditionally (more so in circumstances where previously no source
would generally be created, say on binNMUs or similar).
Thanks,
Guillem
Reply to: