Re: Reproducible builds: a means to an end

[Alex Vong]

Hi,

On 16/11/2015, Ludovic Courtès <address@hidden> wrote:
> Ricardo Wurmus <address@hidden> skribis:
>
>> I wonder how we as a project could help the reproducible builds project
>> and/or directly benefit from their findings.
>
> I was invited to their first Reproducible World Summit in December,
> along with people from many different projects.  I guess the main focus
> will be on collaboration and knowledge sharing.  We’ll see!
>
>> Are there ready-made patches we could apply to our package recipes?
>> Or should we just wait for upstream projects to be fixed?
>
> Sometimes there are ready-made patches that can be found in Debian or
> other distros, sometimes not.  Often they’re hard to find though (for
> instance, patch-tracker.debian.org seems to be off-line.)
>
Yes, according to
<https://lists.debian.org/debian-devel/2014/05/msg00889.html>, the
maintainer of patch-tracker.debian.org has been missing in action
until now. I think the website will be off-line in the near future.

>> The utility of “guix challenge” is much reduced when for so many
>> packages we do not actually have reproducible builds.
>>
>> (Maybe we could have a page that lists packages that “guix challenge”
>> suggests as having non-reproducible builds.)
>
> “guix challenge” is a simple way to find out which packages are non
> deterministic.  That’s how I found about those that can be seen at
> <http://bugs.gnu.org/guix> for example.
>
Does that mean we should have a bug report for every non-reproducible
packages? Or should we only have bug reports for popular packages?

> We could also have a second build farm, probably x86_64-only,
> specifically for the purpose of doing independent builds.
>
> The ability to publish the hash of local builds in a peer-to-peer
> fashion would be even better.
>
> I also want to merge
> <https://github.com/NixOS/nix/commit/8fdd156a650f9b2ce9ae8cd74edcf16225478292>.
> There are some issues that this approach cannot catch, but it’s good
> enough for all the timestamp or randomness related issues.
>
>> Can we automate some fixes, such as disabling timestamps?  (I see, for
>> example, that the Python REPL tells me when it was built.)
>
> I fixed that one in ‘tk-update’.  This particular one could have been
> avoided by having GCC return zero for __DATE__ and __TIME__.
>
> However, most other timestamp issues (like Python, Emacs, and Groff
> adding timestamps in their byproducts) cannot be addressed
> automatically.  That’s why reproducible-build.org as a cross-distro
> project is so important.
>
> Ludo’.
>
>

Cheers,
Alex