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 >