[Buildroot] [PATCH 1/6] cjson: Add license info

[Buildroot] [PATCH 1/6] cjson: Add license info

[Danomi Manchego]

Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
---
 package/cjson/cjson.mk |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/cjson/cjson.mk b/package/cjson/cjson.mk
index a9b0bcf..44ddfc2 100644
--- a/package/cjson/cjson.mk
+++ b/package/cjson/cjson.mk
@@ -7,6 +7,8 @@ CJSON_VERSION         = undefined
 CJSON_SOURCE          = cJSONFiles.zip
 CJSON_SITE            = http://$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/project/cjson/
 CJSON_INSTALL_STAGING = YES
+CJSON_LICENSE         = MIT
+CJSON_LICENSE_FILES   = cJSON/README
 
 define CJSON_EXTRACT_CMDS
 	unzip -d $(@D) $(DL_DIR)/$(CJSON_SOURCE)
-- 
1.7.9.5

[Buildroot] [PATCH 2/6] expat: Add license info

[Danomi Manchego]

Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
---
 package/expat/expat.mk |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/expat/expat.mk b/package/expat/expat.mk
index 663abcd..7fa3126 100644
--- a/package/expat/expat.mk
+++ b/package/expat/expat.mk
@@ -10,6 +10,8 @@ EXPAT_INSTALL_STAGING = YES
 EXPAT_INSTALL_STAGING_OPT = DESTDIR=$(STAGING_DIR) installlib
 EXPAT_INSTALL_TARGET_OPT = DESTDIR=$(TARGET_DIR) installlib
 EXPAT_DEPENDENCIES = host-pkg-config
+EXPAT_LICENSE = MIT
+EXPAT_LICENSE_FILES = COPYING
 
 $(eval $(autotools-package))
 $(eval $(host-autotools-package))
-- 
1.7.9.5

[Buildroot] [PATCH 2/6] expat: Add license info

[Luca Ceresoli]

Danomi Manchego wrote:
> Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
> ---
>   package/expat/expat.mk |    2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/package/expat/expat.mk b/package/expat/expat.mk
> index 663abcd..7fa3126 100644
> --- a/package/expat/expat.mk
> +++ b/package/expat/expat.mk
> @@ -10,6 +10,8 @@ EXPAT_INSTALL_STAGING = YES
>   EXPAT_INSTALL_STAGING_OPT = DESTDIR=$(STAGING_DIR) installlib
>   EXPAT_INSTALL_TARGET_OPT = DESTDIR=$(TARGET_DIR) installlib
>   EXPAT_DEPENDENCIES = host-pkg-config
> +EXPAT_LICENSE = MIT
> +EXPAT_LICENSE_FILES = COPYING
>   
>   $(eval $(autotools-package))
>   $(eval $(host-autotools-package))

Acked-by: Luca Ceresoli <luca@lucaceresoli.net>

Luca

[Buildroot] [PATCH 3/6] lua: Add license info

[Danomi Manchego]

Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
---
 package/lua/lua.mk |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/lua/lua.mk b/package/lua/lua.mk
index 26c1576..de60c57 100644
--- a/package/lua/lua.mk
+++ b/package/lua/lua.mk
@@ -7,6 +7,8 @@
 LUA_VERSION = 5.1.5
 LUA_SITE = http://www.lua.org/ftp
 LUA_INSTALL_STAGING = YES
+LUA_LICENSE = MIT
+LUA_LICENSE_FILES = COPYRIGHT
 
 LUA_CFLAGS = -Wall
 ifeq ($(BR2_PACKAGE_LUA_SHARED_LIBRARY),y)
-- 
1.7.9.5

[Buildroot] [PATCH 3/6] lua: Add license info

[Luca Ceresoli]

Danomi Manchego wrote:
> Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
> ---
>   package/lua/lua.mk |    2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/package/lua/lua.mk b/package/lua/lua.mk
> index 26c1576..de60c57 100644
> --- a/package/lua/lua.mk
> +++ b/package/lua/lua.mk
> @@ -7,6 +7,8 @@
>   LUA_VERSION = 5.1.5
>   LUA_SITE = http://www.lua.org/ftp
>   LUA_INSTALL_STAGING = YES
> +LUA_LICENSE = MIT
> +LUA_LICENSE_FILES = COPYRIGHT
>   
>   LUA_CFLAGS = -Wall
>   ifeq ($(BR2_PACKAGE_LUA_SHARED_LIBRARY),y)

