Re: 01/01: services: Add SRFI-26 to Nix activation gexp.

Re: 01/01: services: Add SRFI-26 to Nix activation gexp.

[Ludovic Courtès]

Hi Tobias,

guix-commits@gnu.org skribis:

> commit 2be6b5e2eea9ac084cc22281f64f7a089e46cdae
> Author: Tobias Geerinckx-Rice <me@tobias.gr>
> Date:   Tue Jun 11 20:50:37 2019 +0200
>
>     services: Add SRFI-26 to Nix activation gexp.

[...]

>  (define (nix-activation _)
>    "Return the activation gexp."
> -  (with-imported-modules '((guix build utils))
> +  (with-imported-modules '((guix build utils)
> +                           (srfi srfi-26))
>      #~(begin
> -        (use-modules (guix build utils))
> +        (use-modules (guix build utils)
> +                     (srfi srfi-26))

(srfi srfi-26) must not be added to the imported modules: it would
import it from the host Guile, but the host Guile version may differ
between users, and thus the resulting derivation would also differ.

The right thing is to just (use-modules (srfi srfi-26)), which has the
effect of using that module from the Guile being used for builds.

Could you adjust it accordingly?

Thanks, and thanks for the bug fix!

Ludo’.

Re: 01/01: services: Add SRFI-26 to Nix activation gexp.

[Tobias Geerinckx-Rice]

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

Ludo',

Ludovic Courtès wrote:
> (srfi srfi-26) must not be added to the imported modules: it 
> would
> import it from the host Guile, but the host Guile version may 
> differ
> between users

I looked at ‘G-Expressions’ in the manual before but I didn't see 
this documented.  Did I miss it, or is this tribal knowledge?

Assuming there's at least a probably-good and definitely-bad set 
of modules that should(n't) be imported this way: can we at least 
print a warning when a non-(guix) module is listed, or whatever 
the rule would be?

> , and thus the resulting derivation would also differ.

Just to make sure I follow, it's obviously wrong it both cases: 
this would only be exposed if Guile's CUT suddenly changed its 
*behaviour* in a visible (and likely very unintentional) way, 
right?  Or does with-imported-modules pull in (and hash) the 
actual object code (/closure)?

> The right thing is to just (use-modules (srfi srfi-26)), which 
> has the
> effect of using that module from the Guile being used for 
> builds.
>
> Could you adjust it accordingly?

Please take a second to check whether 79d19d7d does what you 
meant.

> Thanks, and thanks for the bug fix!

Thank you for answering my many questions,

T G-R

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

Re: 01/01: services: Add SRFI-26 to Nix activation gexp.

[Ludovic Courtès]

Hi Tobias,

Tobias Geerinckx-Rice <me@tobias.gr> skribis:

> Ludovic Courtès wrote:
>> (srfi srfi-26) must not be added to the imported modules: it would
>> import it from the host Guile, but the host Guile version may differ
>> between users
>
> I looked at ‘G-Expressions’ in the manual before but I didn't see this
> documented.  Did I miss it, or is this tribal knowledge?

I’m afraid it’s tribal knowledge.  ;-)

> Assuming there's at least a probably-good and definitely-bad set of
> modules that should(n't) be imported this way: can we at least print a
> warning when a non-(guix) module is listed, or whatever the rule would
> be?

Should we print a warning?  I don’t know.  ‘with-imported-modules’ does
what it says: it imports modules from the host side into the build side.
Usually, it’s “wrong” to import modules that ship with Guile, but there
might be cases where you want to do it.

So I’m not sure a warning is the right thing, but I’m open to
suggestions!

>> , and thus the resulting derivation would also differ.
>
> Just to make sure I follow, it's obviously wrong it both cases: this
> would only be exposed if Guile's CUT suddenly changed its *behaviour*
> in a visible (and likely very unintentional) way, right?  Or does
> with-imported-modules pull in (and hash) the actual object code
> (/closure)?

‘with-imported-modules’ takes the srfi-26.scm file that you have in your
%load-path, and makes it an input of the derivation.

Between Guile 2.2.4 and Guile 2.2.5, the API is undoubtedly the same,
but the file itself could be slightly different (for example, copyright
years in the header might have changed.)  Thus, if I run 2.2.5 and you
run 2.2.4, we’d be getting different derivations, simply because our
copy of srfi-26.scm differs.

>> The right thing is to just (use-modules (srfi srfi-26)), which has
>> the
>> effect of using that module from the Guile being used for builds.
>>
>> Could you adjust it accordingly?
>
> Please take a second to check whether 79d19d7d does what you meant.

It does, thank you!

Ludo’.

Re: 01/01: services: Add SRFI-26 to Nix activation gexp.

[Mark H Weaver]

Hi Tobias,

guix-commits@gnu.org writes:

> nckx pushed a commit to branch master
> in repository guix.
>
> commit 2be6b5e2eea9ac084cc22281f64f7a089e46cdae
> Author: Tobias Geerinckx-Rice <me@tobias.gr>
> Date:   Tue Jun 11 20:50:37 2019 +0200
>
>     services: Add SRFI-26 to Nix activation gexp.
>     
>     Fix the following fatal error on ‘guix system reconfigure’:
>     
>     Backtrace:
>               18 (primitive-load "/home/nckx/.config/guix/current/bin/guix")
>     In guix/ui.scm:
>       1620:12 17 (run-guix-command _ . _)
>     In ice-9/boot-9.scm:
>         829:9 16 (catch _ _ #<procedure 7a7caa2d4c80 at guix/ui.scm:587:2 (key c)> _)
>         829:9 15 (catch _ _ #<procedure 7a7caa2d4c98 at guix/ui.scm:710:6 (key proc format-string format-args . …> …)
>     In guix/scripts/system.scm:
>        1325:8 14 (_)
>     In guix/status.scm:
>         768:4 13 (call-with-status-report _ _)
>     In guix/scripts/system.scm:
>        1181:4 12 (process-action _ _ _)
>     In guix/store.scm:
>        623:10 11 (call-with-store _)
>       1800:24 10 (run-with-store _ _ #:guile-for-build _ #:system _ #:target _)
>     In guix/scripts/system.scm:
>        920:13  9 (_ _)
>         409:8  8 (_ _)
>     In unknown file:
>                7 (primitive-load "/gnu/store/dha7j9gcz3vgb8cy7vfvvaswwsywrrzj-activate")
>     In ice-9/boot-9.scm:
>        260:13  6 (for-each #<procedure primitive-load (_)> _)
>     In unknown file:
>                5 (primitive-load "/gnu/store/ql1xjxrssxm51z2bn2v6l3mlrncij84h-activate-service")
>     In ice-9/eval.scm:
>         619:8  4 (_ #f)
>        196:35  3 (_ #f)
>        196:27  2 (_ #f)
>        223:20  1 (proc #<directory (guile-user) 1fa4140>)
>     In unknown file:
>                0 (%resolve-variable (7 . cut) #<directory (guile-user) 1fa4140>)
>     
>     ERROR: In procedure %resolve-variable:
>     error: cut: unbound variable
>     
>     Reported-by: Alex McGrath on #guix.
>     
>     * gnu/services/nix.scm (nix-activation): Import and use (srfi srfi-26).

FWIW, I don't think we should normally have backtraces like this in our
commit log.  Certainly in this case, the error was sufficiently obvious,
and the backtrace doesn't add much useful information.

What do you think?

      Regards,
        Mark

Re: 01/01: services: Add SRFI-26 to Nix activation gexp.

[Tobias Geerinckx-Rice]

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

Mark,

Mark H Weaver wrote:
> guix-commits@gnu.org writes:
>
>> nckx pushed a commit to branch master
>> in repository guix.
>>
>> commit 2be6b5e2eea9ac084cc22281f64f7a089e46cdae
>> Author: Tobias Geerinckx-Rice <me@tobias.gr>
>> Date:   Tue Jun 11 20:50:37 2019 +0200
>>
>>     services: Add SRFI-26 to Nix activation gexp.
>>     
>>     Fix the following fatal error on ‘guix system reconfigure’:
>>     

[Huge backtrace snipped, who adds stuff like that.]

>>     * gnu/services/nix.scm (nix-activation): Import and use 
>>     (srfi srfi-26).
>
> FWIW, I don't think we should normally have backtraces like this 
> in our
> commit log.  Certainly in this case, the error was sufficiently 
> obvious,
> and the backtrace doesn't add much useful information.

I included it because (this implies there was more deliberation 
involved than there was) the bug was reported on IRC, in an 
ephemeral paste.  For the record, I wouldn't have done so if 
there'd been a regular bug report.

> What do you think?

Nothing, really.  I have so many opinions already, I can't bring 
myself to have one on this matter.  Whatever you say :-)

Kind regards,

T G-R

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