From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#20428: git-fetch does not always validate hash Date: Fri, 01 May 2015 22:21:52 +0200 Message-ID: <87lhh89hgf.fsf@gnu.org> References: <87lhhfyqvn.fsf@mango.localdomain> 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]:60224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoHRk-0001z5-1P for bug-guix@gnu.org; Fri, 01 May 2015 16:22:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoHRj-0001Tt-8N for bug-guix@gnu.org; Fri, 01 May 2015 16:22:03 -0400 Received: from debbugs.gnu.org ([140.186.70.43]:48975) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoHRj-0001Tm-5s for bug-guix@gnu.org; Fri, 01 May 2015 16:22:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YoHRi-0008JD-Uy for bug-guix@gnu.org; Fri, 01 May 2015 16:22:03 -0400 Sender: "Debbugs-submit" Resent-To: bug-guix@gnu.org Resent-Message-ID: In-Reply-To: <87lhhfyqvn.fsf@mango.localdomain> (Ricardo Wurmus's message of "Sun, 26 Apr 2015 15:13:16 +0200") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Ricardo Wurmus Cc: 20428-done@debbugs.gnu.org Ricardo Wurmus skribis: > Upon rebuilding the package from a new commit I would expect the build > to fail with a hash validation error as I have not updated the hash yet. > However, the build procedure just continues. I noticed that the git > checkout is still the very same as before I updated the value of > "commit". I cannot seem to reliably force a new git checkout. Indeed, origins compile to fixed-output derivations, meaning that these are special derivations whose output is known in advance (rather, the SHA256 is the output is known in advance.) Thus, it doesn=E2=80=99t matter= how the derivation produces its result as long as its output has the correct hash. When you leave the =E2=80=98sha256=E2=80=99 unchanged, the daemon notices t= hat there=E2=80=99s already an item with this name and hash in the store, so it does nothing. This is expected behavior, though I understand this can be error-prone here. To avoid that, you could add a =E2=80=98file-name=E2=80=99 field to the ori= gin that includes the commit: (file-name (string-append name "-checkout-" commit)) Thus, if you change the commit without changing the hash, the daemon will still want to build the origin (because of the changed name) and will eventually complain about the hash mismatch. Thanks, Ludo=E2=80=99.