[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Potential MBF: packages failing to build twice in a row



Hi,

Quoting Guillem Jover (2023-08-09 20:55:17)
> On Wed, 2023-08-09 at 19:55:41 +0200, Johannes Schauer Marin Rodrigues wrote:
> > I would only consider switching the default if at the same time, some checks
> > were done that made sure that the result is bit-by-bit identical to the
> > original.
> > 
> > The source package is the *input* to sbuild not its output. If sbuild builds
> > the source package it can happen that the resulting source package is not what
> > was given to sbuild to get built before.
> > 
> > So if the source package gets rebuilt and checked whether it is bit-by-bit
> > identical to what was given to sbuild before, then essentially we would've
> > enforced reproducible source packages. If I remember correctly, reproducible
> > source packages are something that the reproducible builds team discarded as a
> > concept many years ago.
> 
> 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 :).

it has been a long time since I've analyzed this so things might've changed
indeed since then. But what I remember is that, depending on the source
package, running sbuild with --source would produce a different source package
than was originally passed to sbuild. I tried running this on a few source
packages to see if I can reproduce this problem today:

    sbuild --source --arch-all --arch-any -d unstable --no-run-lintian \
        --no-run-autopkgtest \
        --starting-build-commands='grep -E "^ [a-f0-9]{64} " *_*.dsc > before' \
        --finished-build-commands='grep -E "^ [a-f0-9]{64} " *_*.dsc | diff -u before -'

Which prints for src:hello this:

	--- before	2023-08-09 19:46:05.092628335 +0000
	+++ -	2023-08-09 19:46:25.873292249 +0000
	@@ -1,3 +1,3 @@
	  31e066137a962676e89f69d1b65382de95a7ef7d914b8cb956f41ea72e0f516b 725946 hello_2.10.orig.tar.gz
	  4ea69de913428a4034d30dcdcb34ab84f5c4a76acf9040f3091f0d3fac411b60 819 hello_2.10.orig.tar.gz.asc
	- 60ee7a466808301fbaa7fea2490b5e7a6d86f598956fb3e79c71b3295dc1f249 12684 hello_2.10-3.debian.tar.xz
	+ 84b14a8c49f9bca8d6c7a5550fed71790e147576c8eb716b2afbd49df4d5a7a9 12692 hello_2.10-3.debian.tar.xz


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?

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.

Thanks!

cheers, josch

Attachment: signature.asc
Description: signature


Reply to: