Bug#950585: binutils-dev: included log files introduce reproducibility issues

[Matthias Klose]

On 2/24/20 11:09 PM, Vagrant Cascadian wrote:
> On 2020-02-22, Matthias Klose wrote:
>>> I'm not sure what the rationale for including these test logs in the
>>> package is, but from a reproducible builds perspective, ideally these
>>> would simply not be included at all.
>>
>> that's not an option.  this is all useful information for debugging purposes,
>> and you'll find that in the GCC packages as well.  Having it turned off by
>> default defeats the purpose.
> 
> So, my attempt at sanitizing them removed too much information; ok.
> 
> Why can't these test logs be output to the build log instead of being
> embedded in the package? What's the use-case that needs them to be in
> the package itself?
> 
> From what I recall, binutils was reproducible in debian testing for a
> while before these logs were added. While GCC was not ever reproducible
> thus far, it is another core part of the toolchain that I would hope
> could one day be made reproducible.

cat'ing to stdout is possible, yes, however that will add to the log size.
gcc-N-test-results is a 13MB compressed package. This doesn't scale.

>> I think I filed a bug report that builds should be
>> able to generate their own artifacts, as the autopkg tests are doing that,
>> however that probably will take a while to implement.
> 
> I would be very interested in this bug report; against what package?

hmm, that was Ubuntu only:
https://bugs.launchpad.net/launchpad/+bug/1845159

Feel free to forward that. sbuild, pbuilder?

>> Or you could add a override database for files which are expected to differ.
> 
> This is considerably more complicated than running a checksum on the
> resulting .deb files and is another opportunity for bugs to lead to
> incorrect reproducibility results... which I think has actually happened
> when trying this kind of approach in the past, though I don't have a
> reference off the top of my head.
> 
> Exploring avenues to put files like this into some separate artifact for
> things that are not reproducible might be one avenue; I know that the
> debian-installer packages ship some artifacts which are not
> .deb/.dbgsym/.udeb... but this still makes it more difficult to compare
> the resulting objects... worried about how to get that right, but maybe
> we, as reproducible builds, need to explore that an an option?
> 
> 
> live well,
>   vagrant
>