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: Wed, 10 Apr 2019 13:04:50 -0500 Message-ID: <87sgupohx9.fsf@gmail.com> References: <875zs2313w.fsf@gmail.com> <87imw21jpk.fsf@elephly.net> <87wokh1zc0.fsf@gmail.com> <87k1g6ncss.fsf@gmail.com> <87r2aeg96d.fsf@elephly.net> <87ftqun8ce.fsf@gmail.com> <87mul2fr1x.fsf@elephly.net> <877ec5n2n0.fsf@gmail.com> <87h8b9f14s.fsf@elephly.net> <87wok2ortk.fsf@gmail.com> <20190410160428.GA4187@jurong> <871s29q155.fsf@gmail.com> <87k1g1erf6.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:35569) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEHak-0003P8-Et for help-guix@gnu.org; Wed, 10 Apr 2019 14:04:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hEHai-0002QO-CK for help-guix@gnu.org; Wed, 10 Apr 2019 14:04:58 -0400 Received: from mail-it1-x142.google.com ([2607:f8b0:4864:20::142]:55272) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hEHai-0002PM-0E for help-guix@gnu.org; Wed, 10 Apr 2019 14:04:56 -0400 Received: by mail-it1-x142.google.com with SMTP id a190so4987526ite.4 for ; Wed, 10 Apr 2019 11:04:54 -0700 (PDT) In-Reply-To: <87k1g1erf6.fsf@elephly.net> (Ricardo Wurmus's message of "Wed, 10 Apr 2019 18:49:49 +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: > Katherine Cox-Buday writes: > >> Gosh, I am embarassed. The compiled files are indeed in the path Guile >> was helpfully trying to point me at: >> >> #+BEGIN_EXAMPLE >> $ ls -a /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/= lib/guile/2.2/site-ccache/gcrypt/ >> . .. base16.go base64.go common.go hash.go hmac.go package-conf= ig.go pk-crypto.go random.go utils.go >> #+END_EXAMPLE >> >> So I went back and took Ricardo's advice and looked at the time's involv= ed: >> >> #+BEGIN_EXAMPLE >> $ stat /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/s= hare/guile/site/2.2/gcrypt/hash.scm >> File: =E2=80=98/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-modu= le-union/share/guile/site/2.2/gcrypt/hash.scm=E2=80=99 >> Size: 5366 Blocks: 16 IO Block: 4096 regular file >> Device: fc02h/64514d Inode: 137942 Links: 1 >> Access: (0444/-r--r--r--) Uid: ( 0/ root) Gid: ( 0/ roo= t) >> Access: 2019-04-10 09:29:22.008888969 -0500 >> Modify: 2018-12-25 17:02:43.755150339 -0600 >> Change: 2018-12-25 17:02:43.755150339 -0600 >> Birth: - >> #+END_EXAMPLE >> >> #+BEGIN_EXAMPLE >> $ stat /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/l= ib/guile/2.2/site-ccache/gcrypt/hash.go >> File: =E2=80=98/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-modu= le-union/lib/guile/2.2/site-ccache/gcrypt/hash.go=E2=80=99 >> Size: 77485 Blocks: 152 IO Block: 4096 regular file >> Device: fc02h/64514d Inode: 137925 Links: 1 >> Access: (0444/-r--r--r--) Uid: ( 0/ root) Gid: ( 0/ roo= t) >> Access: 2019-04-06 16:56:32.259721626 -0500 >> Modify: 2018-12-25 17:02:43.753150336 -0600 >> Change: 2018-12-25 17:02:43.753150336 -0600 >> Birth: - >> #+END_EXAMPLE >> >> It looks like the scheme file is fractions of a second newer than the >> compiled file. So, pulling on this thread: > > These time stamps are wrong. Everything in /gnu/store should have 0 for > the mtime. Perhaps I missed a flag when unpacking the store initially? > >> 2. I feel like, regardless of the root-cause, some Guix command should >> be able to correct this issue for me, without necessarily having to >> know what went wrong or why. > > This shouldn=E2=80=99t ever happen, because all store items should have t= heir > mtime reset. > > You previously mentioned that you modified your store (which =E2=80=9Cvoi= ds your > warranty=E2=80=9D as it were); by default the store is bind-mounted to en= sure > that it is read-only. Can you tell us more about the file system and > the way the store is mounted? I previously mentioned I was considering modifying the store as a fix to this issue. To my recollection, I don't think I've manually touched the store yet. I still hold the opinion that the guix toolchain should be able to heal store items, regardless of how they got that way, or whether it should be theoretically possible. Do you disagree? --=20 Katherine