GNU bug report logs - #64149
Update u-boot to 2023.07.02

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 64149 <at> debbugs.gnu.org, ludo <at> gnu.org, efraim <at> flashner.co.il
Subject: [bug#64149] [PATCH v3 2/6] gnu: u-boot: Update to 2023.07.02.
Date: Sat, 15 Jul 2023 23:04:28 -0400

Hi,

Vagrant Cascadian <vagrant <at> debian.org> writes:

> On 2023-07-14, Maxim Cournoyer wrote:
>> vagrant <at> debian.org writes:
>>> @@ -726,7 +725,12 @@ (define-public u-boot-tools
>>>      (name "u-boot-tools")
>>>      (native-inputs
>>>       (modify-inputs (package-native-inputs u-boot)
>>> -       (prepend python-coverage python-pycryptodomex python-pytest sdl2)))
>>> +       (prepend python-coverage
>>> +                python-filelock
>>> +                python-pycryptodomex
>>> +                python-pytest
>>> +                python-pytest-xdist
>>
>> Maybe worth checking: Is pytest invoked with the '-n' (number->string
>> (parallel-job-count)); otherwise xdist doesn't provide any benefit.
>
> Whether it is actually used is or not is one thing... but as
> implemented, it fails to build without it... :)

OK :-).

>
>>>                             ;; This test requires a sound system, which is un-used
>>>                             ;; in u-boot-tools.
>>>                             (("CONFIG_SOUND=y") "CONFIG_SOUND=n")))
>>> @@ -1009,6 +1021,8 @@ (define*-public (make-u-boot-sunxi64-package board triplet
>>>            #~(modify-phases #$phases
>>>                (add-after 'unpack 'set-environment
>>>                  (lambda* (#:key native-inputs inputs #:allow-other-keys)
>>> +                  ;; Avoid dependency on crust-firmware https://issues.guix.gnu.org/48371
>>> +                  (setenv "SCP" "/dev/null")
>>
>> I think I've seen this gets added in a later commit.  Any reason why it
>> can't be added here?
>
> Sure, the later commit coud be squashed into this one if desired. The
> initial patch was implemented before crust-firmware-* was merged, and so
> this initial workaround was necessary...

Don't bother; it was a bit weird two things changed in the same series,
but it keeps concerns a bit more separated, so it's fine as is.

>
>>> @@ -1230,7 +1257,8 @@ (define-public u-boot-rockpro64-rk3399
>>>                                                 "CONFIG_SATA_SIL=y"
>>>                                                 "CONFIG_SCSI=y"
>>>                                                 "CONFIG_SCSI_AHCI=y"
>>> -                                               "CONFIG_DM_SCSI=y"))))
>>> +                                               "CONFIG_DM_SCSI=y"
>>> +                                               "# CONFIG_SPL_FIT_SIGNATURE is not set"))))
>>>      (package
>>>        (inherit base)
>>>        (arguments
>>> @@ -1240,6 +1268,13 @@ (define-public u-boot-rockpro64-rk3399
>>>                (add-after 'unpack 'set-environment
>>>                  (lambda* (#:key inputs #:allow-other-keys)
>>>                    (setenv "BL31" (search-input-file inputs "/bl31.elf"))))
>>> +              ;; Disable SPL FIT signatures, due to GPLv2 and Openssl license
>>> +              ;; incompatibilities
>>> +              (add-after 'unpack 'disable-spl-fit-signature
>>> +                (lambda _
>>> +                  (substitute* "configs/rockpro64-rk3399_defconfig"
>>> +                    (("CONFIG_SPL_FIT_SIGNATURE=y")
>>> +                     "# CONFIG_SPL_FIT_SIGNATURE is not set"))))
>>
>> Are you sure this really disables SPL_FIT_SIGNATURE?  The #:configs
>> arguments goes through 'verify-config', which ensures an unset value
>> doesn't get pulled as a dependency of other options, if I recall
>> correctly.
>
> Without this, it spits out a nasty error, I think because
> CONFIG_SPL_FIT_SIGNATURE is effectively defined multiple times
> (e.g. "=y" in the defconfig, and "# ... is not set" in the additional
> guix options?) and maybe verify-config fails in that situation?  Sorry I
> don't have the error handy, but it was easy enough to trigger by
> dropping the 'disable-spl-fit-signature phase.

Hm.  In my experience this means some other option is pulling in (by
means of kconfig dependency resolution) the CONFIG_SPL_FIT_SIGNATURE
option and would need to also be disabled.  When faced with this problem
I usually end up navigating the 'make menuconfig' kconfig interface and
inspecting dependencies for the option at hand.

-- 
Thanks,
Maxim

Previous Next

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