[Buildroot] [PATCH] uboot-tools: fix license issues

[Buildroot] [PATCH] uboot-tools: fix license issues

[Gustavo Zacarias]

U-Boot 2013.10 moved licenses into the Licenses/ directory.
However since we target many versions of u-boot (even non-upstream
versions) we can't point UBOOT_TOOLS_LICENSE_FILES to the proper place
without making mistakes.
So just remove it unforunately. Fixes:
http://autobuild.buildroot.net/results/8c9/8c94c81fe74399c854de335329cf4942f8356fbe/

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/uboot-tools/uboot-tools.mk | 1 -
 1 file changed, 1 deletion(-)

diff --git a/package/uboot-tools/uboot-tools.mk b/package/uboot-tools/uboot-tools.mk
index e19372a..96d2c8d 100644
--- a/package/uboot-tools/uboot-tools.mk
+++ b/package/uboot-tools/uboot-tools.mk
@@ -8,7 +8,6 @@ UBOOT_TOOLS_VERSION = 2013.10
 UBOOT_TOOLS_SOURCE  = u-boot-$(UBOOT_TOOLS_VERSION).tar.bz2
 UBOOT_TOOLS_SITE    = ftp://ftp.denx.de/pub/u-boot
 UBOOT_TOOLS_LICENSE = GPLv2+
-UBOOT_TOOLS_LICENSE_FILES = COPYING
 
 define UBOOT_TOOLS_BUILD_CMDS
 	$(MAKE) -C $(@D) 			\
-- 
1.8.1.5

[Buildroot] [PATCH] uboot-tools: fix license issues

[Thomas De Schampheleire]

On Tue, Oct 22, 2013 at 4:37 PM, Gustavo Zacarias
<gustavo@zacarias.com.ar> wrote:
> U-Boot 2013.10 moved licenses into the Licenses/ directory.
> However since we target many versions of u-boot (even non-upstream
> versions) we can't point UBOOT_TOOLS_LICENSE_FILES to the proper place
> without making mistakes.
> So just remove it unforunately. Fixes:
> http://autobuild.buildroot.net/results/8c9/8c94c81fe74399c854de335329cf4942f8356fbe/
>
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
>  package/uboot-tools/uboot-tools.mk | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/package/uboot-tools/uboot-tools.mk b/package/uboot-tools/uboot-tools.mk
> index e19372a..96d2c8d 100644
> --- a/package/uboot-tools/uboot-tools.mk
> +++ b/package/uboot-tools/uboot-tools.mk
> @@ -8,7 +8,6 @@ UBOOT_TOOLS_VERSION = 2013.10
>  UBOOT_TOOLS_SOURCE  = u-boot-$(UBOOT_TOOLS_VERSION).tar.bz2
>  UBOOT_TOOLS_SITE    = ftp://ftp.denx.de/pub/u-boot
>  UBOOT_TOOLS_LICENSE = GPLv2+
> -UBOOT_TOOLS_LICENSE_FILES = COPYING
>

Maybe the legal-info target should warn for non-existing files, rather
than error out.
It seems more logical to support the latest versions than to support
none, with respect to _LICENSE_FILES.
Those who build older versions of u-boot should see the warning and
handle it appropriately.

Note that in either case, we can't trust the _LICENSE directive
either: a project could change license along the way, and if buildroot
allows to select an arbitrary version in the config, the specified
LICENSE may be wrong.

Best regards,
Thomas

[Buildroot] [PATCH] uboot-tools: fix license issues

[Gustavo Zacarias]

On 10/22/2013 11:57 AM, Thomas De Schampheleire wrote:

> Maybe the legal-info target should warn for non-existing files, rather
> than error out.
> It seems more logical to support the latest versions than to support
> none, with respect to _LICENSE_FILES.
> Those who build older versions of u-boot should see the warning and
> handle it appropriately.

Yes, that's what i thought, this is the quick fix but maybe not the
desired one.

> Note that in either case, we can't trust the _LICENSE directive
> either: a project could change license along the way, and if buildroot
> allows to select an arbitrary version in the config, the specified
> LICENSE may be wrong.

