[Buildroot] [PATCH 1/2] core/pkg-autotools: don't use APPLY_PATCHES for libtool patches

[Buildroot] [PATCH 1/2] core/pkg-autotools: don't use APPLY_PATCHES for libtool patches

[Romain Naour]

Since 19241598147e7555dce40b6dd44b28ef22b67ed9 <package>-reconfigure
target is broken.

$ make elementary-reconfigure
Applying buildroot-libtool-v2.4.4.patch using patch:
Error: duplicate filename 'buildroot-libtool-v2.4.4.patch'
Conflicting files are:
  already applied: buildroot/support/libtool/buildroot-libtool-v2.4.4.patch
  to be applied  : buildroot/support/libtool/buildroot-libtool-v2.4.4.patch

When a package use AUTORECONF, the libtool patch can be applied many
times as the <package>-reconfigure target is called. This is not a
problem since autoreconf will overwrite the previously patched files.

In addition to this, the .applied_patches_list file generated by
apply-patches.sh while patching ltmain.sh is not in the top-level
package source directory. Instead a duplicated .applied_patches_list
is generated beside patched ltmain.sh which can be in a subdirectory.

As noticed by Arnout Vandecappelle [1], the apply-patches.sh script
doesn't bring anything for the libtool patches.

"apply_patches.sh does the following:

* It handles directories -> not needed here.
* It handles compressed patches and tarballs -> not needed.
* It handles series files -> not needed.
* It handles errors in case of multiple patches -> not needed since
it's only one patch.
* It detects errors based on *.rej files -> not needed since it's only
a single patch so patch exit code is OK.
* It writes the patch list -> for libtool, this is quite silly because
it will be written in the directory where ltmain.sh is found, not in the
top-level directory, so you have these patch lists spread over the
source tree."

So for 2016.08 use patch directly rather than apply-patches.

[1] http://lists.busybox.net/pipermail/buildroot/2016-August/169810.html

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
---
 package/pkg-autotools.mk | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/package/pkg-autotools.mk b/package/pkg-autotools.mk
index 75e2df0..d1cdb89 100644
--- a/package/pkg-autotools.mk
+++ b/package/pkg-autotools.mk
@@ -65,14 +65,14 @@ define LIBTOOL_PATCH_HOOK
 		ltmain_patchlevel=`sed -n '/^[ \t]*VERSION=/{s/^[ \t]*VERSION=//;p;q;}' $$i | \
 		sed -e 's/\([0-9]*\.[0-9]*\.*\)\([0-9]*\).*/\2/' -e 's/\"//'`; \
 		if test $${ltmain_version} = '1.5'; then \
-			$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v1.5.patch; \
+			patch -i support/libtool/buildroot-libtool-v1.5.patch $${i}; \
 		elif test $${ltmain_version} = "2.2"; then\
-			$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v2.2.patch; \
+			patch -i support/libtool/buildroot-libtool-v2.2.patch $${i}; \
 		elif test $${ltmain_version} = "2.4"; then\
 			if test $${ltmain_patchlevel:-0} -gt 2; then\
-				$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v2.4.4.patch; \
+				patch -i support/libtool/buildroot-libtool-v2.4.4.patch $${i}; \
 			else \
-				$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v2.4.patch; \
+				patch -i support/libtool/buildroot-libtool-v2.4.patch $${i}; \
 			fi \
 		fi \
 	done
-- 
2.5.5

[Buildroot] [PATCH 2/2] doc: add libtool issue as Know issues

[Romain Naour]

Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
---
 docs/manual/known-issues.txt     | 4 ++++
 support/legal-info/README.header | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/docs/manual/known-issues.txt b/docs/manual/known-issues.txt
index acfe4ff..d89507e 100644
--- a/docs/manual/known-issues.txt
+++ b/docs/manual/known-issues.txt
@@ -33,3 +33,7 @@
 * The +prboom+ package triggers a compiler failure with the SuperH 4
   compiler from Sourcery CodeBench, version 2012.09.
 
+* [2016.08] The libtool patches are not listed as package patches due
+  to a technical issue. Thereby they are not taken into account by the
+  legal-info infra. This will be fixed in a follow up Buildroot
+  release.
diff --git a/support/legal-info/README.header b/support/legal-info/README.header
index 1f3524f..6ba8b56 100644
--- a/support/legal-info/README.header
+++ b/support/legal-info/README.header
@@ -20,6 +20,9 @@ This material is composed of the following items.
    with a file named 'series' that lists the patches in the order they were
    applied. Patches are under the same license as the files that they modify
    in the original package.
