From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: Getting rid of "source file [...] newer than compiled" messages Date: Wed, 10 Apr 2019 20:22:25 +0200 Message-ID: <87d0lten4u.fsf@elephly.net> 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> <87sgupohx9.fsf@gmail.com> 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]:41410) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEI6q-0000uO-1h for help-guix@gnu.org; Wed, 10 Apr 2019 14:38:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hEI6o-00022o-QY for help-guix@gnu.org; Wed, 10 Apr 2019 14:38:07 -0400 Received: from sender4-of-o53.zoho.com ([136.143.188.53]:21338) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hEI6o-0001yw-B8 for help-guix@gnu.org; Wed, 10 Apr 2019 14:38:06 -0400 In-reply-to: <87sgupohx9.fsf@gmail.com> 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: Katherine Cox-Buday Cc: help-guix@gnu.org Katherine Cox-Buday writes: > 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-con= fig.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 invol= ved: >>> >>> #+BEGIN_EXAMPLE >>> $ stat /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/= share/guile/site/2.2/gcrypt/hash.scm >>> File: =E2=80=98/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-mod= ule-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/ ro= ot) >>> 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/= lib/guile/2.2/site-ccache/gcrypt/hash.go >>> File: =E2=80=98/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-mod= ule-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/ ro= ot) >>> 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? Maybe. But subsequent calls to =E2=80=9Cguix pull=E2=80=9D should give you= new store items anyway, and those should be fine. Is there anything special about your setup perhaps? E.g. running the daemon as some other user than root, using btrfs, etc. >>> 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 = their >> mtime reset. >> >> You previously mentioned that you modified your store (which =E2=80=9Cvo= ids your >> warranty=E2=80=9D as it were); by default the store is bind-mounted to e= nsure >> 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. Okay. > 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? No, I agree with you. That=E2=80=99s one of the reasons why =E2=80=9Cguix = gc --verify=3Drepair,contents=E2=80=9D exists. -- Ricardo