On 2018-11-20, Danny Milosavljevic wrote:
> On Tue, 20 Nov 2018 13:24:18 -0800
> Vagrant Cascadian <vagrant@debian.org> wrote:
>> Summary of changes:
>> - Update arm-trusted-firmware-pine64-plus to use upstream git repository
>>   and newer commit.
>
> Hmm, okay for now - would be nice to eventually use a stable release.

Well, it will presumably be in the next release finally!

I did have a minor patch update to update arm-trusted-firmware to v2.0,
but there aren't yet any targets that can make use of that without
loosing functionality.


>> - Rename arm-trusted-firmware-pine64-plus to
>>   arm-trusted-firmware-sun50i-a64 to be consistant with upstream.
>
> OK!
>
>> - Add a make-u-boot-package-sunxi64 wrapper function based on the
>>   u-boot-pine64-plus target.
>
> OK except for the name :)

Works for me.

I did notice the os-with-u-boot and various other functions which
directly call make-u-boot-package will break with this. Though for
targets that need additions on top of make-u-boot-package anyways
(pine64, pinebook, puma-rk3399) those still break anyways.


>> - Add support for u-boot-pinebook, with patches from the u-boot sunxi
>>   maintainer tree backported to 2018.11.
>
> OK!
>
>> I wasn't sure weather some of these patches should be squashed together
>> or not (especially 1 and 2, maybe 3 and 4).
>
> I'm always trying to keep user-visible changes apart as much as possible
> (in extra commits).
>
> The reason is that if we decide to only partially apply, it's much easier
> to do it (also to be able to revert only part and keep the functionality
> intact).
>
> For example the renaming of a public variable is something that's visible
> to the user but not essential to the functioning of the thing.
> If it turns out to cause trouble, we could back just that one out.

Makes sense to me, thanks for the explanation.


>> I used patches on top of the u-boot 2018.11 release rather than a git
>> repository with the patches included, as it took a much longer time to
>> download the git respository and more disk space, though I can take
>> another look at using the git repository if that is preferred.
>
> I prefer patches on top of a release to using a different git repository -
> the latter can be a real drain on us since we want to verify the integrity of
> the external repository - if there are too many of those in Guix.

Ok.

> That said, there are exceptions, but in this specific case I'd definitely
> keep it as release & patches because it makes it obvious how invasive we
> are in patching our package (Note: I agree that we should do patch it in
> this case - some of the patches are to undo upstream breaking backward
> compatibility, others are to add new platforms, others are to increase
> resilience; also, they come from u-boot-sunxi anyway).

Works for me. FWIW these patches landed in mainline u-boot git since I
started working on it, so only need to be maintained ~2 months more. :)


> In the end, your patchset failed to apply cleanly.  Nevertheless, I've
> cleaned up the first three patches (changed the commit message to our
> conventions; also took the liberty to rename "make-u-boot-package-sunxi64"
> to "make-u-boot-sunxi64-package") and pushed those to guix master since
> they are self-contained.

Great!


> Could you send a variant of patch 4/4 that applies cleanly? (this one
> fails because of conflicting changes in gnu/local.mk)
>
> Also, could you use small letters in the name of the files of the patches
> in gnu/packages/patches ?

Updated patch, with lower case and some slight renaming of the patches, and
updated make-u-boot-sunxi64-package call.

Thanks!


live well,
  vagrant