From mboxrd@z Thu Jan 1 00:00:00 1970 From: Katherine Cox-Buday Subject: Re: Getting rid of "source file [...] newer than compiled" messages Date: Sat, 06 Apr 2019 16:15:45 -0500 Message-ID: <87ftqun8ce.fsf@gmail.com> References: <87ef6q3muf.fsf@gmail.com> <87lg0y1xut.fsf@elephly.net> <875zs2313w.fsf@gmail.com> <87imw21jpk.fsf@elephly.net> <87wokh1zc0.fsf@gmail.com> <87k1g6ncss.fsf@gmail.com> <87r2aeg96d.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([209.51.188.92]:34285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hCsfG-0002rS-Un for help-guix@gnu.org; Sat, 06 Apr 2019 17:15:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hCsfF-0001si-C9 for help-guix@gnu.org; Sat, 06 Apr 2019 17:15:50 -0400 Received: from mail-it1-x12d.google.com ([2607:f8b0:4864:20::12d]:51616) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hCsfF-0001s1-46 for help-guix@gnu.org; Sat, 06 Apr 2019 17:15:49 -0400 Received: by mail-it1-x12d.google.com with SMTP id s3so15187188itk.1 for ; Sat, 06 Apr 2019 14:15:48 -0700 (PDT) In-Reply-To: <87r2aeg96d.fsf@elephly.net> (Ricardo Wurmus's message of "Sat, 06 Apr 2019 22:39:38 +0200") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: "Help-Guix" To: Ricardo Wurmus Cc: help-guix@gnu.org Ricardo Wurmus writes: > This is really odd and I cannot reproduce this. I wonder if this might > be related to some unusual file system choices or settings that cause > Guile to think that the source files are more recent. I have accepted that I have somehow gotten myself into a dark corner of Guix! I was expecting there to be a Guix command that would basically get any package back into a good state. I was kind of surprised that `guix build --check` or `guix build --repair` didn't help me out. My expectation was that maybe this would check the hash of the store with upstream and rebuild or redownload a substitute. > Can you show us the mtime of these files? In my case both the scm and > the go files all have their mtime as 1970-01-01 01:00:01.000000000 > +0100. One interesting point might be that there are no `.go` files. I would argue Guile's error message here could use some care, but even a better error message won't get me to a better spot :) Thanks again for the time, Ricardo. -- Katherine