Hi!

Vagrant Cascadian <vagrant@debian.org> writes:

> [[PGP Signed Part:Undecided]]
> On 2021-08-02, Pierre Langlois wrote:
>> Pierre Langlois <pierre.langlois@gmx.com> writes:
>>>>> That being said, while it works on pinebookpro, I still need an extra
>>>>> patch on the rockpro64 in order to boot, both on master with u-boot
>>>>> 2021.07 :-/ (see #49550).
>>>>>
>>>>> Were you able to confirm the issue? I see it looks like we have the same
>>>>> configuration in debian and guix, CONFIG_USE_PREBOOT=y and the
>>>>> "inno-usb" patch applied, mmmm
>>>>
>>>> Seems like you fixed the core of that problem in another commit!
>>>>
>>>> Patch looks good to me, thanks for working on it!
>>>
>>> Thanks for the review! I've just pushed it as
>>> eb46c6c5c81695af475f7e1e416d05e51157fe60, with a couple of tweaks to
>>> make `guix lint' happy (the patch filename was a little too long, as
>>> well as a line was over the column limit).
>
> Great!
>
>> It turns out I broke a few u-boot packages :-/ https://ci.guix.gnu.org/eval/70864?status=failed
>
> Oh well...
>
>> u-boot-tools failing to build on aarch64 appears to be unrelated, it's
>> due to libical which builds just fine for me on my rockpro64.
>
> hrm... yeah, it has been a while since libical succeeded on aarch64:
>
>   https://ci.guix.gnu.org/search?query=libical+system%3Aaarch64-linux
>
> Might be another case where the package doesn't build on some of the
> virtualized machines but builds fine on real hardware...
>
>
> Appears to have built fine on bordeaux:
>
> $ guix weather libical
> computing 1 package derivations for aarch64-linux...
> looking for 1 store items on https://ci.guix.gnu.org...
> https://ci.guix.gnu.org
>   0.0% substitutes available (0 out of 1)
>   unknown substitute sizes
>   0.0 MiB on disk (uncompressed)
>   0.723 seconds per request (0.7 seconds in total)
>   1.4 requests per second
>
>   0.0% (0 out of 1) of the missing items are queued
>   1 queued builds
>       aarch64-linux: 1 (100.0%)
>   build rate: .00 builds per hour
>       x86_64-linux: 39.79 builds per hour
>       i686-linux: 0.00 builds per hour
>       aarch64-linux: 0.00 builds per hour
> looking for 1 store items on https://bordeaux.guix.gnu.org...
> https://bordeaux.guix.gnu.org
>   100.0% substitutes available (1 out of 1)
>   0.5 MiB of nars (compressed)
>   7.4 MiB on disk (uncompressed)
>   0.872 seconds per request (0.9 seconds in total)
>   1.1 requests per second
>   (continuous integration information unavailable)
>
>
>> However u-boot-vexpress
>
> I suspect u-boot-vexpress should just be dropped. The hardware was
> always unobtanium (e.g. you can't get it even with absurd sums of
> money); the only use-case was it was a platform supported in qemu early
> on, but there are better virtualization platform options these days
> (e.g. virt)...

Oh I see, I was curious why it had been added, assuming somebody had
access to this board and probably still cared. If not, I agree let's
remove it!

>
>
>> u-boot-sifive-fu540 and u-boot-qemu-riscv64-smode are
>> real issues. Here are a couple of patches for them, they're pretty
>> trivial so I'll push them soon unless anybody objects:
>
>> From 26957dac52584457d43d6139e2edc49074c7ca44 Mon Sep 17 00:00:00 2001
>> From: Pierre Langlois <pierre.langlois@gmx.com>
>> Date: Mon, 2 Aug 2021 15:13:11 +0100
>> Subject: [PATCH 2/2] gnu: Rename u-boot-sifive-fu540 to sifive-unleashed.
>
>> * gnu/packages/bootloaders.scm (u-boot-sifive-fu540): Rename to ...
>> (u-boot-sifive-unleashed): ... this.  Change board name from sifive_fu540 to
>> sifive_unleashed.
>> * gnu/packages/patches/u-boot-riscv64-fix-extlinux.patch: Rename sifive_fu540
>> to sifive_unleashed.
>
> Ah, sorry, I should have caught this, as I had to do this in the Debian
> packages too (but an earlier upload, so not as fresh in my
> memory)...

No worries! I should have made sure to build all dependents.

>
> Patch looks good to me, for what it's worth. :)
>
> It might normally be good to make a deprecated package for the name
> change, but again, since riscv64 is so experimental in guix it is
> probably not worth cluttering up with niche deprecated packages like
> this...

SGTM!

I'll push a patch to remove the vexpress board support and the renaming
patch shortly.

Thanks,
Pierre