‘guix shell --system=ALIEN’ builds for both systems

Done

Details

5 participants

Josselin Poiret
Ludovic Courtès
Maxim Cournoyer
Tobias Geerinckx-Rice
Simon Tournier

Owner: unassigned

Submitted by: Tobias Geerinckx-Rice

Severity: important

Tobias Geerinckx-Rice wrote on 11 Aug 2023 13:10

‘guix shell --system=ALIEN’ builds f or both systems

Recipients:(address . bug-guix@gnu.org)

Message-ID:a5a1d7c689b975e5941abed23e7f6b85@tobias.gr

Hi,

ekaitz noticed this when building a mes-derived package that fails on

x86_64. Here's a reproducer that uses upstream Guix:

$ guix shell --system=riscv64-linux drawterm --no-grafts --rebuild-cache

--dry-run | grep drv$

/gnu/store/4c02fgswkbldys93w4vgj0gwax2ly4bh-profile.drv

$ guix build --dry-run

/gnu/store/4c02fgswkbldys93w4vgj0gwax2ly4bh-profile.drv | grep drawterm

/gnu/store/mkxyhjq117wdalc0gbz4468blqxih1kn-drawterm-20210628-1.c97fe46

/gnu/store/h8dk35aw2n8rj1hki6dkdrknfly26vq8-drawterm-20210628-1.c97fe46

/gnu/store/fl4iimlcdnlkarjm8m6z3392wss6b8yr-drawterm-20210628-1.c97fe46.drv

→

/gnu/store/mkxyhjq117wdalc0gbz4468blqxih1kn-drawterm-20210628-1.c97fe46

is riscv64-linux.

/gnu/store/9a1pji59hzacrmpb65nk3pp3m01niqf3-drawterm-20210628-1.c97fe46.drv

→

/gnu/store/h8dk35aw2n8rj1hki6dkdrknfly26vq8-drawterm-20210628-1.c97fe46

is x86_64-linux.

Eventually the ‘correct’ riscv64 drawterm ends up in the shell, but Guix

should never have built the x86_64 version.

Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

Tobias Geerinckx-Rice wrote on 11 Aug 2023 13:43

Re: ‘guix shell --system=ALIEN’ bu ilds for both systems

Recipients:(address . 65225@debbugs.gnu.org)

Message-ID:b30d30bc7d40461e8cf9243007fa8666@tobias.gr

Oh, OK.

Parts of scripts/shell.scm (and perhaps environment.scm) assume that

$ guix build --system={x86_64,riscv64}-linux foo

is equivalent to

$ guix build --system=riscv64-linux foo

It's not. This includes and causes things like commit

9c513303156b418567b9d2cde9f8df66190051ac. There's a lot of fast & loose

assoc-reffing going on here that makes me nervous.

Anyway, I'll get me to a PC and then fix the code that's injecting a

spurious extra ‘(system . (%current-system))’ that's causing these

double builds. Simple™.

Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

Tobias Geerinckx-Rice wrote on 11 Aug 2023 17:58

Recipients:(address . 65225@debbugs.gnu.org)

Message-ID:f5844d29b8f03e19135b696bfe36b27d@tobias.gr

Oh OK.

Toggle quote (3 lines)

> the code that's injecting a spurious extra ‘(system .

> (%current-system))’ that's causing these double builds

is not actually the problem. Instead, the profile hooks are

unconditionally built for the host's (%current-system). Forcing them to

match ‘--system=’ does the trick. Simple™!

Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

Tobias Geerinckx-Rice wrote on 6 Aug 2023 02:00

[PATCH] environment: Build the profile for the requested system.

Recipients:(address . 65225@debbugs.gnu.org)

Message-ID:2f29e4cbc33a82509a5980bc5ddd5f8ae53cf113.1691280000.git.me@tobias.gr

Previously, ‘--system=’ did not affect profile hooks, meaning that all

packages would be built for both the host and requested systems.

* guix/scripts/environment.scm (guix-environment*): Parameterize

%current-system to match the requested ‘--system=’.

Reported by ekaitz in #guix.

---

guix/scripts/environment.scm | 3 ++-

1 file changed, 2 insertions(+), 1 deletion(-)