Looking at Licenses/README in 2013.10 it seems there was some licensing
cleanup done and not all the code is guaranteed to be GPLv2*.
It's mostly accurate for uboot-tools but may not be so for target u-boot
(which isn't covered by this issue, just bringing up the details here).
Regards.

[Buildroot] [PATCH] uboot-tools: fix license issues

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Tue, 22 Oct 2013 16:57:31 +0200, Thomas De Schampheleire wrote:

> Maybe the legal-info target should warn for non-existing files, rather
> than error out.

I disagree. Before 376c3aad61dbeb8e2126e13658fd150b70746afb
("legal-info: fail trying to copy a non-existent license file"), what
was happening is exactly what you're suggesting.

The problem is that we didn't notice when legal information were wrong,
because nobody looks at warnings, and because autobuilders result were
saying "OK" even though the legal info wasn't ok. So at the time (back
in May this year), we discussed that, and we agreed that legal-info
should error out if it cannot find a license file referenced by
<pkg>_LICENSE_FILES, so that autobuilder results loudly say that
something failed.

And interestingly, the precise reason why we noticed the legal-info
were wrong was because the autobuilder build failed, and we fixed it. I
very much prefer that than having the <pkg>_LICENSE_FILES remain wrong
for many weeks/months without anybody noticing.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] uboot-tools: fix license issues

[Thomas De Schampheleire]

Hi Thomas,

On Wed, Oct 23, 2013 at 11:39 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Tue, 22 Oct 2013 16:57:31 +0200, Thomas De Schampheleire wrote:
>
>> Maybe the legal-info target should warn for non-existing files, rather
>> than error out.
>
> I disagree. Before 376c3aad61dbeb8e2126e13658fd150b70746afb
> ("legal-info: fail trying to copy a non-existent license file"), what
> was happening is exactly what you're suggesting.
>
> The problem is that we didn't notice when legal information were wrong,
> because nobody looks at warnings, and because autobuilders result were
> saying "OK" even though the legal info wasn't ok. So at the time (back
> in May this year), we discussed that, and we agreed that legal-info
> should error out if it cannot find a license file referenced by
> <pkg>_LICENSE_FILES, so that autobuilder results loudly say that
> something failed.
>
> And interestingly, the precise reason why we noticed the legal-info
> were wrong was because the autobuilder build failed, and we fixed it. I
> very much prefer that than having the <pkg>_LICENSE_FILES remain wrong
> for many weeks/months without anybody noticing.

My comment was too one-sided. I still agree with the commit that
changed the warning into an error.
But now we are in a special situation: for packages that support
multiple versions, we currently assume that these all have the same
LICENSE and LICENSE_FILES, which is not necessarily true. For such
packages, we _expect_ that the LICENSE_FILES definition will not be
correct for some versions, and this will cause buildroot to fail on
the legal-info. However, we cannot simply fix that failure by changing
LICENSE_FILES, because it will fail on the other versions.

We could envision a strategy where we can pass some version annotation
to LICENSE(_FILES) that the legal-info infrastructure can recognize,
which would work for packages with known versions only.
However, in the case of linux, u-boot, and probably others, we allow
the user to specify an arbitrary version, for which we don't know the
license unless with some deeper checking of the base version. Maybe
this last case is more of an exception, and we should warn the user
that we are not sure which license to use if he is using an arbitrary
version.

Best regards,
Thomas

[Buildroot] [PATCH] uboot-tools: fix license issues

[Luca Ceresoli]

