GNU bug report logs - #64745
[guix-past] channel derivation broken after recent u-boot update

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64745 in the body.
You can then email your comments to 64745 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: bug-guix <bug-guix <at> gnu.org>
Subject: [guix-past] channel derivation broken after recent u-boot update
Date: Thu, 20 Jul 2023 12:27:54 -0400

Hello,

It appears that the Guix-Past channel now fails to build like so:

--8<---------------cut here---------------start------------->8---
substitute: ^Msubstitute: ESC[Kupdating substitutes from 'https://ci.guix.gnu.org'...   0.0%^Msubstitute: ESC[Kupdating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: ^Msubstitute: ESC[Kupdating substitutes from 'https://bordeaux.guix.gnu.org'...   0.0%^Msubstitute: ESC[Kupdating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
@ build-started /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv - x86_64-linux /var/log/guix/drvs/5g//xx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv 4536
(repl-version 0 1 1)
(exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (crust-pine64-plus)) (value #f))
builder for `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv' failed to produce output path `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
@ build-failed /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv - 1 builder for `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv' failed to produce output path `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
--8<---------------cut here---------------end--------------->8---

I suspect it's caused by the commit
ed5dc3a25d858a394bb7db937a51d866c3cdc6ed ("gnu: u-boot: Add crust
firmware to pinebook, pine64_plus and pine64-lts."), although I don't
understand why.

-- 
Thanks,
Maxim

Message #8 received at 64745 <at> debbugs.gnu.org (full text, mbox):

From: Janneke Nieuwenhuizen <janneke <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 64745 <at> debbugs.gnu.org
Subject: Re: bug#64745: [guix-past] channel derivation broken after recent
 u-boot update
Date: Thu, 20 Jul 2023 19:58:15 +0200

Maxim Cournoyer writes:

Hi,

> It appears that the Guix-Past channel now fails to build like so:
>
> substitute: ^Msubstitute: ESC[Kupdating substitutes from 'https://ci.guix.gnu.org'...   0.0%^Msubstitute: ESC[Kupdating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: ^Msubstitute: ESC[Kupdating substitutes from 'https://bordeaux.guix.gnu.org'...   0.0%^Msubstitute: ESC[Kupdating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
> @ build-started /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv - x86_64-linux /var/log/guix/drvs/5g//xx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv 4536
> (repl-version 0 1 1)
> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (crust-pine64-plus)) (value #f))
> builder for `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv' failed to produce output path `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
> @ build-failed /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv - 1 builder for `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv' failed to produce output path `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
>
> I suspect it's caused by the commit
> ed5dc3a25d858a394bb7db937a51d866c3cdc6ed ("gnu: u-boot: Add crust
> firmware to pinebook, pine64_plus and pine64-lts."), although I don't
> understand why.

I've hit a simimilar problem when attempting to build guix
(./pre-inst-env guix build guix for x86_64) on hurd-team.

--8<---------------cut here---------------start------------->8---
[ 39%] GUILEC   gnu/packages/fsf.go
[ 39%] GUILEC   gnu/packages/ftp.go
[ 39%] GUILEC   gnu/packages/fribidi.go
[ 39%] GUILEC   gnu/packages/fvwm.go
Compiling Scheme modules...
[ 39%] LOAD     gnu/packages/game-development.scm
ice-9/eval.scm:293:34: error: crust-pine64-plus: unbound variable
hint: Did you forget a `use-modules' form?
--8<---------------cut here---------------end--------------->8---

The hurd-team branch has (two) `make update-guix-package' commits
because it has guix build fixes for the hurd.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke <at> gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Message #11 received at 64745 <at> debbugs.gnu.org (full text, mbox):

From: Janneke Nieuwenhuizen <janneke <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 64745 <at> debbugs.gnu.org
Subject: Re: bug#64745: [guix-past] channel derivation broken after recent
 u-boot update
Date: Thu, 20 Jul 2023 23:52:44 +0200

Janneke Nieuwenhuizen writes:

Hello again,

>> It appears that the Guix-Past channel now fails to build like so:
[..]
>> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (crust-pine64-plus)) (value #f))
[..]
>> I suspect it's caused by the commit
>> ed5dc3a25d858a394bb7db937a51d866c3cdc6ed ("gnu: u-boot: Add crust
>> firmware to pinebook, pine64_plus and pine64-lts."), although I don't
>> understand why.
>
> I've hit a simimilar problem when attempting to build guix
> (./pre-inst-env guix build guix for x86_64) on hurd-team.
>
> [ 39%] GUILEC   gnu/packages/fsf.go
> [ 39%] GUILEC   gnu/packages/ftp.go
> [ 39%] GUILEC   gnu/packages/fribidi.go
> [ 39%] GUILEC   gnu/packages/fvwm.go
> Compiling Scheme modules...
> [ 39%] LOAD     gnu/packages/game-development.scm
> ice-9/eval.scm:293:34: error: crust-pine64-plus: unbound variable
> hint: Did you forget a `use-modules' form?
>
> The hurd-team branch has (two) `make update-guix-package' commits
> because it has guix build fixes for the hurd.

As discussed on IRC, I can confirm ed5dc3a25d858a394bb7db937a51d866c3cdc6ed 
is causing this for me.  When I revert it before `make update-guix-package',
then the build phase of `./pre-inst-env guix build guix (x86_64)
succeeds.

Completely unrelated but sadly, the check phase fails

--8<---------------cut here---------------start------------->8---
FAIL: tests/packages.scm
FAIL: tests/store-roots.scm
FAIL: tests/texlive.scm
--8<---------------cut here---------------end--------------->8---

so I'm skipping those patches for now on hurd-team.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke <at> gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

Message #14 received at 64745 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Vagrant Cascadian <vagrant <at> debian.org>, 64745 <at> debbugs.gnu.org,
 Janneke Nieuwenhuizen <janneke <at> gnu.org>
Subject: Re: bug#64745: [guix-past] channel derivation broken after recent
 u-boot update
Date: Fri, 21 Jul 2023 00:16:01 +0200

Hi,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> It appears that the Guix-Past channel now fails to build like so:
>
> substitute: ^Msubstitute: ESC[Kupdating substitutes from 'https://ci.guix.gnu.org'...   0.0%^Msubstitute: ESC[Kupdating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: ^Msubstitute: ESC[Kupdating substitutes from 'https://bordeaux.guix.gnu.org'...   0.0%^Msubstitute: ESC[Kupdating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
> @ build-started /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv - x86_64-linux /var/log/guix/drvs/5g//xx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv 4536
> (repl-version 0 1 1)
> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (crust-pine64-plus)) (value #f))
> builder for `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv' failed to produce output path `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
> @ build-failed /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv - 1 builder for `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv' failed to produce output path `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
>
> I suspect it's caused by the commit
> ed5dc3a25d858a394bb7db937a51d866c3cdc6ed ("gnu: u-boot: Add crust
> firmware to pinebook, pine64_plus and pine64-lts."), although I don't
> understand why.

This can be reproduced like so:

--8<---------------cut here---------------start------------->8---
$ guix time-machine --commit=a4038c4f783b05040cfdb262d9f4c0119b612371 -- repl <(echo '(use-modules (gnu packages firmware))')
Backtrace:
In ice-9/boot-9.scm:
   222:29 19 (map1 (((gnu packages acl)) ((gnu packages admin)) ((gnu packages assembly)) ((gnu packages attr)) ((gnu packages autotools)) ((gnu packages backup)) ((gnu # #)) # …))
   222:29 18 (map1 (((gnu packages admin)) ((gnu packages assembly)) ((gnu packages attr)) ((gnu packages autotools)) ((gnu packages backup)) ((gnu packages base)) ((gnu # #)) # …))
   222:29 17 (map1 (((gnu packages assembly)) ((gnu packages attr)) ((gnu packages autotools)) ((gnu packages backup)) ((gnu packages base)) ((gnu packages bash)) ((gnu # #)) # …))
   222:29 16 (map1 (((gnu packages attr)) ((gnu packages autotools)) ((gnu packages backup)) ((gnu packages base)) ((gnu packages bash)) ((gnu packages bison)) ((gnu # #)) ((…)) …))
   222:29 15 (map1 (((gnu packages autotools)) ((gnu packages backup)) ((gnu packages base)) ((gnu packages bash)) ((gnu packages bison)) ((gnu packages bootloaders)) ((gnu …)) …))
   222:29 14 (map1 (((gnu packages backup)) ((gnu packages base)) ((gnu packages bash)) ((gnu packages bison)) ((gnu packages bootloaders)) ((gnu packages build-tools)) ((# …)) …))
   222:29 13 (map1 (((gnu packages base)) ((gnu packages bash)) ((gnu packages bison)) ((gnu packages bootloaders)) ((gnu packages build-tools)) ((gnu packages check)) ((gnu …)) …))
   222:29 12 (map1 (((gnu packages bash)) ((gnu packages bison)) ((gnu packages bootloaders)) ((gnu packages build-tools)) ((gnu packages check)) ((gnu packages cluster)) ((…)) …))
   222:29 11 (map1 (((gnu packages bison)) ((gnu packages bootloaders)) ((gnu packages build-tools)) ((gnu packages check)) ((gnu packages cluster)) ((gnu packages cmake)) ((…)) …))
   222:17 10 (map1 (((gnu packages bootloaders)) ((gnu packages build-tools)) ((gnu packages check)) ((gnu packages cluster)) ((gnu packages cmake)) ((gnu packages #)) ((gnu …)) …))
  3327:17  9 (resolve-interface (gnu packages bootloaders) #:select _ #:hide _ #:prefix _ #:renamer _ #:version _)
In ice-9/threads.scm:
    390:8  8 (_ _)
In ice-9/boot-9.scm:
  3253:13  7 (_)
In ice-9/threads.scm:
    390:8  6 (_ _)
In ice-9/boot-9.scm:
  3544:20  5 (_)
   2836:4  4 (save-module-excursion #<procedure 7f15e679c150 at ice-9/boot-9.scm:3545:21 ()>)
  3564:26  3 (_)
In unknown file:
           2 (primitive-load-path "gnu/packages/bootloaders" #<procedure 7f15e68a0c00 at ice-9/boot-9.scm:3551:37 ()>)
In gnu/packages/bootloaders.scm:
  1061:31  1 (_)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
error: crust-pine64-plus: unbound variable
--8<---------------cut here---------------end--------------->8---

This is the dreaded “circular top-level references” case: to load
firmware.scm, you need to (indirectly) load bootloaders.scm; but to load
bootloader.scm, you need to be able to look up ‘crust-pine64-plus’,
which is then unbound.

Fixed in 0ab46ef3f9719f03d9b191a16e5aa91619e95451 by introducing
promises.

BTW, we should probably keep ‘make-u-boot-sunxi64-package’ private, no?

Thanks,
Ludo’.

Message #19 received at 64745 <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Ludovic Courtès <ludo <at> gnu.org>, Maxim Cournoyer
 <maxim.cournoyer <at> gmail.com>
Cc: 64745 <at> debbugs.gnu.org, Janneke Nieuwenhuizen <janneke <at> gnu.org>
Subject: Re: bug#64745: [guix-past] channel derivation broken after recent
 u-boot update
Date: Thu, 20 Jul 2023 16:08:19 -0700

[Message part 1 (text/plain, inline)]

On 2023-07-21, Ludovic Courtès wrote:
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> It appears that the Guix-Past channel now fails to build like so:
>>
>> substitute: ^Msubstitute: ESC[Kupdating substitutes from 'https://ci.guix.gnu.org'...   0.0%^Msubstitute: ESC[Kupdating substitutes from 'https://ci.guix.gnu.org'... 100.0%
>> substitute: ^Msubstitute: ESC[Kupdating substitutes from 'https://bordeaux.guix.gnu.org'...   0.0%^Msubstitute: ESC[Kupdating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
>> @ build-started /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv - x86_64-linux /var/log/guix/drvs/5g//xx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv 4536
>> (repl-version 0 1 1)
>> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (crust-pine64-plus)) (value #f))
>> builder for `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv' failed to produce output path `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
>> @ build-failed /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv - 1 builder for `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv' failed to produce output path `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
>>
>> I suspect it's caused by the commit
>> ed5dc3a25d858a394bb7db937a51d866c3cdc6ed ("gnu: u-boot: Add crust
>> firmware to pinebook, pine64_plus and pine64-lts."), although I don't
>> understand why.
>
> This can be reproduced like so:
>
> --8<---------------cut here---------------start------------->8---
> $ guix time-machine --commit=a4038c4f783b05040cfdb262d9f4c0119b612371 -- repl <(echo '(use-modules (gnu packages firmware))')
> Backtrace:
> In ice-9/boot-9.scm:
>    222:29 19 (map1 (((gnu packages acl)) ((gnu packages admin)) ((gnu packages assembly)) ((gnu packages attr)) ((gnu packages autotools)) ((gnu packages backup)) ((gnu # #)) # …))
...
> In unknown file:
>            2 (primitive-load-path "gnu/packages/bootloaders" #<procedure 7f15e68a0c00 at ice-9/boot-9.scm:3551:37 ()>)
> In gnu/packages/bootloaders.scm:
>   1061:31  1 (_)
> In ice-9/boot-9.scm:
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> error: crust-pine64-plus: unbound variable
> --8<---------------cut here---------------end--------------->8---
>
> This is the dreaded “circular top-level references” case: to load
> firmware.scm, you need to (indirectly) load bootloaders.scm; but to load
> bootloader.scm, you need to be able to look up ‘crust-pine64-plus’,
> which is then unbound.
>
> Fixed in 0ab46ef3f9719f03d9b191a16e5aa91619e95451 by introducing
> promises.

Thanks!


> BTW, we should probably keep ‘make-u-boot-sunxi64-package’ private, no?

What is different about crust-firmware vs. the various
arm-trusted-firmware packages, which have a similar relationship to
u-boot?

How... can I avoid this sort of issue in the future? It is at the very
least non-obvious to humble little me...


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #22 received at 64745 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Vagrant Cascadian <vagrant <at> debian.org>, 64745 <at> debbugs.gnu.org,
 Janneke Nieuwenhuizen <janneke <at> gnu.org>
Subject: Re: bug#64745: [guix-past] channel derivation broken after recent
 u-boot update
Date: Fri, 21 Jul 2023 11:35:46 -0400

Hi Ludovic,

Thanks a lot for the prompt resolution.

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

> Hi,
>
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>> It appears that the Guix-Past channel now fails to build like so:
>>
>> substitute: ^Msubstitute: ESC[Kupdating substitutes from
>> 'https://ci.guix.gnu.org'...  0.0%^Msubstitute: ESC[Kupdating
>> substitutes from 'https://ci.guix.gnu.org'... 100.0%
>> substitute: ^Msubstitute: ESC[Kupdating substitutes from
>> 'https://bordeaux.guix.gnu.org'...  0.0%^Msubstitute: ESC[Kupdating
>> substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
>> @ build-started
>> /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv -
>> x86_64-linux
>> /var/log/guix/drvs/5g//xx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv
>> 4536
>> (repl-version 0 1 1)
>> (exception unbound-variable (value #f) (value "Unbound variable:
>> ~S") (value (crust-pine64-plus)) (value #f))
>> builder for
>> `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv' failed
>> to produce output path
>> `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
>> @ build-failed
>> /gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv - 1
>> builder for
>> `/gnu/store/5gxx0xnrncdg5rsi00j4bvy4frxpd466-guix-past.drv' failed
>> to produce output path
>> `/gnu/store/hwfy6kbh8q7v9ljam99gfzaz46lf3i8z-guix-past'
>>
>> I suspect it's caused by the commit
>> ed5dc3a25d858a394bb7db937a51d866c3cdc6ed ("gnu: u-boot: Add crust
>> firmware to pinebook, pine64_plus and pine64-lts."), although I don't
>> understand why.
>
> This can be reproduced like so:
>
> $ guix time-machine --commit=a4038c4f783b05040cfdb262d9f4c0119b612371 -- repl <(echo '(use-modules (gnu packages firmware))')
> Backtrace:
> In ice-9/boot-9.scm:
>    222:29 19 (map1 (((gnu packages acl)) ((gnu packages admin)) ((gnu packages assembly)) ((gnu packages attr)) ((gnu packages autotools)) ((gnu packages backup)) ((gnu # #)) # …))
>    222:29 18 (map1 (((gnu packages admin)) ((gnu packages assembly)) ((gnu packages attr)) ((gnu packages autotools)) ((gnu packages backup)) ((gnu packages base)) ((gnu # #)) # …))
>    222:29 17 (map1 (((gnu packages assembly)) ((gnu packages attr)) ((gnu packages autotools)) ((gnu packages backup)) ((gnu packages base)) ((gnu packages bash)) ((gnu # #)) # …))
>    222:29 16 (map1 (((gnu packages attr)) ((gnu packages autotools)) ((gnu packages backup)) ((gnu packages base)) ((gnu packages bash)) ((gnu packages bison)) ((gnu # #)) ((…)) …))
>    222:29 15 (map1 (((gnu packages autotools)) ((gnu packages backup)) ((gnu packages base)) ((gnu packages bash)) ((gnu packages bison)) ((gnu packages bootloaders)) ((gnu …)) …))
>    222:29 14 (map1 (((gnu packages backup)) ((gnu packages base)) ((gnu packages bash)) ((gnu packages bison)) ((gnu packages bootloaders)) ((gnu packages build-tools)) ((# …)) …))
>    222:29 13 (map1 (((gnu packages base)) ((gnu packages bash)) ((gnu packages bison)) ((gnu packages bootloaders)) ((gnu packages build-tools)) ((gnu packages check)) ((gnu …)) …))
>    222:29 12 (map1 (((gnu packages bash)) ((gnu packages bison)) ((gnu packages bootloaders)) ((gnu packages build-tools)) ((gnu packages check)) ((gnu packages cluster)) ((…)) …))
>    222:29 11 (map1 (((gnu packages bison)) ((gnu packages bootloaders)) ((gnu packages build-tools)) ((gnu packages check)) ((gnu packages cluster)) ((gnu packages cmake)) ((…)) …))
>    222:17 10 (map1 (((gnu packages bootloaders)) ((gnu packages build-tools)) ((gnu packages check)) ((gnu packages cluster)) ((gnu packages cmake)) ((gnu packages #)) ((gnu …)) …))
>   3327:17  9 (resolve-interface (gnu packages bootloaders) #:select _ #:hide _ #:prefix _ #:renamer _ #:version _)
> In ice-9/threads.scm:
>     390:8  8 (_ _)
> In ice-9/boot-9.scm:
>   3253:13  7 (_)
> In ice-9/threads.scm:
>     390:8  6 (_ _)
> In ice-9/boot-9.scm:
>   3544:20  5 (_)
>    2836:4  4 (save-module-excursion #<procedure 7f15e679c150 at ice-9/boot-9.scm:3545:21 ()>)
>   3564:26  3 (_)
> In unknown file:
>            2 (primitive-load-path "gnu/packages/bootloaders" #<procedure 7f15e68a0c00 at ice-9/boot-9.scm:3551:37 ()>)
> In gnu/packages/bootloaders.scm:
>   1061:31  1 (_)
> In ice-9/boot-9.scm:
>   1685:16  0 (raise-exception _ #:continuable? _)
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> error: crust-pine64-plus: unbound variable
>
> This is the dreaded “circular top-level references” case: to load
> firmware.scm, you need to (indirectly) load bootloaders.scm

I suspected it had to do with top level cycles, but how did you work out
the indirect dependencies of firmware.scm on bootloaders.scm ?  I simply
thought "firmware doesn't pull the bootloaders module directly, so we
should be good".

Is there some trick (Guile traces?) to print which modules are getting
pulled or something useful to know?

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.