Re: Getting rid of "source file [...] newer than compiled" messages
Ricardo Wurmus skribis: >> $ stat >> /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go >> File: >> ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go’ >> Size: 77485 Blocks: 152IO Block: 4096 regular file >> Device: fc02h/64514d Inode: 137925 Links: 1 >> Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) >> 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. More precisely the mtime should be 1 (one second after the Epoch). Also, when using the ‘stat’ command, it’s a good idea to set TZ=UTC to avoid confusion when looking at the timestamps. Thanks, Ludo’.
Re: Getting rid of "source file [...] newer than compiled" messages
Katherine Cox-Buday writes: > Giovanni Biscuolo writes: > >> synoacl? I cannot find that mount option: are you on a Synology NAS? > > Yes. > >> AFAIK stripe=32 should not have any impact on mtime, nor data=writeback >> >> I'm using Guix on Debian and my store is in a LV too: >> >> /dev/mapper/vg01-gnu on /gnu type ext4 (rw,relatime) > > Hm, OK. That was my best guess. about your mount options: it's likely you don't need all them exept (rw,realtime), try to remove them and remount /gnu... it may be synoacl "confusing" things here [...] -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: Getting rid of "source file [...] newer than compiled" messages
Giovanni Biscuolo writes: > synoacl? I cannot find that mount option: are you on a Synology NAS? Yes. > AFAIK stripe=32 should not have any impact on mtime, nor data=writeback > > I'm using Guix on Debian and my store is in a LV too: > > /dev/mapper/vg01-gnu on /gnu type ext4 (rw,relatime) Hm, OK. That was my best guess. > I vaguely recall once I had one problem with source scm files newer than > compiled when using ./pre-inst-env (for sure I did something wrong > hacking, not directly touching /gnu/store anyway) but "guix gc > --verify=repair" fixed that for me This was my expectation too! I am perplexed as to why it doesn't. > Ricardo also asked you about the daemon: how is it started on your > machine? Synology's distro remains on upstart which is what I'm using to start the daemon: #+BEGIN_EXAMPLE $ ps -fC guix-daemon UIDPID PPID C STIME TTY TIME CMD root 27071 1 0 Apr06 ?00:00:00 guix-daemon --build-users-group=guixbuild #+END_EXAMPLE > HTH! Gio' Thank you! -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Ricardo Wurmus writes: > Maybe. But subsequent calls to “guix pull” should give you new store > items anyway, and those should be fine. That's odd. I have definitely run `guix pull` several times on this machine. > Is there anything special about your setup perhaps? E.g. running the > daemon as some other user than root, using btrfs, etc. The store is mounted on a RAID-6 array with an ext4 filesystem. Maybe the striping is confusing things? Here's the mount point: #+BEGIN_EXAMPLE $ mount |grep gnu /dev/mapper/vg1-volume_2 on /gnu type ext4 (rw,relatime,synoacl,stripe=32,data=writeback,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group) #+END_EXAMPLE >> 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’s one of the reasons why “guix gc > --verify=repair,contents” exists. Hm, does this also look at timestamps? Why didn't this give me any output or fix the issue? -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
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-config.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 involved: >>> >>> #+BEGIN_EXAMPLE >>> $ stat >>> /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm >>> File: >>> ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm’ >>> 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/root) >>> Access: 2019-04-10 09:29:22.00969 -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: >>> ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go’ >>> Size: 77485 Blocks: 152IO Block: 4096 regular file >>> Device: fc02h/64514d Inode: 137925 Links: 1 >>> Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) >>> 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 “guix pull” 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’t ever happen, because all store items should have their >> mtime reset. >> >> You previously mentioned that you modified your store (which “voids your >> warranty” as it were); by default the store is bind-mounted to ensure >> 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’s one of the reasons why “guix gc --verify=repair,contents” exists. -- Ricardo
Re: Getting rid of "source file [...] newer than compiled" messages
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-config.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 involved: >> >> #+BEGIN_EXAMPLE >> $ stat >> /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm >> File: >> ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm’ >> 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/root) >> Access: 2019-04-10 09:29:22.00969 -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: >> ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go’ >> Size: 77485 Blocks: 152IO Block: 4096 regular file >> Device: fc02h/64514d Inode: 137925 Links: 1 >> Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) >> 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’t ever happen, because all store items should have their > mtime reset. > > You previously mentioned that you modified your store (which “voids your > warranty” as it were); by default the store is bind-mounted to ensure > 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? -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
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-config.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 involved: > > #+BEGIN_EXAMPLE > $ stat > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm > File: > ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm’ > Size: 5366Blocks: 16 IO Block: 4096 regular file > Device: fc02h/64514dInode: 137942 Links: 1 > Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) > Access: 2019-04-10 09:29:22.00969 -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: > ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go’ > Size: 77485 Blocks: 152IO Block: 4096 regular file > Device: fc02h/64514dInode: 137925 Links: 1 > Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) > 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. > 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’t ever happen, because all store items should have their mtime reset. You previously mentioned that you modified your store (which “voids your warranty” as it were); by default the store is bind-mounted to ensure that it is read-only. Can you tell us more about the file system and the way the store is mounted? -- Ricardo
Re: Getting rid of "source file [...] newer than compiled" messages
Andreas Enge writes: > Hello, > > On Wed, Apr 10, 2019 at 09:31:03AM -0500, Katherine Cox-Buday wrote: >> Ricardo Wurmus writes: >> >> > You said that there are no .go files, yet Guile keeps saying that the >> > source file >> > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm >> > is newer than the compiled >> > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go >> > >> > Does the second file really not exist while the first one does? >> >> Correct: >> >> #+BEGIN_EXAMPLE >> ls -a >> /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt >> . .. base16.scm base64.scm common.scm hash.scm hmac.scm >> package-config.scm pk-crypto.scm random.scm utils.scm >> #+END_EXAMPLE > > notice that the .go file is in a different subdirectory of the package > directory. 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-config.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 involved: #+BEGIN_EXAMPLE $ stat /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm File: ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm’ 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/root) Access: 2019-04-10 09:29:22.00969 -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: ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go’ Size: 77485 Blocks: 152IO Block: 4096 regular file Device: fc02h/64514d Inode: 137925 Links: 1 Access: (0444/-r--r--r--) Uid: (0/root) Gid: (0/root) 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: 1. This looks like this has been an issue since I installed Guix. Did I do something wrong? 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. Thank you all! And thoughts? -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Hello, On Wed, Apr 10, 2019 at 09:31:03AM -0500, Katherine Cox-Buday wrote: > Ricardo Wurmus writes: > > > You said that there are no .go files, yet Guile keeps saying that the > > source file > > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm > > is newer than the compiled > > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go > > > > Does the second file really not exist while the first one does? > > Correct: > > #+BEGIN_EXAMPLE > ls -a > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt > . .. base16.scm base64.scm common.scm hash.scm hmac.scm > package-config.scm pk-crypto.scm random.scm utils.scm > #+END_EXAMPLE notice that the .go file is in a different subdirectory of the package directory. Andreas
Re: Getting rid of "source file [...] newer than compiled" messages
Ricardo Wurmus writes: > You said that there are no .go files, yet Guile keeps saying that the > source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm > is newer than the compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go > > Does the second file really not exist while the first one does? Correct: #+BEGIN_EXAMPLE ls -a /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt . .. base16.scm base64.scm common.scm hash.scm hmac.scm package-config.scm pk-crypto.scm random.scm utils.scm #+END_EXAMPLE -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Katherine Cox-Buday writes: > Ricardo Wurmus writes: > >> Oh, well, that’s definitely not right. Guix does not download >> individual files when fetching packages — it downloads archives that >> definitely do contain the .go files. So the question is… where did they >> go once “guix pull” finished? > > Yeah, I don't know! Mostly I'm trying to dig into this edge-case of > trying to get malformed packages back into a known state. I imagine that > will come up from time to time on users' machines, for various reasons. > >> Does “guix gc --verify=repair,contents” (run as root) really not tell >> you anything useful? [no repair output] Hmm. You said that there are no .go files, yet Guile keeps saying that the source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm is newer than the compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go Does the second file really not exist while the first one does? -- Ricardo
Re: Getting rid of "source file [...] newer than compiled" messages
Ricardo Wurmus writes: > Oh, well, that’s definitely not right. Guix does not download > individual files when fetching packages — it downloads archives that > definitely do contain the .go files. So the question is… where did they > go once “guix pull” finished? Yeah, I don't know! Mostly I'm trying to dig into this edge-case of trying to get malformed packages back into a known state. I imagine that will come up from time to time on users' machines, for various reasons. > Does “guix gc --verify=repair,contents” (run as root) really not tell > you anything useful? Here is the output, verbatim: #+BEGIN_EXAMPLE sudo guix gc --verify=repair,contents Password: guile: warning: failed to install locale ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/common.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/common.go ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/package-config.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/package-config.go ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/utils.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/utils.go reading the store... checking path existence... checking hashes... Some deprecated features have been used. Set the environment variable GUILE_WARN_DEPRECATED to "detailed" and rerun the program to get more information. Set it to "no" to suppress this message. #+END_EXAMPLE So, unfortunately not :( And these messages continue. As a user, I would have definitely expected this command to have found an issue. -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Katherine Cox-Buday writes: >> 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.0 >> +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 :) Oh, well, that’s definitely not right. Guix does not download individual files when fetching packages — it downloads archives that definitely do contain the .go files. So the question is… where did they go once “guix pull” finished? Does “guix gc --verify=repair,contents” (run as root) really not tell you anything useful? -- Ricardo
Re: Getting rid of "source file [...] newer than compiled" messages
Hello Katherine, Katherine Cox-Buday ezt írta (időpont: 2019. ápr. 6., Szo, 23:16): > > 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. > I believe you might be looking looking for guix gc --verify, and suboptions thereof. https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-gc.html Does that help? > > 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.0 > > +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 > Best regards, g_bor
Re: Getting rid of "source file [...] newer than compiled" messages
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.0 > +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
Re: Getting rid of "source file [...] newer than compiled" messages
Hi Katherine, > I was wondering if anyone had any ideas? This is not blocking me from > doing anything, but it does cause a lot of spam, and it slows operations > down a lot. 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. You showed us this example output: > ;;; note: source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm > ;;; newer than compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go > ;;; note: source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/common.scm > ;;; newer than compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/common.go > ;;; note: source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/package-config.scm > ;;; newer than compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/package-config.go > ;;; note: source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/utils.scm > ;;; newer than compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/utils.go 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.0 +0100. -- Ricardo
Re: Getting rid of "source file [...] newer than compiled" messages
I was wondering if anyone had any ideas? This is not blocking me from doing anything, but it does cause a lot of spam, and it slows operations down a lot. Katherine Cox-Buday writes: > Ricardo Wurmus writes: > >> Katherine Cox-Buday writes: >> >>> I'm not using Guix from a source checkout. I've issued `guix pull` >>> (both >>> under the root account and as my user account) a few times with no >>> change. >> >> Hmm, this should never leave you with an uncompiled Guix. Can you tell >> us more about the environment in which this happens? (e.g. the output >> of “env” will be fine.) > > Here is an example. When I run `guix help` I receive: > > #+BEGIN_EXAMPLE > ;;; note: source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm > ;;; newer than compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go > ;;; note: source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/common.scm > ;;; newer than compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/common.go > ;;; note: source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/package-config.scm > ;;; newer than compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/package-config.go > ;;; note: source file > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/utils.scm > ;;; newer than compiled > /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/utils.go > #+END_EXAMPLE > > > `env` reports: > > #+BEGIN_EXAMPLE > GUIX_LOCPATH=/var/services/homes/me/.guix-profile/lib/locale > TERM=xterm-256color > SHELL=/bin/sh > SSH_CLIENT=[redacted ip] 41856 22 > SSH_TTY=/dev/pts/9 > LC_ALL=en_US.utf8 > USER=me > GUIX_PROFILE=/var/services/homes/me/.guix-profile > PAGER=more > MAIL=/var/mail/me > > PATH=/var/services/homes/me/.guix-profile/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin > PWD=/var/services/homes/me > LANG=en_US.utf8 > SHLVL=1 > HOME=/var/services/homes/me > TERMINFO=/usr/share/terminfo > LOGNAME=me > SSH_CONNECTION=[redacted ip] 41856 [redacted ip] 22 > PGDATA=/var/services/pgsql > XDG_RUNTIME_DIR=/var/services/homes/me/.local/run > GIT_EXEC_PATH=/var/services/homes/me/.guix-profile/bin > _=/bin/env > #+END_EXAMPLE > >>> `guix` is symlinked from `/usr/local/bin/guix` to >>> `/var/guix/profiles/per-user/root/current-guix/bin/guix` which >>> points to >>> the latest profile (which is updated when running `guix pull` as root. >> >> When using “guix pull” it will install into the current user’s >> ~/.config/guix/current/. Are you only using Guix as the root user? > > No, I always use my user account, but root contains the symlinks for the > daemon and CLI. The symlink for `/usr/local/bin/guix` is there from > installation per step (6) of the manual[1]. I tried running `guix pull` > as root because running it under my user account wasn't doing anything. > > Thank you for troubleshooting this with me. > > [1] - > https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html#Binary-Installation -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Ricardo Wurmus writes: > Katherine Cox-Buday writes: > >> I'm not using Guix from a source checkout. I've issued `guix pull` (both >> under the root account and as my user account) a few times with no >> change. > > Hmm, this should never leave you with an uncompiled Guix. Can you tell > us more about the environment in which this happens? (e.g. the output > of “env” will be fine.) Here is an example. When I run `guix help` I receive: #+BEGIN_EXAMPLE ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/hash.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/common.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/common.go ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/package-config.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/package-config.go ;;; note: source file /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/share/guile/site/2.2/gcrypt/utils.scm ;;; newer than compiled /gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/utils.go #+END_EXAMPLE `env` reports: #+BEGIN_EXAMPLE GUIX_LOCPATH=/var/services/homes/me/.guix-profile/lib/locale TERM=xterm-256color SHELL=/bin/sh SSH_CLIENT=[redacted ip] 41856 22 SSH_TTY=/dev/pts/9 LC_ALL=en_US.utf8 USER=me GUIX_PROFILE=/var/services/homes/me/.guix-profile PAGER=more MAIL=/var/mail/me PATH=/var/services/homes/me/.guix-profile/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin PWD=/var/services/homes/me LANG=en_US.utf8 SHLVL=1 HOME=/var/services/homes/me TERMINFO=/usr/share/terminfo LOGNAME=me SSH_CONNECTION=[redacted ip] 41856 [redacted ip] 22 PGDATA=/var/services/pgsql XDG_RUNTIME_DIR=/var/services/homes/me/.local/run GIT_EXEC_PATH=/var/services/homes/me/.guix-profile/bin _=/bin/env #+END_EXAMPLE >> `guix` is symlinked from `/usr/local/bin/guix` to >> `/var/guix/profiles/per-user/root/current-guix/bin/guix` which points to >> the latest profile (which is updated when running `guix pull` as root. > > When using “guix pull” it will install into the current user’s > ~/.config/guix/current/. Are you only using Guix as the root user? No, I always use my user account, but root contains the symlinks for the daemon and CLI. The symlink for `/usr/local/bin/guix` is there from installation per step (6) of the manual[1]. I tried running `guix pull` as root because running it under my user account wasn't doing anything. Thank you for troubleshooting this with me. [1] - https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html#Binary-Installation -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Katherine Cox-Buday writes: > I'm not using Guix from a source checkout. I've issued `guix pull` (both > under the root account and as my user account) a few times with no > change. Hmm, this should never leave you with an uncompiled Guix. Can you tell us more about the environment in which this happens? (e.g. the output of “env” will be fine.) > `guix` is symlinked from `/usr/local/bin/guix` to > `/var/guix/profiles/per-user/root/current-guix/bin/guix` which points to > the latest profile (which is updated when running `guix pull` as root. When using “guix pull” it will install into the current user’s ~/.config/guix/current/. Are you only using Guix as the root user? > Do I need to `guix package -i guix` to get a good version? No. You should never run “guix package -i guix” because it necessarily installs an *older* version of Guix than the version you use to install it. -- Ricardo
Re: Getting rid of "source file [...] newer than compiled" messages
Ricardo Wurmus writes: > Katherine Cox-Buday writes: > >> I have a Guix installation on a foreign distro, and with most any Guix >> command I receive this message for different packages (depending on what >> command is run). I looked at one package and found that there were no >> `.go` files for the `.scm` files which are listed. > > How did you install Guix? It's been awhile now, but I'm pretty sure I followed the manual and used the bash script. >> Is there a supported way to get rid of these issues? Right now my plan >> is to manually go into the store and use guile to compile these fields, >> and I'd really rather not muck with the store! > > You should never change files in the store. > > The recommended way is to use “guix pull”, which compiles Guix. If > you’re using Guix from a source checkout and with ’pre-inst-env’ you’ll > only need to compile the files with “make” to remove the reason for > these warnings to be issued. I'm not using Guix from a source checkout. I've issued `guix pull` (both under the root account and as my user account) a few times with no change. `guix` is symlinked from `/usr/local/bin/guix` to `/var/guix/profiles/per-user/root/current-guix/bin/guix` which points to the latest profile (which is updated when running `guix pull` as root. Even commands which do not submit jobs to the daemon give this error. Do I need to `guix package -i guix` to get a good version? -- Katherine
Re: Getting rid of "source file [...] newer than compiled" messages
Katherine Cox-Buday writes: > I have a Guix installation on a foreign distro, and with most any Guix > command I receive this message for different packages (depending on what > command is run). I looked at one package and found that there were no > `.go` files for the `.scm` files which are listed. How did you install Guix? > Is there a supported way to get rid of these issues? Right now my plan > is to manually go into the store and use guile to compile these fields, > and I'd really rather not muck with the store! You should never change files in the store. The recommended way is to use “guix pull”, which compiles Guix. If you’re using Guix from a source checkout and with ’pre-inst-env’ you’ll only need to compile the files with “make” to remove the reason for these warnings to be issued. -- Ricardo
Getting rid of "source file [...] newer than compiled" messages
I have a Guix installation on a foreign distro, and with most any Guix command I receive this message for different packages (depending on what command is run). I looked at one package and found that there were no `.go` files for the `.scm` files which are listed. I tried a few different things to try and correct this including `guix build --repair`, but I nothing has worked. Is there a supported way to get rid of these issues? Right now my plan is to manually go into the store and use guile to compile these fields, and I'd really rather not muck with the store! -- Katherine