Thomas De Schampheleire <patrickdepinguin@gmail.com> ha scritto:
>Hi Thomas,
>
>On Wed, Oct 23, 2013 at 11:39 AM, Thomas Petazzoni
><thomas.petazzoni@free-electrons.com> wrote:
>> Dear Thomas De Schampheleire,
>>
>> On Tue, 22 Oct 2013 16:57:31 +0200, Thomas De Schampheleire wrote:
>>
>>> Maybe the legal-info target should warn for non-existing files,
>rather
>>> than error out.
>>
>> I disagree. Before 376c3aad61dbeb8e2126e13658fd150b70746afb
>> ("legal-info: fail trying to copy a non-existent license file"), what
>> was happening is exactly what you're suggesting.
>>
>> The problem is that we didn't notice when legal information were
>wrong,
>> because nobody looks at warnings, and because autobuilders result
>were
>> saying "OK" even though the legal info wasn't ok. So at the time
>(back
>> in May this year), we discussed that, and we agreed that legal-info
>> should error out if it cannot find a license file referenced by
>> <pkg>_LICENSE_FILES, so that autobuilder results loudly say that
>> something failed.
>>
>> And interestingly, the precise reason why we noticed the legal-info
>> were wrong was because the autobuilder build failed, and we fixed it.
>I
>> very much prefer that than having the <pkg>_LICENSE_FILES remain
>wrong
>> for many weeks/months without anybody noticing.
>
>My comment was too one-sided. I still agree with the commit that
>changed the warning into an error.
>But now we are in a special situation: for packages that support
>multiple versions, we currently assume that these all have the same
>LICENSE and LICENSE_FILES, which is not necessarily true. For such
>packages, we _expect_ that the LICENSE_FILES definition will not be
>correct for some versions, and this will cause buildroot to fail on
>the legal-info. However, we cannot simply fix that failure by changing
>LICENSE_FILES, because it will fail on the other versions.
>
>We could envision a strategy where we can pass some version annotation
>to LICENSE(_FILES) that the legal-info infrastructure can recognize,
>which would work for packages with known versions only.
>However, in the case of linux, u-boot, and probably others, we allow
>the user to specify an arbitrary version, for which we don't know the
>license unless with some deeper checking of the base version. Maybe
>this last case is more of an exception, and we should warn the user
>that we are not sure which license to use if he is using an arbitrary
>version.

Instead of special annotations in the _LICENSE* fields, I think we have two better options.

First, we may conditionally define _LICENSE* fields based on versions. Simple, but this would never handle cases where the bootloader or kernel is obtained from a custom git repo.

Or we may override the <pkg>-legal-info target for those few packages. The overridden target may do anything, e.g. try to copy a license file and, if not found, copy another one, failing only if both are missing. Or it could launch a script doing fancy things...

Not tried any of the two, but I feel the latter is more flexible and still quite simple in terms of infrastructure. Both would let the "normal" packages be handled in the old, simple way.


-- 
Luca

[Buildroot] [PATCH] uboot-tools: fix license issues

[Arnout Vandecappelle]

On 24/10/13 10:20, Luca Ceresoli wrote:
>
>
> Thomas De Schampheleire <patrickdepinguin@gmail.com> ha scritto:
>> Hi Thomas,
>>
>> On Wed, Oct 23, 2013 at 11:39 AM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>>> Dear Thomas De Schampheleire,
>>>
>>> On Tue, 22 Oct 2013 16:57:31 +0200, Thomas De Schampheleire wrote:
>>>
>>>> Maybe the legal-info target should warn for non-existing files,
>> rather
>>>> than error out.
>>>
>>> I disagree. Before 376c3aad61dbeb8e2126e13658fd150b70746afb
>>> ("legal-info: fail trying to copy a non-existent license file"), what
>>> was happening is exactly what you're suggesting.
>>>
>>> The problem is that we didn't notice when legal information were
>> wrong,
>>> because nobody looks at warnings, and because autobuilders result
>> were
>>> saying "OK" even though the legal info wasn't ok. So at the time
>> (back
>>> in May this year), we discussed that, and we agreed that legal-info
>>> should error out if it cannot find a license file referenced by
>>> <pkg>_LICENSE_FILES, so that autobuilder results loudly say that
>>> something failed.
>>>
>>> And interestingly, the precise reason why we noticed the legal-info
>>> were wrong was because the autobuilder build failed, and we fixed it.
>> I
>>> very much prefer that than having the <pkg>_LICENSE_FILES remain
>> wrong
>>> for many weeks/months without anybody noticing.
>>
>> My comment was too one-sided. I still agree with the commit that
>> changed the warning into an error.
>> But now we are in a special situation: for packages that support
>> multiple versions, we currently assume that these all have the same
>> LICENSE and LICENSE_FILES, which is not necessarily true. For such
>> packages, we _expect_ that the LICENSE_FILES definition will not be
>> correct for some versions, and this will cause buildroot to fail on
>> the legal-info. However, we cannot simply fix that failure by changing
>> LICENSE_FILES, because it will fail on the other versions.
>>
>> We could envision a strategy where we can pass some version annotation
>> to LICENSE(_FILES) that the legal-info infrastructure can recognize,
>> which would work for packages with known versions only.
>> However, in the case of linux, u-boot, and probably others, we allow
>> the user to specify an arbitrary version, for which we don't know the
>> license unless with some deeper checking of the base version. Maybe
>> this last case is more of an exception, and we should warn the user
>> that we are not sure which license to use if he is using an arbitrary
>> version.
>
> Instead of special annotations in the _LICENSE* fields, I think we have two better options.
>
> First, we may conditionally define _LICENSE* fields based on versions. Simple, but this would never handle cases where the bootloader or kernel is obtained from a custom git repo.
>
> Or we may override the <pkg>-legal-info target for those few packages. The overridden target may do anything, e.g. try to copy a license file and, if not found, copy another one, failing only if both are missing. Or it could launch a script doing fancy things...
>
> Not tried any of the two, but I feel the latter is more flexible and still quite simple in terms of infrastructure. Both would let the "normal" packages be handled in the old, simple way.

  The U-Boot issue is actually a symptom of a deeper problem: for 
