From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Reproducible builds: a means to an end Date: Mon, 16 Nov 2015 16:40:57 +0100 Message-ID: <87wpti3qba.fsf@gnu.org> References: <87bnb0egb1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58413) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyLtw-0001j6-98 for guix-devel@gnu.org; Mon, 16 Nov 2015 10:41:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyLts-0004t2-8z for guix-devel@gnu.org; Mon, 16 Nov 2015 10:41:04 -0500 In-Reply-To: (Ricardo Wurmus's message of "Mon, 16 Nov 2015 15:44:40 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ricardo Wurmus Cc: guix-devel Ricardo Wurmus 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=E2=80=99ll 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=E2=80=99re hard to find though (f= or instance, patch-tracker.debian.org seems to be off-line.) > The utility of =E2=80=9Cguix challenge=E2=80=9D 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 =E2=80=9Cguix challe= nge=E2=80=9D > suggests as having non-reproducible builds.) =E2=80=9Cguix challenge=E2=80=9D is a simple way to find out which packages= are non deterministic. That=E2=80=99s how I found about those that can be seen at for example. 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 . There are some issues that this approach cannot catch, but it=E2=80=99s 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 =E2=80=98tk-update=E2=80=99. 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=E2=80=99s why reproducible-build.org as a cross-distro project is so important. Ludo=E2=80=99.