Getting rid of "source file [...] newer than compiled" messages

Getting rid of "source file [...] newer than compiled" messages

[Katherine Cox-Buday]

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

Re: Getting rid of "source file [...] newer than compiled" messages

[Ricardo Wurmus]

Katherine Cox-Buday <cox.katherine.e@gmail.com> 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

Re: Getting rid of "source file [...] newer than compiled" messages

[Katherine Cox-Buday]

Ricardo Wurmus <rekado@elephly.net> writes:

> Katherine Cox-Buday <cox.katherine.e@gmail.com> 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

[Ricardo Wurmus]

Katherine Cox-Buday <cox.katherine.e@gmail.com> 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

[Katherine Cox-Buday]

Ricardo Wurmus <rekado@elephly.net> writes:

> Katherine Cox-Buday <cox.katherine.e@gmail.com> 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]

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 <cox.katherine.e@gmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Katherine Cox-Buday <cox.katherine.e@gmail.com> 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]

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.000000000
+0100.

--
Ricardo

Re: Getting rid of "source file [...] newer than compiled" messages

[Katherine Cox-Buday]

Ricardo Wurmus <rekado@elephly.net> 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

Re: Getting rid of "source file [...] newer than compiled" messages

[Gábor Boskovits]

Hello Katherine,

Katherine Cox-Buday <cox.katherine.e@gmail.com> ezt írta (időpont:
2019. ápr. 6., Szo, 23:16):
>
> Ricardo Wurmus <rekado@elephly.net> 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.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
>

Best regards,
g_bor

Re: Getting rid of "source file [...] newer than compiled" messages

[Ricardo Wurmus]

Katherine Cox-Buday <cox.katherine.e@gmail.com> 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.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 :)

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

[Katherine Cox-Buday]

Ricardo Wurmus <rekado@elephly.net> 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

[Ricardo Wurmus]

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> 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

[Katherine Cox-Buday]

Ricardo Wurmus <rekado@elephly.net> 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

[Andreas Enge]

Hello,

On Wed, Apr 10, 2019 at 09:31:03AM -0500, Katherine Cox-Buday wrote:
> Ricardo Wurmus <rekado@elephly.net> 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

[Katherine Cox-Buday]

Andreas Enge <andreas@enge.fr> writes:

> Hello,
>
> On Wed, Apr 10, 2019 at 09:31:03AM -0500, Katherine Cox-Buday wrote:
>> Ricardo Wurmus <rekado@elephly.net> 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.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: ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go’
    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/    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

[Ricardo Wurmus]

Katherine Cox-Buday <cox.katherine.e@gmail.com> 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.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: ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go’
>     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/    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

[Katherine Cox-Buday]

Ricardo Wurmus <rekado@elephly.net> writes:

> Katherine Cox-Buday <cox.katherine.e@gmail.com> 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.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: ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go’
>>     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/    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

[Ricardo Wurmus]

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Katherine Cox-Buday <cox.katherine.e@gmail.com> 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.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: ‘/gnu/store/cd6rjv3qhhghr59wpq4fksfr84d5dsdf-guix-module-union/lib/guile/2.2/site-ccache/gcrypt/hash.go’
>>>     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/    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

[Katherine Cox-Buday]

Ricardo Wurmus <rekado@elephly.net> 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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 1839 bytes --]

Hello,

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:

[...]

>> 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

synoacl? I cannot find that mount option: are you on a Synology NAS?

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:

--8<---------------cut here---------------start------------->8---
/dev/mapper/vg01-gnu on /gnu type ext4 (rw,relatime)
--8<---------------cut here---------------end--------------->8---

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

Ricardo also asked you about the daemon: how is it started on your
machine?

mine is starded by the systemd service (installed via binary
installation), and is running as root:

--8<---------------cut here---------------start------------->8---
host:~$ ps aux | grep guix-daemon
root      2444  0.0  0.0  12216  1808 ?        Ss   Mar22   0:00 /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild
--8<---------------cut here---------------end--------------->8---

[...]

HTH! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Getting rid of "source file [...] newer than compiled" messages

[Katherine Cox-Buday]

Giovanni Biscuolo <g@xelera.eu> 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
  UID        PID  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

[Giovanni Biscuolo]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

Katherine Cox-Buday <cox.katherine.e@gmail.com> writes:

> Giovanni Biscuolo <g@xelera.eu> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Getting rid of "source file [...] newer than compiled" messages

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> 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: 152        IO 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’.