+   Note: Libtool patches from support/libtool/buildroot-libtool-v*..patch,
+   used by autotools based packages, have not been saved due to technical
+   limitations, you may need to collect it manually.
  * A manifest file listing the configured packages and related information.
  * The license text of the packages; they have been saved in the licenses/
    subdirectory.
-- 
2.5.5

[Buildroot] [PATCH 1/2] core/pkg-autotools: don't use APPLY_PATCHES for libtool patches

[Yann E. MORIN]

Romain, All,

On 2016-08-15 13:09 +0200, Romain Naour spake thusly:
> Since 19241598147e7555dce40b6dd44b28ef22b67ed9 <package>-reconfigure
> target is broken.
[--SNIP--]
> So for 2016.08 use patch directly rather than apply-patches.
> 
> [1] http://lists.busybox.net/pipermail/buildroot/2016-August/169810.html
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Arnout Vandecappelle <arnout@mind.be>

Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

> ---
>  package/pkg-autotools.mk | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/package/pkg-autotools.mk b/package/pkg-autotools.mk
> index 75e2df0..d1cdb89 100644
> --- a/package/pkg-autotools.mk
> +++ b/package/pkg-autotools.mk
> @@ -65,14 +65,14 @@ define LIBTOOL_PATCH_HOOK
>  		ltmain_patchlevel=`sed -n '/^[ \t]*VERSION=/{s/^[ \t]*VERSION=//;p;q;}' $$i | \
>  		sed -e 's/\([0-9]*\.[0-9]*\.*\)\([0-9]*\).*/\2/' -e 's/\"//'`; \
>  		if test $${ltmain_version} = '1.5'; then \
> -			$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v1.5.patch; \
> +			patch -i support/libtool/buildroot-libtool-v1.5.patch $${i}; \
>  		elif test $${ltmain_version} = "2.2"; then\
> -			$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v2.2.patch; \
> +			patch -i support/libtool/buildroot-libtool-v2.2.patch $${i}; \
>  		elif test $${ltmain_version} = "2.4"; then\
>  			if test $${ltmain_patchlevel:-0} -gt 2; then\
> -				$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v2.4.4.patch; \
> +				patch -i support/libtool/buildroot-libtool-v2.4.4.patch $${i}; \
>  			else \
> -				$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v2.4.patch; \
> +				patch -i support/libtool/buildroot-libtool-v2.4.patch $${i}; \
>  			fi \
>  		fi \
>  	done
> -- 
> 2.5.5
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  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 2/2] doc: add libtool issue as Know issues

[Yann E. MORIN]

Romain, All,

In title: "Know" -> "Known".

On 2016-08-15 13:09 +0200, Romain Naour spake thusly:
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Arnout Vandecappelle <arnout@mind.be>
> ---
>  docs/manual/known-issues.txt     | 4 ++++
>  support/legal-info/README.header | 3 +++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/docs/manual/known-issues.txt b/docs/manual/known-issues.txt
> index acfe4ff..d89507e 100644
> --- a/docs/manual/known-issues.txt
> +++ b/docs/manual/known-issues.txt
> @@ -33,3 +33,7 @@
>  * The +prboom+ package triggers a compiler failure with the SuperH 4
>    compiler from Sourcery CodeBench, version 2012.09.
>  
> +* [2016.08] The libtool patches are not listed as package patches due
> +  to a technical issue. Thereby they are not taken into account by the
> +  legal-info infra. This will be fixed in a follow up Buildroot

s/(infra)/\1structure/

> +  release.
> diff --git a/support/legal-info/README.header b/support/legal-info/README.header
> index 1f3524f..6ba8b56 100644
> --- a/support/legal-info/README.header
> +++ b/support/legal-info/README.header
> @@ -20,6 +20,9 @@ This material is composed of the following items.
>     with a file named 'series' that lists the patches in the order they were
>     applied. Patches are under the same license as the files that they modify
>     in the original package.
> +   Note: Libtool patches from support/libtool/buildroot-libtool-v*..patch,
                                                                  ---^
Superfluous dot.

> +   used by autotools based packages, have not been saved due to technical
> +   limitations, you may need to collect it manually.

