guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#33447] Patch series to support pinebook


From: Danny Milosavljevic
Subject: [bug#33447] Patch series to support pinebook
Date: Tue, 20 Nov 2018 23:52:50 +0100

Hi Vagrant,

On Tue, 20 Nov 2018 13:24:18 -0800
Vagrant Cascadian <address@hidden> 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.

> - 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 :)

> - 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.

> 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.

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).

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.

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 ?

Attachment: pgpmY78tvoqUe.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]