Acked-by: Luca Ceresoli <luca@lucaceresoli.net>

Luca

[Buildroot] [PATCH 4/6] luacjson: Add license info

[Danomi Manchego]

Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
---
 package/luacjson/luacjson.mk |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/package/luacjson/luacjson.mk b/package/luacjson/luacjson.mk
index fe92f16..1f79d5d 100644
--- a/package/luacjson/luacjson.mk
+++ b/package/luacjson/luacjson.mk
@@ -3,10 +3,12 @@
 # luacjson
 #
 #############################################################
-LUACJSON_VERSION      = 2.1.0
-LUACJSON_SOURCE       = lua-cjson-$(LUACJSON_VERSION).tar.gz
-LUACJSON_SITE         = http://www.kyne.com.au/~mark/software/download
-LUACJSON_DEPENDENCIES = lua
+LUACJSON_VERSION       = 2.1.0
+LUACJSON_SOURCE        = lua-cjson-$(LUACJSON_VERSION).tar.gz
+LUACJSON_SITE          = http://www.kyne.com.au/~mark/software/download
+LUACJSON_DEPENDENCIES  = lua
+LUACJSON_LICENSE       = MIT
+LUACJSON_LICENSE_FILES = LICENSE
 
 define LUACJSON_BUILD_CMDS
 	$(MAKE) -C $(@D) \
-- 
1.7.9.5

[Buildroot] [PATCH 4/6] luacjson: Add license info

[Luca Ceresoli]

Danomi Manchego wrote:
> Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
> ---
>   package/luacjson/luacjson.mk |   10 ++++++----
>   1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/package/luacjson/luacjson.mk b/package/luacjson/luacjson.mk
> index fe92f16..1f79d5d 100644
> --- a/package/luacjson/luacjson.mk
> +++ b/package/luacjson/luacjson.mk
> @@ -3,10 +3,12 @@
>   # luacjson
>   #
>   #############################################################
> -LUACJSON_VERSION      = 2.1.0
> -LUACJSON_SOURCE       = lua-cjson-$(LUACJSON_VERSION).tar.gz
> -LUACJSON_SITE         = http://www.kyne.com.au/~mark/software/download
> -LUACJSON_DEPENDENCIES = lua
> +LUACJSON_VERSION       = 2.1.0
> +LUACJSON_SOURCE        = lua-cjson-$(LUACJSON_VERSION).tar.gz
> +LUACJSON_SITE          = http://www.kyne.com.au/~mark/software/download
> +LUACJSON_DEPENDENCIES  = lua
> +LUACJSON_LICENSE       = MIT
> +LUACJSON_LICENSE_FILES = LICENSE
>   
>   define LUACJSON_BUILD_CMDS
>   	$(MAKE) -C $(@D) \

Acked-by: Luca Ceresoli <luca@lucaceresoli.net>

Luca

[Buildroot] [PATCH 5/6] luaexpat: Add license info

[Danomi Manchego]

Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
---
 package/luaexpat/luaexpat.mk |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/package/luaexpat/luaexpat.mk b/package/luaexpat/luaexpat.mk
index 400d7b4..c875caa 100644
--- a/package/luaexpat/luaexpat.mk
+++ b/package/luaexpat/luaexpat.mk
@@ -4,9 +4,11 @@
 #
 #############################################################
 
-LUAEXPAT_VERSION      = 1.2.0
-LUAEXPAT_SITE         = http://matthewwild.co.uk/projects/luaexpat
-LUAEXPAT_DEPENDENCIES = lua expat
+LUAEXPAT_VERSION       = 1.2.0
+LUAEXPAT_SITE          = http://matthewwild.co.uk/projects/luaexpat
+LUAEXPAT_DEPENDENCIES  = lua expat
+LUAEXPAT_LICENSE       = MIT
+LUAEXPAT_LICENSE_FILES = doc/us/license.html
 
 
 LUAEXPAT_MFLAGS += LUA_VERSION_NUM=501