*to collect them

Otherwsie:

Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Regards,
Yann E. MORIN.

>   * A manifest file listing the configured packages and related information.
>   * The license text of the packages; they have been saved in the licenses/
>     subdirectory.
> -- 
> 2.5.5
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  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 1/2] core/pkg-autotools: don't use APPLY_PATCHES for libtool patches

[Arnout Vandecappelle]

Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
 Built and reconfigured a bunch of autotools packages with and without AUTORECONF.

 However, some minor spelling nits.

On 15-08-16 13:09, Romain Naour wrote:
> Since 19241598147e7555dce40b6dd44b28ef22b67ed9 <package>-reconfigure
                                                ^the
> target is broken.
> 
> $ make elementary-reconfigure
> Applying buildroot-libtool-v2.4.4.patch using patch:
> Error: duplicate filename 'buildroot-libtool-v2.4.4.patch'
> Conflicting files are:
>   already applied: buildroot/support/libtool/buildroot-libtool-v2.4.4.patch
>   to be applied  : buildroot/support/libtool/buildroot-libtool-v2.4.4.patch
> 
> When a package use AUTORECONF, the libtool patch can be applied many
                 uses                                             a second time
(it can be applied many times the first time the package is configured, but
that's not the issue here; the point is that the same ltmain.sh in the same
directory is patched a second time).

> times as the <package>-reconfigure target is called. This is not a
> problem since autoreconf will overwrite the previously patched files.
> 
> In addition to this, the .applied_patches_list file generated by
> apply-patches.sh while patching ltmain.sh is not in the top-level
> package source directory. Instead a duplicated .applied_patches_list
> is generated beside patched ltmain.sh which can be in a subdirectory.
                     ^the

> 
> As noticed by Arnout Vandecappelle [1], the apply-patches.sh script
> doesn't bring anything for the libtool patches.
> 
> "apply_patches.sh does the following:
> 
> * It handles directories -> not needed here.
> * It handles compressed patches and tarballs -> not needed.
> * It handles series files -> not needed.
> * It handles errors in case of multiple patches -> not needed since
> it's only one patch.
> * It detects errors based on *.rej files -> not needed since it's only
> a single patch so patch exit code is OK.
> * It writes the patch list -> for libtool, this is quite silly because
> it will be written in the directory where ltmain.sh is found, not in the
> top-level directory, so you have these patch lists spread over the
> source tree."

 Nicely written :-P

> 
> So for 2016.08 use patch directly rather than apply-patches.

 Actually, I'd keep it like this even after 2016.08, see my comments in [2/2].

 Regards,
 Arnout

> 
> [1] http://lists.busybox.net/pipermail/buildroot/2016-August/169810.html
> 
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Arnout Vandecappelle <arnout@mind.be>
> ---
>  package/pkg-autotools.mk | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/package/pkg-autotools.mk b/package/pkg-autotools.mk
> index 75e2df0..d1cdb89 100644
> --- a/package/pkg-autotools.mk
> +++ b/package/pkg-autotools.mk
> @@ -65,14 +65,14 @@ define LIBTOOL_PATCH_HOOK
>  		ltmain_patchlevel=`sed -n '/^[ \t]*VERSION=/{s/^[ \t]*VERSION=//;p;q;}' $$i | \
>  		sed -e 's/\([0-9]*\.[0-9]*\.*\)\([0-9]*\).*/\2/' -e 's/\"//'`; \
>  		if test $${ltmain_version} = '1.5'; then \
> -			$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v1.5.patch; \
> +			patch -i support/libtool/buildroot-libtool-v1.5.patch $${i}; \
>  		elif test $${ltmain_version} = "2.2"; then\
> -			$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v2.2.patch; \
> +			patch -i support/libtool/buildroot-libtool-v2.2.patch $${i}; \
>  		elif test $${ltmain_version} = "2.4"; then\
>  			if test $${ltmain_patchlevel:-0} -gt 2; then\
> -				$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v2.4.4.patch; \
> +				patch -i support/libtool/buildroot-libtool-v2.4.4.patch $${i}; \
>  			else \
> -				$(APPLY_PATCHES) $${i%/*} support/libtool buildroot-libtool-v2.4.patch; \
> +				patch -i support/libtool/buildroot-libtool-v2.4.patch $${i}; \
>  			fi \
>  		fi \
>  	done
> 


-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 2/2] doc: add libtool issue as Know issues

[Arnout Vandecappelle]

On 15-08-16 13:09, Romain Naour wrote:
> Signed-off-by: Romain Naour <romain.naour@gmail.com>
> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Arnout Vandecappelle <arnout@mind.be>
> ---
>  docs/manual/known-issues.txt     | 4 ++++
>  support/legal-info/README.header | 3 +++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/docs/manual/known-issues.txt b/docs/manual/known-issues.txt
> index acfe4ff..d89507e 100644
> --- a/docs/manual/known-issues.txt
> +++ b/docs/manual/known-issues.txt
> @@ -33,3 +33,7 @@
>  * The +prboom+ package triggers a compiler failure with the SuperH 4
>    compiler from Sourcery CodeBench, version 2012.09.
>  
> +* [2016.08] The libtool patches are not listed as package patches due
> +  to a technical issue. Thereby they are not taken into account by the
> +  legal-info infra. This will be fixed in a follow up Buildroot
> +  release.

 Personally, I don't see a reason to fix this. The only real fix would be to
generate a patch file on the complete tree after the libtool patch has been
applied to all ltmain.sh. However:

- The libtool patch will not even have been applied for AUTORECONF packages when
'make legal-info' is done without building first.

- This patch is pretty specific to buildroot, buildroot should be distributed
together with the rest of the source, so there is no technical need to have this
patch.

- ltmain.sh doesn't end up on the target so it's not part of the "complete and
corresponding source". It is part of the scripts needed for building, but so is
buildroot, so see above.

 So for me, the additional complexity of properly dealing with the libtool patch
is really not worth it ("keep things simple"). The comment in README.header is
sufficient. Therefore, I would not put this in the Known issues section, but
instead move it to the legal-notice.txt. BTW, the current text about patches
there is not up-to-date, because it still says that patches are not saved. I
propose to change it to the following (copied from README.header):

* The source code for all packages; this is saved in the +sources/+ and
  +host-sources/+ subdirectories for target and host packages respectively.
  The source code for packages that set +<PKG>_REDISTRIBUTE = NO+ will not be
  saved.
  Patches that were applied are also saved, along with a file named +series+
  that lists the patches in the order they were applied. Patches are under the
  same license as the files that they modify.
  Note: Buildroot applies additional patches to Libtool scripts of autotools
  packages. These patches can be found under +support/libtool+ in the buildroot
  source and are not saved with the package sources due to technical
  limitations. You may need to collect it manually.


> diff --git a/support/legal-info/README.header b/support/legal-info/README.header
> index 1f3524f..6ba8b56 100644
> --- a/support/legal-info/README.header
> +++ b/support/legal-info/README.header
> @@ -20,6 +20,9 @@ This material is composed of the following items.
>     with a file named 'series' that lists the patches in the order they were
>     applied. Patches are under the same license as the files that they modify
>     in the original package.
> +   Note: Libtool patches from support/libtool/buildroot-libtool-v*..patch,
> +   used by autotools based packages, have not been saved due to technical
> +   limitations, you may need to collect it manually.

 OK, but I think my version above is still a little better :-)


 Regards,
 Arnout


>   * A manifest file listing the configured packages and related information.
>   * The license text of the packages; they have been saved in the licenses/
>     subdirectory.
> 


-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH 2/2] doc: add libtool issue as Know issues

[Yann E. MORIN]

Arnout, Romain, All,

On 2016-08-16 00:44 +0200, Arnout Vandecappelle spake thusly:
> On 15-08-16 13:09, Romain Naour wrote:
> > Signed-off-by: Romain Naour <romain.naour@gmail.com>
> > Cc: "Yann E. MORIN" <yann.morin.1998@free.fr>
> > Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> > Cc: Arnout Vandecappelle <arnout@mind.be>
> > ---
> >  docs/manual/known-issues.txt     | 4 ++++
> >  support/legal-info/README.header | 3 +++
> >  2 files changed, 7 insertions(+)
> > 
> > diff --git a/docs/manual/known-issues.txt b/docs/manual/known-issues.txt
> > index acfe4ff..d89507e 100644
> > --- a/docs/manual/known-issues.txt
> > +++ b/docs/manual/known-issues.txt
> > @@ -33,3 +33,7 @@
> >  * The +prboom+ package triggers a compiler failure with the SuperH 4
> >    compiler from Sourcery CodeBench, version 2012.09.
> >  
> > +* [2016.08] The libtool patches are not listed as package patches due
> > +  to a technical issue. Thereby they are not taken into account by the
> > +  legal-info infra. This will be fixed in a follow up Buildroot
> > +  release.
> 
>  Personally, I don't see a reason to fix this. The only real fix would be to
> generate a patch file on the complete tree after the libtool patch has been
> applied to all ltmain.sh.

Funny how I almost told Romain the same on IRC. :-)

> However:
> 
> - The libtool patch will not even have been applied for AUTORECONF packages when
> 'make legal-info' is done without building first.

In which case we could overcome this with something like:

    package/pkg-autotools.mk

        # Defined only once, outside of inner-autotools-package:
        # Copy the libtool patches for legal-info.
        # $(1): destination directory
        define LEGAL_INFO_LIBTOOL
            mkdir -p $(1)/libtool
            cp -a support/libtool/*.patch $(1)/libtool/
        endef

        # Then in inner-autotools-package:
        define $(2)_LEGAL_INFO_LIBTOOL
            $$(call LEGAL_INFO_LIBTOOL,$$($(2)_REDIST_SOURCES_DIR))
        endef
        $(2)_POST_LEGAL_INFO_HOOKS += $(2)_LEGAL_INFO_LIBTOOL

This way they are saved, always, per-package. We can even add a little
blurb in the legal-info dir, beside the libtool patches, that briefly
explains what to do with those. We could also be smart and only save the
patch of the version of libtool needed, but that's probably not worth
the try...

Or, instead of saving that per-package, we could save then only once, in
a separate directory, legal-info/misc/libtool/ for example. I'm not too
fond of this, because then the legal-info for a package no longer is in
a single directory. I would prefer the libtool patches be duplicated for
every packages (autotools ones, of course).

> - This patch is pretty specific to buildroot, buildroot should be distributed
> together with the rest of the source, so there is no technical need to have this
> patch.

Why are they specific to Buildroot? They fix libtool idiosyncrasies and
weirdnes about static linking in cross-complation. They are definitely
not specific to Buildroot in anyway I can see...

> - ltmain.sh doesn't end up on the target so it's not part of the "complete and
> corresponding source".

Wrong. "complete and corresponding source" includes "the scripts used to
control compilation and installation of the executable." (GPLv2, section
3.)

> It is part of the scripts needed for building, but so is
> buildroot, so see above.
> 
>  So for me, the additional complexity of properly dealing with the libtool patch
> is really not worth it ("keep things simple"). The comment in README.header is
> sufficient. Therefore, I would not put this in the Known issues section, but
> instead move it to the legal-notice.txt. BTW, the current text about patches
> there is not up-to-date, because it still says that patches are not saved. I
> propose to change it to the following (copied from README.header):
> 
> * The source code for all packages; this is saved in the +sources/+ and
>   +host-sources/+ subdirectories for target and host packages respectively.
>   The source code for packages that set +<PKG>_REDISTRIBUTE = NO+ will not be
>   saved.
>   Patches that were applied are also saved, along with a file named +series+
>   that lists the patches in the order they were applied. Patches are under the
>   same license as the files that they modify.
>   Note: Buildroot applies additional patches to Libtool scripts of autotools

*autotools-based packages

>   packages. These patches can be found under +support/libtool+ in the buildroot
>   source and are not saved with the package sources due to technical
>   limitations. You may need to collect it manually.

*collect them

> > diff --git a/support/legal-info/README.header b/support/legal-info/README.header
> > index 1f3524f..6ba8b56 100644
> > --- a/support/legal-info/README.header
> > +++ b/support/legal-info/README.header
> > @@ -20,6 +20,9 @@ This material is composed of the following items.
> >     with a file named 'series' that lists the patches in the order they were
> >     applied. Patches are under the same license as the files that they modify
> >     in the original package.
> > +   Note: Libtool patches from support/libtool/buildroot-libtool-v*..patch,
> > +   used by autotools based packages, have not been saved due to technical
> > +   limitations, you may need to collect it manually.
> 
>  OK, but I think my version above is still a little better :-)

Oh, only so slightly! ;-)

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.  |
'------------------------------^-------^------------------^--------------------'