unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Danny Milosavljevic <dannym@scratchpost.org>
To: Vagrant Cascadian <vagrant@debian.org>
Cc: 33447@debbugs.gnu.org
Subject: [bug#33447] Patch series to support pinebook
Date: Tue, 20 Nov 2018 23:52:50 +0100	[thread overview]
Message-ID: <20181120235250.65eff9ac@scratchpost.org> (raw)
In-Reply-To: <878t1nv3wd.fsf@aikidev.net>

[-- Attachment #1: Type: text/plain, Size: 2757 bytes --]

Hi Vagrant,

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.

> - 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-11-20 22:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-20 21:24 [bug#33447] Patch series to support pinebook Vagrant Cascadian
2018-11-20 22:52 ` Danny Milosavljevic [this message]
2018-11-21  0:32   ` Vagrant Cascadian
2018-11-22 21:11     ` bug#33447: " Danny Milosavljevic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181120235250.65eff9ac@scratchpost.org \
    --to=dannym@scratchpost.org \
    --cc=33447@debbugs.gnu.org \
    --cc=vagrant@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).