Toggle diff (18 lines)diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index 9712389842..27f7e53549 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -1146,7 +1146,8 @@ (define (guix-environment* opts)
           (warning (G_ "no packages specified; creating an empty environment~%")))
 
         ;; Use the bootstrap Guile when requested.
-        (parameterize ((%graft? (assoc-ref opts 'graft?))
+        (parameterize ((%current-system system)
+                       (%graft? (assoc-ref opts 'graft?))
                        (%guile-for-build
                         (and store-needed?
                              (package-derivation

base-commit: 9e71d4fd6b3893ae87cb079b57d7a8fe6e9e7914
-- 
2.41.0

Josselin Poiret wrote on 12 Aug 2023 12:33

Recipients:

Message-ID:871qg8o8hi.fsf@jpoiret.xyz

Hi Tobias,

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

Toggle quote (30 lines)> Previously, ‘--system=’ did not affect profile hooks, meaning that all
> packages would be built for both the host and requested systems.
>
> * guix/scripts/environment.scm (guix-environment*): Parameterize
> %current-system to match the requested ‘--system=’.
>
> Reported by ekaitz in #guix.
> ---
>  guix/scripts/environment.scm | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
> index 9712389842..27f7e53549 100644
> --- a/guix/scripts/environment.scm
> +++ b/guix/scripts/environment.scm
> @@ -1146,7 +1146,8 @@ (define (guix-environment* opts)
>            (warning (G_ "no packages specified; creating an empty environment~%")))
>  
>          ;; Use the bootstrap Guile when requested.
> -        (parameterize ((%graft? (assoc-ref opts 'graft?))
> +        (parameterize ((%current-system system)
> +                       (%graft? (assoc-ref opts 'graft?))
>                         (%guile-for-build
>                          (and store-needed?
>                               (package-derivation
>
> base-commit: 9e71d4fd6b3893ae87cb079b57d7a8fe6e9e7914
> -- 
> 2.41.0

So, I've looked into this deeper because this fix didn't seem satisfying

to me: it suggests that the implementation of profile-derivation itself

is wrong, and I wanted to fix it instead. Here's what I uncovered:

%current-system (applies mutatis mutandis to %current-target-system)

is a Guile parameter. That means that it is accessed through a function

call, and its values really depends on where that function call occurs.

Now, this interacts with the store monad in a cumbersome way: monadic

values in this case are functions (lambda (store) ...) returning two

values, the actual output and the store. These functions are run only

at the run-with-store call.

Now, there are two non-equivalent ways of getting the current system in

a monadic context. You can either do

(mlet ((system -> (%current-system))

...)

(mlet ((system (current-system))

...)

The former directly evaluates (%current-system), while the latter only

evaluates (%current-system) when the monadic value is run!

What does this mean for our case here? Well, the problem lies with how

the hooks are lowered: they use (gexp->derivation ...) without the

optional #:system keyword. This looks up the current system at call

time with the mlet -> construct, so everything should be okay, right?

Well, the hooks are run through a mapm/accumulate-builds call, which

puts everything in a monadic value, effectively delaying the look-up

until monadic run time.

Toggle snippet (9 lines)

(mlet* %store-monad (...

(extras (if (null? (manifest-entries manifest))

(return '())

(mapm/accumulate-builds (lambda (hook)

(hook manifest))

hooks))))

...)

At this point, I thought: “Well, I could just parameterize
%current-system inside the (lambda (hook) ...), and all would be well,
right?  Well, it didn't seem to work and I was pretty confused by it.  I
tested a bit and noticed that actually, contrary to what was intended
(there even is a comment in gexp-derivation about it), gexp-derivation
looks up the system at monadic run time!  It looks like this:

Toggle snippet (13 lines)

(mlet* %store-monad ( ;; The following binding forces '%current-system' and

;; '%current-target-system' to be looked up at >>=

;; time.

(graft? (set-grafting graft?))

(system -> (or system (%current-system)))

(target -> (if (eq? target 'current)

(%current-target-system)

target))

...)

Well, the issue here is that such an mlet starts by translating the
graft? binding into a >>= call, which ends up putting the rest of the
translation into a function call that will *not* be called until the
monadic value is run.  That means that the system and target bindings
afterwards are *not* looked up at call time but at monadic run time!
And sure enough, moving the (graft? ...) binding after the (target ->
...) one does solve this!

IMO, this is way too complicated to keep in mind at all times, and there
are bugs lurking under the surface absolutely everywhere, waiting for a
corner case to be uncovered.

I'll send a new patch once I've fixed and tested this further.

Best,
-- 
Josselin Poiret

Josselin Poiret wrote on 12 Aug 2023 12:42

Recipients:

Message-ID:87wmy0mtho.fsf@jpoiret.xyz

Hi everyone,

Actually, let me add a big erratum, since it appears I misread the

intention of gexp->derivation (and realized 2 minutes after writing the

previous email).

Josselin Poiret <dev@jpoiret.xyz> writes:

Toggle quote (20 lines)> --8<---------------cut here---------------start------------->8---
> (mlet* %store-monad ( ;; The following binding forces '%current-system' and
>                      ;; '%current-target-system' to be looked up at >>=
>                      ;; time.
>                      (graft?    (set-grafting graft?))
>
>                      (system -> (or system (%current-system)))
>                      (target -> (if (eq? target 'current)
>                                     (%current-target-system)
>                                     target))
>                      ...)
>   ...)
> --8<---------------cut here---------------end--------------->8---
>
> Well, the issue here is that such an mlet starts by translating the
> graft? binding into a >>= call, which ends up putting the rest of the
> translation into a function call that will *not* be called until the
> monadic value is run.  That means that the system and target bindings
> afterwards are *not* looked up at call time but at monadic run time!

This is actually what the comment above hints at, I misunderstood its

meaning. It seems that this piece of code used to be (before 2015)

Toggle snippet (13 lines)

(mlet* %store-monad ( ;; The following binding forces '%current-system' and

;; '%current-target-system' to be looked up at >>=

;; time.

(unused (return #f)

(system -> (or system (%current-system)))

(target -> (if (eq? target 'current)

(%current-target-system)

target))

...)

probably at a time when (current-system) didn't exist.  In turn, this
means that gexp->derivation intentionally delays getting the current
system to monadic run time.  Thus, we probably need to pass an optional
#:system argument to the hooks that they can forward to
gexp->derivation to fix this “properly”

Toggle quote (4 lines)

> IMO, this is way too complicated to keep in mind at all times, and there

> are bugs lurking under the surface absolutely everywhere, waiting for a

> corner case to be uncovered.

My comment still stands.

Best,

Josselin Poiret

Ludovic Courtès wrote on 12 Aug 2023 22:51

Recipients:(name . Josselin Poiret)(address . dev@jpoiret.xyz)

Message-ID:87bkfcdlwi.fsf@gnu.org

Hi,

Josselin Poiret <dev@jpoiret.xyz> skribis:

Toggle quote (4 lines)

> IMO, this is way too complicated to keep in mind at all times, and there

> are bugs lurking under the surface absolutely everywhere, waiting for a

> corner case to be uncovered.

Great writeup! Yeah, that’s the sad situation of mixing parameters and

monads; it’s a longstanding issue and as you write, there have been

bugs. The solution to these has been primarily to avoid relying on

default values and pass explicit values. The other trick is what

‘lower-gexp’ does, with the comment you quoted, or what

‘gexp->derivation’ does.

The good news is that the monadic interface is kept internal

and not really exposed to users, who should stick to file-like objects

as much as possible.

Back to profile hooks: it seems that passing #:system #f to

‘gexp->derivation’ in each of these hooks would solve the problem, no?

Alternatively, each hook could take ‘system’ as a second argument.

Willing to give it a shot?

Thanks,

Ludo’.

Ludovic Courtès wrote on 19 Oct 2023 16:37

control message for bug #65225

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87pm1a3cg1.fsf@gnu.org

severity 65225 important

quit

Ludovic Courtès wrote on 19 Oct 2023 16:48

[PATCH 0/2] Build profile hooks for the right system

Recipients:(address . guix-patches@gnu.org)

Message-ID:cover.1697726601.git.ludo@gnu.org

Hello Guix,

This fixes https://issues.guix.gnu.org/65225, ensuring that profile

hooks are built for the right system. It does so by passing each

profile hook the targeted system.

Thoughts?

Thanks,

Ludo'.

Ludovic Courtès (2):

packages: Add ‘system’ parameter for ‘set-guile-for-build’.

profiles: Hooks honor the #:system parameter of ‘profile-derivation’.

gnu/bootloader.scm | 5 +++--

guix/channels.scm | 3 ++-

guix/packages.scm | 7 ++++---

guix/profiles.scm | 49 ++++++++++++++++++++++++++++++----------------

tests/profiles.scm | 24 ++++++++++++++++++++++-

5 files changed, 64 insertions(+), 24 deletions(-)

base-commit: 8d6b3dd0b863ccada887da8cd347727dd04cb456

2.41.0

Maxim Cournoyer wrote on 21 Oct 2023 00:46

Re: bug#65225: ‘guix shell --system =ALIEN’ builds for both systems

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:87v8b0gbf4.fsf@gmail.com

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (22 lines)> Hello Guix,
>
> This fixes <https://issues.guix.gnu.org/65225>, ensuring that profile
> hooks are built for the right system.  It does so by passing each
> profile hook the targeted system.
>
> Thoughts?
>
> Thanks,
> Ludo'.
>
> Ludovic Courtès (2):
>   packages: Add ‘system’ parameter for ‘set-guile-for-build’.
>   profiles: Hooks honor the #:system parameter of ‘profile-derivation’.
>
>  gnu/bootloader.scm |  5 +++--
>  guix/channels.scm  |  3 ++-
>  guix/packages.scm  |  7 ++++---
>  guix/profiles.scm  | 49 ++++++++++++++++++++++++++++++----------------
>  tests/profiles.scm | 24 ++++++++++++++++++++++-
>  5 files changed, 64 insertions(+), 24 deletions(-)

I see the cover letter, but not the patches :-). Where did they go?

Thanks,

Maxim

Simon Tournier wrote on 23 Oct 2023 12:16

Recipients:

Message-ID:87edhllk33.fsf@gmail.com

Hi Maxim,

On Fri, 20 Oct 2023 at 18:46, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

Toggle quote (2 lines)

> I see the cover letter, but not the patches :-). Where did they go?

They are in #66640 [1]. The cover letter had been CC:

65225@debbugs.gnu.org, I guess.

1: https://issues.guix.gnu.org/issue/66640

Cheers,

simon

Simon Tournier wrote on 23 Oct 2023 12:36

Re: [bug#66640] [PATCH 0/2] Build profile hooks for the right system

Recipients:

Message-ID:875y2xlj5r.fsf@gmail.com

Hi Ludo,

A naive question about the default value.

On Thu, 19 Oct 2023 at 16:48, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (2 lines)

> packages: Add ‘system’ parameter for ‘set-guile-for-build’.

The change reads,

Toggle snippet (6 lines)

+(define* (set-guile-for-build guile #:optional system)

[...]

+ (let ((guile (package-derivation store guile

+ (or system (%current-system)))))

Toggle quote (2 lines)

> profiles: Hooks honor the #:system parameter of ‘profile-derivation’.

The change reads for all hooks,

Toggle snippet (7 lines)

+ (define* (efi-bootloader-profile-hook manifest #:optional system)

[...]

(gexp->derivation "efi-bootloader-profile"

build

+ #:system system

Do I understand correctly when I consider that

’(efi-bootloader-profile-hook manifest)’ pass #false as ’system’ and

then it is ’set-guile-for-build’ that sets ’(%current-system)’?

Somehow, my question is about the readability of default values.

Why not,

#:system (or system (%current-system))

for all the hooks?

Cheers,

simon

Maxim Cournoyer wrote on 23 Oct 2023 16:29

Re: bug#65225: ‘guix shell --system =ALIEN’ builds for both systems

Recipients:(name . Simon Tournier)(address . zimon.toutoune@gmail.com)

Message-ID:87a5s98l9i.fsf@gmail.com

Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> writes:

Toggle quote (9 lines)

> Hi Maxim,

> On Fri, 20 Oct 2023 at 18:46, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

>> I see the cover letter, but not the patches :-). Where did they go?

> They are in #66640 [1]. The cover letter had been CC:

> 65225@debbugs.gnu.org, I guess.

Thanks!

Maxim

Ludovic Courtès wrote on 23 Oct 2023 21:53

Re: [bug#66640] [PATCH 0/2] Build profile hooks for the right system

Recipients:(name . Simon Tournier)(address . zimon.toutoune@gmail.com)

Message-ID:87bkcpf74t.fsf@gnu.org

Simon Tournier <zimon.toutoune@gmail.com> skribis:

Toggle quote (4 lines)

> Do I understand correctly when I consider that

> ’(efi-bootloader-profile-hook manifest)’ pass #false as ’system’ and

> then it is ’set-guile-for-build’ that sets ’(%current-system)’?

Yes.

Toggle quote (8 lines)

> Somehow, my question is about the readability of default values.

> Why not,

> #:system (or system (%current-system))

> for all the hooks?

Because that value would be captured at call time rather than at

monadic-bind time. See Josselin’s excellent explanation of this trap:

https://issues.guix.gnu.org/65225#4-lineno34

HTH!

Ludo’.

Simon Tournier wrote on 24 Oct 2023 20:34

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:878r7rj2d4.fsf@gmail.com

Hi,

On Mon, 23 Oct 2023 at 21:53, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (5 lines)

> Because that value would be captured at call time rather than at

> monadic-bind time. See Josselin’s excellent explanation of this trap:

> https://issues.guix.gnu.org/65225#4-lineno34

Yeah, all clear. Thank you.

Before the patch:

Toggle snippet (49 lines)$ guix shell --system=riscv64-linux sterm --no-grafts --rebuild-cache --dry-run 2>&1 | grep profile
  /gnu/store/0l02iwcq3bzh38qykg70ygy5cf5c2hml-profile.drv

$ guix repl
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,run-in-store (references* "/gnu/store/0l02iwcq3bzh38qykg70ygy5cf5c2hml-profile.drv")
$1 = ("/gnu/store/4zg87dbcf7mcr82jlbfsbqqffn1miaml-ca-certificate-bundle.drv"
 "/gnu/store/5myp281kr169dag03plk5wy0s1jmkk40-emacs-subdirs.drv"
 "/gnu/store/7s9j9ns9mmfg0vg8wpjvjj0x8rrq992f-info-dir.drv"
 "/gnu/store/8q36aw38kr2879ll9zrn3cg7w5xpxmjd-module-import"
 "/gnu/store/bvnibpf0kfk2w4vh069q97mk98q3pwbz-profile-builder"
 "/gnu/store/fw22lk3vnal8477lpbi0f5wfgh8i1w6f-fonts-dir.drv"
 "/gnu/store/j0vmqz44kmsp8jhpxw8wa4jq60rjfgaj-module-import-compiled.drv"
 "/gnu/store/s38y5afcy2bwzsspqsz2n4riiqy77gr4-sterm-20200306.drv"
 "/gnu/store/x6qzhxy1wilipnlygi508l9yvz66dlvs-glibc-utf8-locales-2.35.drv"
 "/gnu/store/zraigp7miin3vzr5dcbr4i9rvds0i07r-guile-3.0.9.drv")
scheme@(guix-user)> $1
;;; <stdin>:4:0: warning: possibly unbound variable `$1'
$2 = ("/gnu/store/4zg87dbcf7mcr82jlbfsbqqffn1miaml-ca-certificate-bundle.drv" "/gnu/store/5myp281kr169dag03plk5wy0s1jmkk40-emacs-subdirs.drv" "/gnu/store/7s9j9ns9mmfg0vg8wpjvjj0x8rrq992f-info-dir.drv" "/gnu/store/8q36aw38kr2879ll9zrn3cg7w5xpxmjd-module-import" "/gnu/store/bvnibpf0kfk2w4vh069q97mk98q3pwbz-profile-builder" "/gnu/store/fw22lk3vnal8477lpbi0f5wfgh8i1w6f-fonts-dir.drv" "/gnu/store/j0vmqz44kmsp8jhpxw8wa4jq60rjfgaj-module-import-compiled.drv" "/gnu/store/s38y5afcy2bwzsspqsz2n4riiqy77gr4-sterm-20200306.drv" "/gnu/store/x6qzhxy1wilipnlygi508l9yvz66dlvs-glibc-utf8-locales-2.35.drv" "/gnu/store/zraigp7miin3vzr5dcbr4i9rvds0i07r-guile-3.0.9.drv")
scheme@(guix-user)> ,pp (map (lambda (drv) (list drv (or (not (string-suffix? ".drv" drv)) (derivation-system (read-derivation-from-file drv))))) $1)
$3 = (("/gnu/store/4zg87dbcf7mcr82jlbfsbqqffn1miaml-ca-certificate-bundle.drv"
  "x86_64-linux")
 ("/gnu/store/5myp281kr169dag03plk5wy0s1jmkk40-emacs-subdirs.drv"
  "x86_64-linux")
 ("/gnu/store/7s9j9ns9mmfg0vg8wpjvjj0x8rrq992f-info-dir.drv"
  "x86_64-linux")
 ("/gnu/store/8q36aw38kr2879ll9zrn3cg7w5xpxmjd-module-import"
  #t)
 ("/gnu/store/bvnibpf0kfk2w4vh069q97mk98q3pwbz-profile-builder"
  #t)
 ("/gnu/store/fw22lk3vnal8477lpbi0f5wfgh8i1w6f-fonts-dir.drv"
  "x86_64-linux")
 ("/gnu/store/j0vmqz44kmsp8jhpxw8wa4jq60rjfgaj-module-import-compiled.drv"
  "riscv64-linux")
 ("/gnu/store/s38y5afcy2bwzsspqsz2n4riiqy77gr4-sterm-20200306.drv"
  "riscv64-linux")
 ("/gnu/store/x6qzhxy1wilipnlygi508l9yvz66dlvs-glibc-utf8-locales-2.35.drv"
  "riscv64-linux")
 ("/gnu/store/zraigp7miin3vzr5dcbr4i9rvds0i07r-guile-3.0.9.drv"
  "x86_64-linux"))

After the patch:

Toggle snippet (49 lines)$ ./pre-inst-env guix shell --system=riscv64-linux sterm --no-grafts --rebuild-cache --dry-run 2>&1 | grep profile
  /gnu/store/1nnji4fr8mgpsal0rcnzbdjdm4p04yk3-profile.drv

$ guix repl
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,run-in-store (references* "/gnu/store/1nnji4fr8mgpsal0rcnzbdjdm4p04yk3-profile.drv")
$1 = ("/gnu/store/2ff9j170rckkr2zs0l6sf4bbkx7fk5vc-profile-builder"
 "/gnu/store/5mi4ij2vf5cxhsbh52n04h48mvc6z6r8-module-import-compiled.drv"
 "/gnu/store/5sbcg8siv5jzzbdy4m7bfravpxg95j7h-emacs-subdirs.drv"
 "/gnu/store/7rz0kd6bigj3gdlp9l4z1v91sxy43bib-fonts-dir.drv"
 "/gnu/store/8l03g4sg271c0wc2axhpn689r6faa0ij-info-dir.drv"
 "/gnu/store/94ad504y18rg0d1kgznlj0ib1l56ljxl-ca-certificate-bundle.drv"
 "/gnu/store/w314gb2gc9z6jd9ng7gpn88zvhhsax09-sterm-20200306.drv"
 "/gnu/store/x6qzhxy1wilipnlygi508l9yvz66dlvs-glibc-utf8-locales-2.35.drv"
 "/gnu/store/y545dx7df92al3yz1a9swnf0lhjg9igi-module-import"
 "/gnu/store/zb3vrbwv8qx9430n839ljbalnik8019g-guile-3.0.9.drv")
scheme@(guix-user)> $1
;;; <stdin>:2:0: warning: possibly unbound variable `$1'
$2 = ("/gnu/store/2ff9j170rckkr2zs0l6sf4bbkx7fk5vc-profile-builder" "/gnu/store/5mi4ij2vf5cxhsbh52n04h48mvc6z6r8-module-import-compiled.drv" "/gnu/store/5sbcg8siv5jzzbdy4m7bfravpxg95j7h-emacs-subdirs.drv" "/gnu/store/7rz0kd6bigj3gdlp9l4z1v91sxy43bib-fonts-dir.drv" "/gnu/store/8l03g4sg271c0wc2axhpn689r6faa0ij-info-dir.drv" "/gnu/store/94ad504y18rg0d1kgznlj0ib1l56ljxl-ca-certificate-bundle.drv" "/gnu/store/w314gb2gc9z6jd9ng7gpn88zvhhsax09-sterm-20200306.drv" "/gnu/store/x6qzhxy1wilipnlygi508l9yvz66dlvs-glibc-utf8-locales-2.35.drv" "/gnu/store/y545dx7df92al3yz1a9swnf0lhjg9igi-module-import" "/gnu/store/zb3vrbwv8qx9430n839ljbalnik8019g-guile-3.0.9.drv")
scheme@(guix-user)> ,pp (map (lambda (drv) (list drv (or (not (string-suffix? ".drv" drv)) (derivation-system (read-derivation-from-file drv))))) $1)
$3 = (("/gnu/store/2ff9j170rckkr2zs0l6sf4bbkx7fk5vc-profile-builder"
  #t)
 ("/gnu/store/5mi4ij2vf5cxhsbh52n04h48mvc6z6r8-module-import-compiled.drv"
  "riscv64-linux")
 ("/gnu/store/5sbcg8siv5jzzbdy4m7bfravpxg95j7h-emacs-subdirs.drv"
  "riscv64-linux")
 ("/gnu/store/7rz0kd6bigj3gdlp9l4z1v91sxy43bib-fonts-dir.drv"
  "riscv64-linux")
 ("/gnu/store/8l03g4sg271c0wc2axhpn689r6faa0ij-info-dir.drv"
  "riscv64-linux")
 ("/gnu/store/94ad504y18rg0d1kgznlj0ib1l56ljxl-ca-certificate-bundle.drv"
  "riscv64-linux")
 ("/gnu/store/w314gb2gc9z6jd9ng7gpn88zvhhsax09-sterm-20200306.drv"
  "riscv64-linux")
 ("/gnu/store/x6qzhxy1wilipnlygi508l9yvz66dlvs-glibc-utf8-locales-2.35.drv"
  "riscv64-linux")
 ("/gnu/store/y545dx7df92al3yz1a9swnf0lhjg9igi-module-import"
  #t)
 ("/gnu/store/zb3vrbwv8qx9430n839ljbalnik8019g-guile-3.0.9.drv"
  "x86_64-linux"))

Therefore, it seems fixing the issue. All the x86_64-linux above are

turned as riscv64-linux. However, still a naive question:

Why ’guile’ is not? Is it expected?

If not, does it mean that some ’set-guile-for-build’ is missing?

Cheers,

simon

Ludovic Courtès wrote on 28 Oct 2023 01:36

Recipients:(name . Simon Tournier)(address . zimon.toutoune@gmail.com)

Message-ID:87h6mbab8s.fsf@gnu.org

Hi,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

Toggle quote (8 lines)

> ("/gnu/store/zb3vrbwv8qx9430n839ljbalnik8019g-guile-3.0.9.drv"

> "x86_64-linux"))

> Therefore, it seems fixing the issue. All the x86_64-linux above are

> turned as riscv64-linux. However, still a naive question:

> Why ’guile’ is not? Is it expected?

Oh, that’s another bug, this one in ‘guix shell’ (missing argument for

‘package-derivation’).

I pushed this:

344e39c928 profiles: Hooks honor the #:system parameter of ‘profile-derivation’.

9d4b720e1f packages: Add ‘system’ parameter for ‘set-guile-for-build’.

b3ec2a0d37 environment: Honor ‘-s’ for guile-for-build.

Thanks for reviewing and reporting the issue!

Ludo’.

Ludovic Courtès wrote on 28 Oct 2023 01:38

control message for bug #65225

Recipients:(address . control@debbugs.gnu.org)

Message-ID:87fs1vab6u.fsf@gnu.org

close 65225

quit

Your comment

This issue is archived.

To comment on this conversation send an email to 65225@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 65225

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date