situations where the user is able to change the source of a package, our 
license info may be incorrect. So it's not just about LICENSE_FILES, but 
also about the license itself.

  I don't think it's worth to spend much effort in dealing with variant 
licenses. Instead, it's more useful to detect situations where our 
license information is incorrect and mark it like that in the legal info.

  So where can the user override the source of a package?

* _OVERRIDE_SRCDIR: I think we should add a warning to the manifest that 
the license information may be incorrect.

* Custom versions of U-Boot, barebox, mxs-bootlets, linux - am I 
forgetting anything? I think we should treat these the same as 
_OVERRIDE_SRCDIR: put a warning in the manifest file.

* External toolchains: we don't cover these anyway.

* Patches passed in through package-specific config variables (e.g. linux 
and many bootloaders) or throught GLOBAL_PATCH_DIR: here we have to 
assume that the user knows what he's doing, but it would be good to add a 
reminder in the README if GLOBAL_PATCH_DIR or any of the other patch 
config variables is set (actually I would prefer to deprecate the other 
patch config variables and force users to switch to GLOBAL_PATCH_DIR).

  Anything else?


  Now, for the specific case of U-Boot, we can do better: if _VERSION is 
2013.10 or larger, we can use the new license specification, else the old 
one (and due to U-Boot's versioning policy we can just use sort; custom 
has to be handled separately anyway).

  But another issue is that the license that we specify is just plain 
wrong (as so often): all the U-Boot versions contain code that is GPLv2 
without + and that is BSD-3c, some also contain code that is eCos-2.0, 
IBM-pibs, LGPL. So we should probably fix the license spec for U-Boot 
regardless of where it comes from.



  Regards,
  Arnout

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

[Buildroot] [PATCH] uboot-tools: fix license issues

[Gustavo Zacarias]

On 10/24/2013 09:24 AM, Arnout Vandecappelle wrote:
>  Now, for the specific case of U-Boot, we can do better: if _VERSION is
> 2013.10 or larger, we can use the new license specification, else the
> old one (and due to U-Boot's versioning policy we can just use sort;
> custom has to be handled separately anyway).

We don't use version choices any more, just a recommended version
string, so matching might not be that easy.
And there's custom tarball / git repo / etc too.

>  But another issue is that the license that we specify is just plain
> wrong (as so often): all the U-Boot versions contain code that is GPLv2
> without + and that is BSD-3c, some also contain code that is eCos-2.0,
> IBM-pibs, LGPL. So we should probably fix the license spec for U-Boot
> regardless of where it comes from.

The U-Boot licenses that apply rely on the selected target too which
complicates things.
I don't think we want to become license police here other than "one or
more of X, Y, ..., please do your homework".
Regards.

[Buildroot] [PATCH] uboot-tools: fix license issues

[Arnout Vandecappelle]

