[bug#64149] [PATCH v3 2/6] gnu: u-boot: Update to 2023.07.02.

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi,

Vagrant Cascadian <vagrant@debian.org> writes:

> On 2023-07-14, Maxim Cournoyer wrote:
>> vagrant@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