Hi, On 16/11/2015, Ludovic Courtès <l...@gnu.org> wrote: > Ricardo Wurmus <ricardo.wur...@mdc-berlin.de> 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