On 24/10/13 14:35, Gustavo Zacarias wrote:
> On 10/24/2013 09:24 AM, Arnout Vandecappelle wrote:
>>   Now, for the specific case of U-Boot, we can do better: if _VERSION is
>> 2013.10 or larger, we can use the new license specification, else the
>> old one (and due to U-Boot's versioning policy we can just use sort;
>> custom has to be handled separately anyway).
>
> We don't use version choices any more, just a recommended version
> string, so matching might not be that easy.

  We don't? Then what does BR2_TARGET_UBOOT_CUSTOM_VERSION do?

> And there's custom tarball / git repo / etc too.

  Exactly, for these the other considerations still apply.

>
>>   But another issue is that the license that we specify is just plain
>> wrong (as so often): all the U-Boot versions contain code that is GPLv2
>> without + and that is BSD-3c, some also contain code that is eCos-2.0,
>> IBM-pibs, LGPL. So we should probably fix the license spec for U-Boot
>> regardless of where it comes from.
>
> The U-Boot licenses that apply rely on the selected target too which
> complicates things.
> I don't think we want to become license police here other than "one or
> more of X, Y, ..., please do your homework".

  I agree completely. But currently it just says GPLv2+, which is plain 
wrong.

  Regards,
  Arnout

> Regards.
>
>


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

[Buildroot] [PATCH] uboot-tools: fix license issues

[Peter Korsgaard]

>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:

 > U-Boot 2013.10 moved licenses into the Licenses/ directory.
 > However since we target many versions of u-boot (even non-upstream
 > versions) we can't point UBOOT_TOOLS_LICENSE_FILES to the proper place
 > without making mistakes.
 > So just remove it unforunately. Fixes:
 > http://autobuild.buildroot.net/results/8c9/8c94c81fe74399c854de335329cf4942f8356fbe/

Ehh, we do support multiple versions of u-boot, but only a single
version of uboot-tools, so it makes sense to just change it to
Licenses/..

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] uboot-tools: fix license issues

[Gustavo Zacarias]

On 10/22/2013 01:39 PM, Peter Korsgaard wrote:

> Ehh, we do support multiple versions of u-boot, but only a single
> version of uboot-tools, so it makes sense to just change it to
> Licenses/..

D'oh that's true, i'll fix it.
Regards.

[Buildroot] [PATCH] uboot-tools: fix license issues

[Thomas De Schampheleire]

Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:
>
> > U-Boot 2013.10 moved licenses into the Licenses/ directory.
> > However since we target many versions of u-boot (even non-upstream
> > versions) we can't point UBOOT_TOOLS_LICENSE_FILES to the proper place
> > without making mistakes.
> > So just remove it unforunately. Fixes:
> > http://autobuild.buildroot.net/results/8c9/8c94c81fe74399c854de335329cf4942f8356fbe/
>
>Ehh, we do support multiple versions of u-boot, but only a single
>version of uboot-tools, so it makes sense to just change it to
>Licenses/..


Sure, but the mentioned problem remains for uboot proper right?

[Buildroot] [PATCH] uboot-tools: fix license issues

[Peter Korsgaard]

>>>>> "Thomas" == Thomas De Schampheleire <patrickdepinguin@gmail.com> writes:

Hi,

 >> Ehh, we do support multiple versions of u-boot, but only a single
 >> version of uboot-tools, so it makes sense to just change it to
 >> Licenses/..

 > Sure, but the mentioned problem remains for uboot proper right?

Indeed, it does.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] uboot-tools: fix license issues

[Gustavo Zacarias]

On 10/22/2013 02:01 PM, Thomas De Schampheleire wrote:

>> Ehh, we do support multiple versions of u-boot, but only a single
>> version of uboot-tools, so it makes sense to just change it to
>> Licenses/..
> 
> 
> Sure, but the mentioned problem remains for uboot proper right?

The problem is a bit more complicated for uboot proper.
The README says the u-boot part is GPL, but some extras (preloaders,
etc) might not be, so even if we fail silently to cover the different
uboot versions that might not be enough (i.e. GPL won't be enough
depending on the target).
Regards.

[Buildroot] [PATCH] uboot-tools: fix license issues

