Bug#914714: reproducible builds: vary binary-arch and binary-indep vs binary builds

[Vagrant Cascadian]

On 2018-11-26, Holger Levsen wrote:
> On Mon, Nov 26, 2018 at 05:18:15PM +0100, Ivo De Decker wrote:
>> 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).
>
> that's something I like.
>
>> - 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.
>
> that's something I dont really like. (because it has cognitive and other
> costs for us (working on r-b).)
>
> But still, the first quoted block convinced me that it's worthwhile to
> do. Just I'm not sure when, so I'd definitly accept patches.

From a quick glance at the jenkins code it looks feasible to implement
the split arch:all and arch:any build, but what's unclear is how to
compare a single arch:all+any .buildinfo against two .buildinfo files
(arch:all and arch:any).

Maybe something like "mergechanges" applied to .buildinfo files?


>> 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.
>
> instead of making our rebuilds in the lab more efficient/complicated,
> I'd rather spend time on working rebuilding against the actual debian
> archive, based on the published .buildinfo files from these builds.

This also would be very helpful...

A problem I'm facing, having introduced a change in u-boot that now
builds an arch:all package that only builds on amd64/i386, but has
significantly different arch:any packages for arm64/armhf that really
should get tested.

Maybe we should only test arch:all on amd64? Though that's edging into a
different kind of bug entirely.


> But this is my POV, if someone wants to implement this, I'd very
> probably take those patches.
>
>> 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.
>
> we btw also need / should check, whether arch:all rebuilds on different
> arch have reproducible results...

That seems pretty doable; amd64+i386 would be the easiest but perhaps
least interesting to test...  or testing four consecutive builds across
all four architectures... that seems almost too adventurous! Especially
given that some packages only build arch:all on specific architectures.


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/qa-jenkins-dev/attachments/20190513/db0c779c/attachment.sig>