-- 
1.7.9.5

[Buildroot] [PATCH 5/6] luaexpat: Add license info

[Luca Ceresoli]

Danomi Manchego wrote:
> Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
> ---
>   package/luaexpat/luaexpat.mk |    8 +++++---
>   1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/package/luaexpat/luaexpat.mk b/package/luaexpat/luaexpat.mk
> index 400d7b4..c875caa 100644
> --- a/package/luaexpat/luaexpat.mk
> +++ b/package/luaexpat/luaexpat.mk
> @@ -4,9 +4,11 @@
>   #
>   #############################################################
>   
> -LUAEXPAT_VERSION      = 1.2.0
> -LUAEXPAT_SITE         = http://matthewwild.co.uk/projects/luaexpat
> -LUAEXPAT_DEPENDENCIES = lua expat
> +LUAEXPAT_VERSION       = 1.2.0
> +LUAEXPAT_SITE          = http://matthewwild.co.uk/projects/luaexpat
> +LUAEXPAT_DEPENDENCIES  = lua expat
> +LUAEXPAT_LICENSE       = MIT
> +LUAEXPAT_LICENSE_FILES = doc/us/license.html

Ouch, putting the license in an HTML file is very strange!
The license.txt file produces by `make legal-info` is supposed to be a
text file, not a mix of different formats.

I have no strong opinion about what to do here, but I slightly prefer to
not define LUAEXPAT_LICENSE_FILES in this case, since it cannot work 100%
as expected. Asking the developers to use a standard format may be a good
idea as well.

Luca

[Buildroot] [PATCH 6/6] xinetd: Add license info

[Danomi Manchego]

Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
---
 package/xinetd/xinetd.mk |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/package/xinetd/xinetd.mk b/package/xinetd/xinetd.mk
index a209d12..c2f891b 100644
--- a/package/xinetd/xinetd.mk
+++ b/package/xinetd/xinetd.mk
@@ -3,9 +3,11 @@
 # xinetd
 #
 #############################################################
-XINETD_VERSION = 2.3.15
-XINETD_SOURCE  = xinetd-$(XINETD_VERSION).tar.gz
-XINETD_SITE    = http://www.xinetd.org
+XINETD_VERSION       = 2.3.15
+XINETD_SOURCE        = xinetd-$(XINETD_VERSION).tar.gz
+XINETD_SITE          = http://www.xinetd.org
+XINETD_LICENSE       = Custom
+XINETD_LICENSE_FILES = COPYRIGHT
 
 ifneq ($(BR2_INET_RPC),y)
 XINETD_CONF_ENV = CFLAGS="$(TARGET_CFLAGS) -DNO_RPC"
-- 
1.7.9.5

[Buildroot] [PATCH 6/6] xinetd: Add license info

[Luca Ceresoli]

Danomi Manchego wrote:
> Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
> ---
>   package/xinetd/xinetd.mk |    8 +++++---
>   1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/package/xinetd/xinetd.mk b/package/xinetd/xinetd.mk
> index a209d12..c2f891b 100644
> --- a/package/xinetd/xinetd.mk
> +++ b/package/xinetd/xinetd.mk
> @@ -3,9 +3,11 @@
>   # xinetd
>   #
>   #############################################################
> -XINETD_VERSION = 2.3.15
> -XINETD_SOURCE  = xinetd-$(XINETD_VERSION).tar.gz
> -XINETD_SITE    = http://www.xinetd.org
> +XINETD_VERSION       = 2.3.15
> +XINETD_SOURCE        = xinetd-$(XINETD_VERSION).tar.gz
> +XINETD_SITE          = http://www.xinetd.org
> +XINETD_LICENSE       = Custom

To keep it consistent with similar cases (currently only bzip2 and
berkeleydb) I would better like to use "xinetd license" instead of
"Custom".
Or is there any reason that I didn't notice?

Thanks,
Luca

[Buildroot] [PATCH 6/6] xinetd: Add license info

[Danomi Manchego]

Okay, will do.

On Fri, Aug 3, 2012 at 4:18 AM, Luca Ceresoli <luca@lucaceresoli.net>wrote:
>
> To keep it consistent with similar cases (currently only bzip2 and
> berkeleydb) I would better like to use "xinetd license" instead of
> "Custom".
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120803/35f55cb8/attachment.html>

[Buildroot] A little summer game ? :-)

[Thomas Petazzoni]

Le Thu,  2 Aug 2012 22:53:47 -0400,
Danomi Manchego <danomimanchego123@gmail.com> a ?crit :

> Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>

Thanks for all the license information patches.

However, those patches are too easy, so let's make a little summer
game :-)

I will merge 3 "license information" patches from someone for each
patch that this developer sends to fix a build issue reported by the
autobuilders. This way, I'm pretty sure we'll manage to reduce the
number of build issues! This offer is obviously valid for all
contributors.

Ready to play the game ? :-)

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] A little summer game ? :-)

[Luca Ceresoli]

Thomas Petazzoni wrote:
> Le Thu,  2 Aug 2012 22:53:47 -0400,
> Danomi Manchego <danomimanchego123@gmail.com> a ?crit :
>
>> Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
>
> Thanks for all the license information patches.
>
> However, those patches are too easy, so let's make a little summer
> game :-)
>
> I will merge 3 "license information" patches from someone for each
> patch that this developer sends to fix a build issue reported by the
> autobuilders. This way, I'm pretty sure we'll manage to reduce the
> number of build issues! This offer is obviously valid for all
> contributors.
>
> Ready to play the game ? :-)
>
> Thomas

Wheee, what a fun, Thomas! Call it "Buildroot Summer Of Bugfix" and
people will flock in! :-D

Seriously, I admit I'm not investing a lot of time in fixing build
errors. This is in part due to the limited time available, but
another important blocking factor is that many build errors happen
with external, custom toolchains that are installed on your build
server.

I almost daily skim through the build failures and take a look at
those about by packages and/or architectures I use and somehow know.
These are already a small subset of all the possibilities.
But often I discover these happen with toolchains (and probably
architectures) I don't have an easy access to, so I just go along.

It would help if the external toolchains used for the builds were
always available within Buildroot, so we could just apply the
[def]config, run make, have an icy drink while it downloads and
fails building and then, happily refreshed, hunt for the bug.

I'm not saying this would be easy to do, but it would be helpful
to me.

Luca

[Buildroot] A little summer game ? :-)

[Thomas Petazzoni]

Hello,

Le Fri, 03 Aug 2012 11:04:22 +0200,
Luca Ceresoli <luca@lucaceresoli.net> a ?crit :

> Wheee, what a fun, Thomas! Call it "Buildroot Summer Of Bugfix" and
> people will flock in! :-D

I like this name, adopted! :-)

> Seriously, I admit I'm not investing a lot of time in fixing build
> errors. This is in part due to the limited time available, but
> another important blocking factor is that many build errors happen
> with external, custom toolchains that are installed on your build
> server.
> 
> I almost daily skim through the build failures and take a look at
> those about by packages and/or architectures I use and somehow know.
> These are already a small subset of all the possibilities.
> But often I discover these happen with toolchains (and probably
> architectures) I don't have an easy access to, so I just go along.
> 
> It would help if the external toolchains used for the builds were
> always available within Buildroot, so we could just apply the
> [def]config, run make, have an icy drink while it downloads and
> fails building and then, happily refreshed, hunt for the bug.
> 
> I'm not saying this would be easy to do, but it would be helpful
> to me.

Yes, I know this is a problem with the current autobuilders. My plan is
to make the tarballs of those external toolchains available somewhere,
so that people can easily install them as well. But that will take a
bit of time, and still leave some work when you want to reproduce a bug
(download the external toolchain, download .config, adjust .config to
match the path of the external toolchain on your local machine, build).
Or maybe, I should put all of them somewhere, and have my defconfig
download them from this common place. This could be a good idea to make
it easier to reproduce the build problems.