[Gustavo Zacarias]

Fix license directory and filename change, fixes:
http://autobuild.buildroot.net/results/8c9/8c94c81fe74399c854de335329cf4942f8356fbe/

Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
---
 package/uboot-tools/uboot-tools.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/uboot-tools/uboot-tools.mk b/package/uboot-tools/uboot-tools.mk
index e19372a..73e1d32 100644
--- a/package/uboot-tools/uboot-tools.mk
+++ b/package/uboot-tools/uboot-tools.mk
@@ -8,7 +8,7 @@ UBOOT_TOOLS_VERSION = 2013.10
 UBOOT_TOOLS_SOURCE  = u-boot-$(UBOOT_TOOLS_VERSION).tar.bz2
 UBOOT_TOOLS_SITE    = ftp://ftp.denx.de/pub/u-boot
 UBOOT_TOOLS_LICENSE = GPLv2+
-UBOOT_TOOLS_LICENSE_FILES = COPYING
+UBOOT_TOOLS_LICENSE_FILES = Licenses/gpl-2.0.txt
 
 define UBOOT_TOOLS_BUILD_CMDS
 	$(MAKE) -C $(@D) 			\
-- 
1.8.1.5

[Buildroot] [PATCH] uboot-tools: fix license issues

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Tue, 22 Oct 2013 13:46:40 -0300, Gustavo Zacarias wrote:
> Fix license directory and filename change, fixes:
> http://autobuild.buildroot.net/results/8c9/8c94c81fe74399c854de335329cf4942f8356fbe/
> 
> Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
> ---
>  package/uboot-tools/uboot-tools.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to for-peter-2013.11, thanks!

For some reason, this patch was not in patchwork, not sure what
happened, since I don't see it having been applied on master by Peter,
unless I missed something.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] uboot-tools: fix license issues

[Gustavo Zacarias]

On 11/02/2013 10:43 AM, Thomas Petazzoni wrote:

> For some reason, this patch was not in patchwork, not sure what
> happened, since I don't see it having been applied on master by Peter,
> unless I missed something.

Patchwork is acting up a little sometimes, for instance some patches
that were applied by Peter were never marked as accepted (for instance
the libpng disable tools patch IIRC).
Better keep an eye on it ;)
Regards.

[Buildroot] [PATCH] uboot-tools: fix license issues

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Sat, 02 Nov 2013 13:24:02 -0300, Gustavo Zacarias wrote:
> On 11/02/2013 10:43 AM, Thomas Petazzoni wrote:
> 
> > For some reason, this patch was not in patchwork, not sure what
> > happened, since I don't see it having been applied on master by Peter,
> > unless I missed something.
> 
> Patchwork is acting up a little sometimes, for instance some patches
> that were applied by Peter were never marked as accepted (for instance
> the libpng disable tools patch IIRC).

This is expected when Peter makes a small modification to the patch:
patchwork no longer recognizes the committed patch as being the same as
the patch sitting in the queue.

However, a patch not committed and not visible in patchwork is a bit
weird (except for patches that only rename files, because the patch
contents are empty and patchwork doesn't understand that).

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] uboot-tools: fix license issues

[Yann E. MORIN]

Thomas, All,

On 2013-11-02 17:43 +0100, Thomas Petazzoni spake thusly:
> However, a patch not committed and not visible in patchwork is a bit
> weird (except for patches that only rename files, because the patch
> contents are empty and patchwork doesn't understand that).

Actually, this last part is now wrong: patchwork should now recognise
renames-only patches (since about two weeks now).

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] uboot-tools: fix license issues

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Sat, 2 Nov 2013 18:32:58 +0100, Yann E. MORIN wrote:

> On 2013-11-02 17:43 +0100, Thomas Petazzoni spake thusly:
> > However, a patch not committed and not visible in patchwork is a bit
> > weird (except for patches that only rename files, because the patch
> > contents are empty and patchwork doesn't understand that).
> 
> Actually, this last part is now wrong: patchwork should now recognise
> renames-only patches (since about two weeks now).

Aaah, and this is actually true! The ngrep patches renaming patch was
recognized by patchwork.

My bad,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com