[1/6] cjson: Add license info

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

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

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

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

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

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

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

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.

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