From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] Patchwork cleanup #7: submitter notification (feedback deadline: April 12)
Date: Fri, 04 Apr 2014 18:22:23 +0200 [thread overview]
Message-ID: <533EDC3F.9060101@mind.be> (raw)
In-Reply-To: <20140331171204.GB5004@free.fr>
On 31/03/14 19:12, Yann E. MORIN wrote:
> On 2014-03-31 10:58 +0200, Eric Jarrige spake thusly:
>> Hi Thomas,
>>
>>>> [v2,1/1] u-boot: allow to pass a custom configuration file
>>>> http://patchwork.ozlabs.org/patch/276286/
>>>> Eric Jarrige
>>>> Yann Morin gave the feedback that this patch allows to overwrite
>>>> u-boot sources, rendering the declared license possible invalid.
>>
>> AFAIK this feature cannot overwrite the U-Boot license files and
>> according to the U-Boot licenses/README - "You can redistribute
>> U-Boot and/or modify it under the terms of version 2 of the GNU
>> General Public License as published by the Free Software
>> Foundation."
>> So, it should not be an issue as long as the new config file respects
>> the terms of the version 2 of the GNU GPL license.
>
> Hmm. There was maybe a bit of misunderstanding in what I said. Lemme
> quote it here again:
>
> ---
> This is likely to overwrite a uboot source file
> with a local file, so we won't be able to generate conpliant
> legal-info when a custom comnfig file is used.
> ---
>
> What I meant was, when running 'make legal-info', we will end up copying
> the tarball of the sources, and we will miss this file (since Buildroot
> is not recreating the tarballs from the build dir, but just copies what
> was downloaded.)
>
> So, this indeed can not overwrite the license file, but the sources in
> legal-info will not be the exact sources used to build U-Boot, so the
> legal-info will not create a compliant distribution.
Note that this is the same for the kernel (although a bit more vague).
One could easily argue that the .config file is part of the
infrastructure needed to build the kernel (if you've ever tried to
reverse engineer a kernel config you will know what I mean). With U-Boot
it's more obvious because the config file is a header file, but the
semantics are really the same.
That said, this shouldn't be a reason to do the wrong thing in U-Boot.
>
> That's why I oppposed the change as-is.
>
>>>> Eric: are you still interested in pursuing this patch? If so, I think
>>>> some further discussion on it should be ignited.
>>
>> I submitted this patch because I think it is generic enough to support
>> custom U-Boot configuration file for any board without using a patch
>> but I can understand I am the only one customizing bootloader for
>> my boards.
>> So feel free to reject this patch if there is no interest to manage
>> U-Boot configuration files within BuildRoot.
>
> I did not say we did not want to be able to provide a custom config
> file. I just said we need to be careful on the impact.
>
> However, I see that it is possible to declare post-legal-info hooks in
> packages.
>
> So you could complement your patch with something like:
>
> UBOOT_CUSTOM_CONFIG = $(call qstrip,$(BR2_TARGET_UBOOT_CUSTOM_CONFIG_FILE))
> ifneq ($(UBOOT_CUSTOM_CONFIG_FILE),)
> define UBOOT_COPY_CUSTOM_CONFIG_FILE
> $(INSTALL) -m 0644 -D $(UBOOT_CUSTOM_CONFIG_FILE) \
> $(SOMEWHERE)
> endef
> UBOOT_POST_LEGAL_INFO_HOOKS += UBOOT_COPY_CUSTOM_CONFIG_FILE
> endif
>
> I'll leave it to you as an exercise to find what $(SOMEWHERE) should be.
> ;-)
Perhaps we should add legal-info infrastructure to support this kind of
thing. Something like
PKG_LICENSE_EXTRA_SOURCE = list of files relative to BR dir
By the way, since this config.h copying is only useful for changing the
configuration of existing boards, I think this should be explicitly
mentioned in the help text of the option.
BTW, note that this patch has become more useful since the deprecation
of BR2_TARGET_UBOOT_IPADDR and friends.
Regards,
Arnout
>
> Regards,
> Yann E. MORIN.
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
next prev parent reply other threads:[~2014-04-04 16:22 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAAXf6LW5stEOk84f-SiPvnYSxazu7vBgM-cNpQStV7j+dcMrbw@mail.gmail.com>
2014-03-27 20:01 ` [Buildroot] Patchwork cleanup #7: submitter notification (feedback deadline: April 12) Thomas De Schampheleire
2014-03-31 8:58 ` Eric Jarrige
2014-03-31 17:12 ` Yann E. MORIN
2014-04-04 16:22 ` Arnout Vandecappelle [this message]
2014-04-29 19:52 ` Thomas De Schampheleire
2014-04-30 13:46 ` Arnout Vandecappelle
2014-04-30 14:55 ` Luca Ceresoli
2014-04-29 19:57 ` Thomas De Schampheleire
2014-04-29 20:03 ` Spenser Gilliland
2014-04-29 20:10 ` Thomas De Schampheleire
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=533EDC3F.9060101@mind.be \
--to=arnout@mind.be \
--cc=buildroot@busybox.net \
/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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox