Subject: Re: bug#64745: [guix-past] channel derivation broken after recent u-boot update

From: Vagrant Cascadian <[email-masked]>
Date: Thu, 20 Jul 2023 16:08:19 -0700

On 2023-07-21, Ludovic Courtès wrote:
> Maxim Cournoyer <[email-masked]> 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