Also, there is a problem with BR external toolchains that are not (yet)
relocatable. I can create a tarball for them, but it will force you to
install them to /home/test/toolchains/... which is the location where
they are built on my build server. I guess the best solution for this
is just to make Buildroot toolchains relocatable :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] A little summer game ? :-)

[Thomas De Schampheleire]

Hi,

On Fri, Aug 3, 2012 at 11:19 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> Le Fri, 03 Aug 2012 11:04:22 +0200,
> Luca Ceresoli <luca@lucaceresoli.net> a ?crit :
>
>> Wheee, what a fun, Thomas! Call it "Buildroot Summer Of Bugfix" and
>> people will flock in! :-D
>
> I like this name, adopted! :-)

I like the game, I like the name.

>
>> Seriously, I admit I'm not investing a lot of time in fixing build
>> errors. This is in part due to the limited time available, but
>> another important blocking factor is that many build errors happen
>> with external, custom toolchains that are installed on your build
>> server.
>>
>> I almost daily skim through the build failures and take a look at
>> those about by packages and/or architectures I use and somehow know.
>> These are already a small subset of all the possibilities.
>> But often I discover these happen with toolchains (and probably
>> architectures) I don't have an easy access to, so I just go along.
>>
>> It would help if the external toolchains used for the builds were
>> always available within Buildroot, so we could just apply the
>> [def]config, run make, have an icy drink while it downloads and
>> fails building and then, happily refreshed, hunt for the bug.
>>
>> I'm not saying this would be easy to do, but it would be helpful
>> to me.
>
> Yes, I know this is a problem with the current autobuilders. My plan is
> to make the tarballs of those external toolchains available somewhere,
> so that people can easily install them as well. But that will take a
> bit of time, and still leave some work when you want to reproduce a bug
> (download the external toolchain, download .config, adjust .config to
> match the path of the external toolchain on your local machine, build).
> Or maybe, I should put all of them somewhere, and have my defconfig
> download them from this common place. This could be a good idea to make
> it easier to reproduce the build problems.
>
> Also, there is a problem with BR external toolchains that are not (yet)
> relocatable. I can create a tarball for them, but it will force you to
> install them to /home/test/toolchains/... which is the location where
> they are built on my build server. I guess the best solution for this
> is just to make Buildroot toolchains relocatable :-)

One of the hurdles I experience with looking/fixing the
autobuild-reported problems is that it's not clear:
- who is already looking at a given issue
- who has already looked at a certain issue and determined the
problem, without being able to fix it or not having time.
    => For these, some kind of comment field would be nice, attached
to each issue.

- whether there is progress. How many issues are remaining?
    => Due to the random build principle it's a bit hard to give exact
numbers, but maybe some alternative statistics are possible? For
example, the amount of issues found each week?

- at first sight, which issues are related? It would be nice if two
issues caused by the same thing could be identified as such. This may
not be completely possible in an automatic fashion, but we could try.
For example, on the first problem, a manual intervention could be
possible to specify which is the identifying string of that error
(part of the error message). If a later build finds a problem in a
given package, grep in the endlog for that identifying string. If
present, we assume it's the same problem. Obviously, the choice of the
identifying string is critical.
It could be that the same problem can occur in different packages, in
which case the above strategy wouldn't mark them as such. You could
expand the strategy across packages, so that you only check for the
string, but it may yield too much false relations.

This probably needs some further thinking...

Best regards,
Thomas

[Buildroot] A little summer game ? :-)

[Thomas Petazzoni]

Le Fri, 3 Aug 2012 13:07:01 +0200,
Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :

> One of the hurdles I experience with looking/fixing the
> autobuild-reported problems is that it's not clear:
> - who is already looking at a given issue
> - who has already looked at a certain issue and determined the
> problem, without being able to fix it or not having time.
>     => For these, some kind of comment field would be nice, attached
> to each issue.

To solve this, my idea was to connect the autobuilders with the bug
tracker: whenever there is a failed build, submit automatically a bug
to the bug tracker. This way, we don't reinvent the bug tracker wheel
with bug state, comments, who is assigned on the bug, etc.

