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
