[Qa-jenkins-dev] Bug#914714: reproducible builds: vary binary-arch and binary-indep vs binary builds

Ivo De Decker ivodd at debian.org
Mon Nov 26 16:18:15 GMT 2018


package: jenkins.debian.org
severity: wishlist

Hi,

Please consider having the first build do separate binary-arch and
binary-indep builds and having the second build do a full binary build (with
arch and indep binaries in the same build run).

Rationale:

- Some packages might produce different binaries in both of these scenario's.
- The buildds run separate binary-arch and binary-indep builds, so this brings
  the reproducible builds infrastructure closer to what is done on the
  buildds, while still testing the full build (which is probably more common
  for maintainer uploads, which unfortunately still exist).
- Some packages might fail in on of these scenario's, but not in the other.
  This could happen because the build-deps-{arch,indep} are not correct, or
  because the build process is different.
- R-b tests the full build on all architectures that are tested. The
  binary-indep build on the buildds happens only on amd64, and we generally
  consider it to be acceptable if arch:all binaries can only be built on some
  architectures. By separating the builds, packages that fail to build the
  binary-indep target on some architectures can be clearly identified.

The process could maybe even be extended somewhat further in the last case.
For those packages, the second build could run the binary-arch target again.
That would allow packages to be tested for reproducibility even on
architectures where the binary-arch (or binary) target doesn't work. Obviously
this would be more complicated to implement. It also would require a double
state to keep track of this (FTBFS for binary/binary-indep and a secondary
state for binary-arch). This is probably only useful if a simple
implementation shows that this is common.

This bug was inspired by the discussion in https://bugs.debian.org/907573.

Thanks for your work on reproducible builds!

Ivo



More information about the Qa-jenkins-dev mailing list