> - whether there is progress. How many issues are remaining?
>     => Due to the random build principle it's a bit hard to give exact
> numbers, but maybe some alternative statistics are possible? For
> example, the amount of issues found each week?

Well, every day in the e-mail I'm giving the number of successful
builds and the number of failed builds. For sure, I could draw graphs
that show these numbers over time.

> - at first sight, which issues are related? It would be nice if two
> issues caused by the same thing could be identified as such. This may
> not be completely possible in an automatic fashion, but we could try.
> For example, on the first problem, a manual intervention could be
> possible to specify which is the identifying string of that error
> (part of the error message). If a later build finds a problem in a
> given package, grep in the endlog for that identifying string. If
> present, we assume it's the same problem. Obviously, the choice of the
> identifying string is critical.
> It could be that the same problem can occur in different packages, in
> which case the above strategy wouldn't mark them as such. You could
> expand the strategy across packages, so that you only check for the
> string, but it may yield too much false relations.

Yes, this is the big problem I have with automatically feeding failed
build reports to the bug tracker: a large number of duplicates that
would have to be sorted out.

So either we create an additional field in the bug tracker that holds
some "recognizable string of the build failure", and as you suggest we
look for this "recognizable string" in the last 100 lines of the build
output or something like that.

Or we try to experiment with text similarity algorithm to detect when
the end of two build outputs are fairly similar, and before submitting a
bug, I check if we have had a similar build output since the last month
or so.

But for now, I think you can fairly safely assume that nobody is
working on fixing build issues. If anyone works on an issue that takes
a while to figure out, just send an e-mail to the list saying you're
working on it.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [PATCH 1/6] cjson: Add license info

[Luca Ceresoli]

Danomi Manchego wrote:
> Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
> ---
>   package/cjson/cjson.mk |    2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/package/cjson/cjson.mk b/package/cjson/cjson.mk
> index a9b0bcf..44ddfc2 100644
> --- a/package/cjson/cjson.mk
> +++ b/package/cjson/cjson.mk
> @@ -7,6 +7,8 @@ CJSON_VERSION         = undefined
>   CJSON_SOURCE          = cJSONFiles.zip
>   CJSON_SITE            = http://$(BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/project/cjson/
>   CJSON_INSTALL_STAGING = YES
> +CJSON_LICENSE         = MIT
> +CJSON_LICENSE_FILES   = cJSON/README

Unfortunately that README is not a license file. Ok, it starts
with the license, but then goes on with a description of the
packages, how to build, etc. The license is just 10% of the whole
file. This is off topic in licenses.txt.

This is one of the known cases that `make legal-info` is unable to
handle correctly, so you should a) skip the definition of
CJSON_LICENSE_FILES, or b) ask the developers include a proper
license file, or c) extend legal-info to handle these cases. :)

Luca

[Buildroot] [PATCH 1/6] cjson: Add license info

[Danomi Manchego]

On Fri, Aug 3, 2012 at 4:38 AM, Luca Ceresoli <luca@lucaceresoli.net> wrote:
>
> Unfortunately that README is not a license file. Ok, it starts
> with the license, but then goes on with a description of the
> packages, how to build, etc. The license is just 10% of the whole
> file. This is off topic in licenses.txt.
>

Doh, you're correct, the license part is just the author's file header,
just like the actual source.  I hadn't noticed that.


> This is one of the known cases that `make legal-info` is unable to
> handle correctly, so you should a) skip the definition of
> CJSON_LICENSE_FILES, or b) ask the developers include a proper
> license file, or c) extend legal-info to handle these cases. :)


cJSON is not updated often, so I will resubmit the patch without the FILES
definition, and then think about the other two options for later.  Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20120803/8d863a95/attachment.html>

[Buildroot] [PATCH 1/6] cjson: Add license info

[Thomas Petazzoni]

Le Thu,  2 Aug 2012 22:53:47 -0400,
Danomi Manchego <danomimanchego123@gmail.com> a ?crit :

> Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>

Thanks. Applied v2 for cjson and xinetd. Applied v1 for expat, lua,
luacjson.

luaexpat not applied due to the comments of Luca.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com