[Buildroot] buildroot & GPL

Sagaert Johan sagaert.johan at skynet.be
Tue Dec 20 09:57:31 UTC 2011


Hi

Have a look at http://www.qnap.com/GPL.asp what they do, there is however a difference.
Qnap is making hardware with a rootfs based on GPL sources, buildroot is providing a toolchain.

I don't think the tarball sources should be provided. Nobody does : example if you want to build GDB you need a compiler, but that
does not mean GDB has to provide the tarballs of the compiler as well.

Notice that QNAP provides some of the tarballs, but GCC is not one of them.
Snippet from the GPL list of QNAP
--- This file was automatically generated by build_GPL.sh ---

List of contains
===============================================
src/u-boot-3.5.3
licenses/u-boot-3.5.3

src/u-boot-1.1.4
licenses/u-boot-1.1.4

src/netatalk-2.1
licenses/netatalk-2.1

src/samba-3.5.2
licenses/samba-3.5.2

src/mysql-5.1.36
licenses/mysql-5.1.36

src/sqlite-3.4.1
NO LICENSE FILE

src/proftpd-1.3.2e
licenses/proftpd-1.3.2e

................
................

src/nfs-utils-1.2.1
licenses/nfs-utils-1.2.1

src/libtorrent-rasterbar-0.14.5
NO LICENSE FILE


src/linux-2.6.33.2-arm
licenses/linux-2.6.33.2-arm

src/linux-2.6.33.2
licenses/linux-2.6.33.2

src/netkit-ftp-0.17
NO LICENSE FILE

src/parted-2.2
licenses/parted-2.2

src/LVM2.2.02.60
licenses/LVM2.2.02.60

src/ffmpeg-0.5
licenses/ffmpeg-0.5

................
................

Johan

-----Oorspronkelijk bericht-----
Van: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] Namens buildroot-request at busybox.net
Verzonden: dinsdag 20 december 2011 9:39
Aan: buildroot at busybox.net
Onderwerp: buildroot Digest, Vol 66, Issue 97

Send buildroot mailing list submissions to
	buildroot at busybox.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.busybox.net/mailman/listinfo/buildroot
or, via email, send a message with subject or body 'help' to
	buildroot-request at busybox.net

You can reach the person managing the list at
	buildroot-owner at busybox.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of buildroot digest..."


Today's Topics:

   1. Re: Buildroot and GPL compliance (Luca Ceresoli)
   2. Re: Buildroot and GPL compliance (Luca Ceresoli)
   3. tutorial to extend buildroot? (vbr vbr)
   4. Re: tutorial to extend buildroot? (Thomas De Schampheleire)
   5. Re: [PATCH 2/3] Rework of the init system (Arnout Vandecappelle)


----------------------------------------------------------------------

Message: 1
Date: Mon, 19 Dec 2011 22:02:25 +0100
From: Luca Ceresoli <luca at lucaceresoli.net>
To: Thomas De Schampheleire <patrickdepinguin+buildroot at gmail.com>
Cc: buildroot <buildroot at busybox.net>
Subject: Re: [Buildroot] Buildroot and GPL compliance
Message-ID: <4EEFA661.5010503 at lucaceresoli.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Thomas,
thank you for having started the discussion on this topic.

Thomas De Schampheleire wrote:
> Hi,
>
> I would like to bring up the topic of complying with open-source
> software licenses (among which GPL/LGPL) in embedded projects using
> buildroot. In part to get answers, but also to determine what needs to
> be done in buildroot to automate certain aspects of this compliancy.
> The topic has been touched on Buildroot Developer Day, and the report
> thereof.

...

> Some discussion topics:
> * There has already been some discussion on BDD and the report
> regarding the inclusion of the .config file or not. In my opinion, the
> .config file is necessary to recreate the whole system, and as such
> should be part of the distribution. Some have expressed doubts as to
> whether every company would be willing to share the configuration, as
> it can share too much knowledge about the system. Examples as to what
> information is too sensitive is welcome.

I don't think it is mandatory to allow the recreation of the whole
system, but I discuss this point in detail below.

Nevertheless, I think the .config (or a defconfig) should be
distributed as well, but for different reasons.
Some packages have menuconfig options to tweak the configuration flags
(e.g. BR2_PACKAGE_FFMPEG_ENCODERS), and as such I think they fall in the
category of "scripts used to control compilation".

>
> * What about the tarballs? Should the tarballs themselves be included
> in the distribution, or would they be downloaded from the web by the
> user running buildroot? I think it is safer to include the tarballs,
> since you never know whether the official location will continue to
> exist in the future (or be temporarily out-of-order, as with
> kernel.org)

GPL allows the source to be distributed as "copy from a designated
place", but only when the object code is distributed in the same way.
But I cannot think of an embedded system made using Buildroot that is
shipped without any rootfs already on board...

So, unless there are counterexamples, I think distributing the tarballs
is the only option for BR.

>
> * What about the toolchain? In our system, the toolchain is prebuilt
> with buildroot/crosstool-ng, and used as external toolchain. If we
> distribute the toolchain as such in binary form, then it will also be
> subjected to GPL obligations. In that case, next to the set of sources
> that make up the target embedded system, there is another set of
> sources that are used to compile/link these sources. This means that
> the gcc sources and the sources for various host tools that may be
> used (like host-automake) should also be distributed, along with the
> ways to build them.
> What is the best practice? Provide the user with a unified .config
> that builds the toolchain on-the-fly and then immediately uses it to
> generate the embedded system? Or provide two .configs, one to generate
> the toolchain, and another one to generate the actual system with the
> toolchain?

The choice of external or internal toolchain should be primarily based
on technical and practical engineering choices, among which the
simplicity of the GPL compliance procedures plays only a limited role.

The GPL simply states that these sources have to be provided, which
is feasible whichever kind on toolchain is used in Buildroot.

>
> * How to handle proprietary applications? Even though during
> development these applications may be build from within buildroot
> (when sources are available), one would typically not want to
> distribute the sources to the end-user. Still, in order to be able to
> regenerate the system, I think the user should have access to the
> binary versions of these applications. How do we handle this, what is
> the best practice?
> One solution is to place them in output/target directly, before
> creating the buildroot tarball. Downside is that a 'make clean' would
> remove these applications. Alternatively, one could use the customize
> package for this purpose. This would require a separate .config file
> for use by the end-user, but this may be ok and maybe needed for the
> toolchain anyhow, depending on the output of the previous point.

Is it really mandatory to make the end user able to build the entire
system?
Here's why I don't think so.

For programs and libraries, there is a clear relationship between the
"source code" and the "object code or executable form": the latter is
a binary form of the former, from which it is obtained through a
process that is automated by the toolchain and the build scripts.

OTOH, the product of Buildroot is a root filesystem, which is not
a binary form of BR's sources. Buildroot is what the GPLv2 defines "the
scripts used to control compilation and installation of the executable".
In fact, just like gcc or make, Buildroot itself is not present in the
final image (well, except for the skeleton files and a little more).

Each executable or library file in the rootfs is a binary form of
a package: /bin/busybox is a binary form of Busybox's sources,
/usr/bin/myapp is a binary form of my own (proprietary) application
source code.

So, Buildroot has to be distributed because it is required to build each
single executable and library whose sources are GPL-licensed, not
because one has to be able to build the entire root filesystem.

For example, if an embedded device contains a modified busybox and a
proprietary application, anybody who receives the device has the right
to obtain the modified busybox's sources and the tools+scripts
necessary to compile it (which in our case means toolchain + buildroot).
But I do not see any legal obligation to make him able to build the
entire rootfs.

But of course I am not a lawyer.

It would be good the hear the main BR developers' opinion about this
and, why not, to add a notice at the beginning of COPYING clarifying
what is the intention of Buildroot developers.
I think of something like the note on top of the COPYING file in the
Linux source tree.

>
> * What about changes to buildroot itself? Since buildroot is GPL, any
> distribution of buildroot comes with obligations as well. One of these
> obligations is the requirement to clearly advertise changes to the GPL
> software.
>
> [quote from the GPLv2 license:]
>    2. You may modify your copy or copies of the Program or any portion
> of it, thus forming a work based on the Program, and copy and
> distribute such modifications or work under the terms of Section 1
> above, provided that you also meet all of these conditions:
>
>      a) You must cause the modified files to carry prominent notices
>      stating that you changed the files and the date of any change.
> [endquote]
>
>   However, the way I see it, this is not the typical way of working.
> The workflow in buildroot is that you submit patches to the list,
> which can then be included. Although the patch itself contains the
> name of the author and the e-mail header bears the date, the modified
> files do not typically contain this information.
> In my case, I make modifications to buildroot in our own repository. I
> try to submit most of these changes to the list, but not all of them
> are fit for mainstream, and submitted patches are not applied
> immediately. So, when releasing the system, there will still be
> unsubmitted changes. These changes do not comply with point 2a above,
> since the files do not contain the required metadata.
> Technically, the only solution I see is to add 'prominent notices' to
> modified files in our own repository, but manually remove them when
> submitting patches to the buildroot list. This is annoying but may be
> the only legal possibility. How do others see this?

If've never really understood the rationale behind this GPL requirement,
although it might have had some use in the pre-VCS era.

For Buildroot recipe files in particular, many of which are very small, 
these notices would sometimes take more space than the actual code.
This would quickly become unsustainable bloat.

I'm afraid I have no strong opinion about this point. I can only observe
that nobody seems to miss these prominent notes in the Buildroot
sources.


Luca


------------------------------

Message: 2
Date: Mon, 19 Dec 2011 22:08:37 +0100
From: Luca Ceresoli <luca at lucaceresoli.net>
To: Stephan Hoffmann <sho at relinux.de>
Cc: buildroot at busybox.net
Subject: Re: [Buildroot] Buildroot and GPL compliance
Message-ID: <4EEFA7D5.8060709 at lucaceresoli.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Stephan,

Stephan Hoffmann wrote:
>> Technically, the only solution I see is to add 'prominent notices' to
>> modified files in our own repository, but manually remove them when
>> submitting patches to the buildroot list. This is annoying but may be
>> the only legal possibility. How do others see this?
> I think we should try to find out how other projects handle this or how
> lawyers or GNU comment on this.

Sounds like a good idea. I think the FSF provides free (as in beer)
consultancy to free (as in speech) software projects of some importance.
It might be worth trying, after we have focused on a few precise
questions.

Luca


------------------------------

Message: 3
Date: Mon, 19 Dec 2011 17:47:42 -0800
From: vbr vbr <vvvg77 at gmail.com>
To: Buildroot List <buildroot at busybox.net>
Subject: [Buildroot] tutorial to extend buildroot?
Message-ID:
	<CAOrAeomixni4EZqKWV0p9bVfg9eOsQ+4LP4=CyK6POTsiga2iw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

I have set up my buildroot environment, built an external toolchain
(crosstool ng) with uClibc, and I understand how to add autotools-based
packages to buildroot. I committed buildroot source to my svn repo and most
of the tarballs that I needed which sit in the dl directory. Everything
works great!

Now I have private programs and libraries that I would want to add in
buildroot infrastructure too, but I don't want to add them in the form of a
tarball like other open-source tools and libraries. I just want to commit
the source code for each library and integrate their respective makefiles
(or create a new makefile for each of them to work) with buildroot. (no
tarball involved).

Does buildroot infrastructure/makefiles support that? Any guidelines or
examples?
I haven't found info regarding that question in the online documentation so
far.

Thanks
Vincent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111219/f6dd9f4f/attachment-0001.html>

------------------------------

Message: 4
Date: Tue, 20 Dec 2011 08:33:38 +0100
From: Thomas De Schampheleire <patrickdepinguin+buildroot at gmail.com>
To: vbr vbr <vvvg77 at gmail.com>
Cc: Buildroot List <buildroot at busybox.net>
Subject: Re: [Buildroot] tutorial to extend buildroot?
Message-ID:
	<CAAXf6LXrANu2mfxX6zjVGRZYUKH7Ud=wv+Xh7N0p338yxSMHpQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Hello Vincent,

On Tue, Dec 20, 2011 at 2:47 AM, vbr vbr <vvvg77 at gmail.com> wrote:
> Hi,
>
> I have set up my buildroot environment, built an external toolchain
> (crosstool ng) with uClibc, and I understand how to add autotools-based
> packages to buildroot. I committed buildroot source to my svn repo and most
> of the tarballs that I needed which sit in the dl directory. Everything
> works great!

That's nice to hear!

>
> Now I have private programs and libraries that I would want to add in
> buildroot infrastructure too, but I don't want to add them in the form of a
> tarball like other open-source tools and libraries. I just want to commit
> the source code for each library and integrate their respective makefiles
> (or create a new makefile for each of them to work) with buildroot. (no
> tarball involved).
>
> Does buildroot infrastructure/makefiles support that? Any guidelines or
> examples?
> I haven't found info regarding that question in the online documentation so
> far.

You could either use the git, svn, bzr or hg site methods, or use the
'local' site method.
The first set of methods will automatically clone the right revision
from your repository and build it. The revision itself is packaged in
a tarball in the background, but I don't think this bothers you. It is
transparent. All you have to do is specify the revision to use in the
.mk file.
This is described in the buildroot documentation (search for
LIBFOO_SITE_METHOD).

The local site method allows you to use an already existing clone or
source base. In this case, you point buildroot to the path where this
working directory is located. You can have uncommitted files there,
which is useful during development. This feature is described in the
following blog post made by Thomas Petazzoni:
http://free-electrons.com/blog/buildroot-2011-11/
It describes some of the new features of buildroot 2011.11 that are
not yet documented.

Best regards,
Thomas


------------------------------

Message: 5
Date: Tue, 20 Dec 2011 09:03:41 +0100
From: Arnout Vandecappelle <arnout at mind.be>
To: buildroot at busybox.net
Cc: Maxime Ripard <maxime.ripard at free-electrons.com>
Subject: Re: [Buildroot] [PATCH 2/3] Rework of the init system
Message-ID: <201112200903.41149.arnout at mind.be>
Content-Type: Text/Plain;  charset="iso-8859-1"

On Wednesday 23 November 2011 12:30:10 Maxime Ripard wrote:
> Since we have now two uncompatible init systems, and we want only one of
> them at the same time in the rootfs, we need to select a particular init
> system. This patch also adds $(PKG)_INIT_SYSV and $(PKG)_INIT_SYSTEMD
> variables, that basically moves the init script installation in the
> package infrastructure, and installs them only when needed.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout at mind.be>

> ---
>  package/Makefile.package.in  |    8 ++++++++
>  package/busybox/busybox.mk   |   11 +++++++++++
>  package/systemd/Config.in    |    1 +
>  package/sysvinit/Config.in   |    1 +
>  package/sysvinit/sysvinit.mk |    5 -----
>  target/generic/Config.in     |   19 +++++++++++++++++++
>  6 files changed, 40 insertions(+), 5 deletions(-)
> 
> diff --git a/package/Makefile.package.in b/package/Makefile.package.in
> index bd9ceb5..c0684d0 100644
> --- a/package/Makefile.package.in
> +++ b/package/Makefile.package.in
> @@ -367,6 +367,10 @@ $(BUILD_DIR)/%/.stamp_images_installed:
>  # Install to target dir
>  $(BUILD_DIR)/%/.stamp_target_installed:
>  	@$(call MESSAGE,"Installing to target")
> +	$(if $(and $(BR2_INIT_SYSTEMD),$($(PKG)_INIT_SYSTEMD)),\
> +		$(foreach init,$($(PKG)_INIT_SYSTEMD),$(INSTALL) -m 0755 -D $(init) $(TARGET_DIR)/etc/init.d/$(notdir $(init))))
> +	$(if $(and $(or $(BR2_INIT_SYSV),$(BR2_INIT_BUSYBOX)),$($(PKG)_INIT_SYSV)),\
> +		$(foreach init,$($(PKG)_INIT_SYSV),$(INSTALL) -m 0755 -D $(init) $(TARGET_DIR)/etc/init.d/$(notdir $(init))))
 Since this is used twice, it makes sense to either define a function for
it or to go over SYSTEMD and SYSV in a loop.  Also to simplify things, I
would rename BR2_INIT_SYSV to BR2_INIT_SYSVINIT and define an additional 
BR2_INIT_SYSV that is selected by both INIT_BUSYBOX and INIT_SYSV (see 
below).  So this becomes (untested!):
	$(foreach style,SYSTEMD SYSV,\
	  $(if $(and $(BR2_INIT_$(style)),$($(PKG)_INIT_$(style))),\
	    $(foreach init,$($(PKG)_INIT_$(style)),\
	      $(INSTALL) -m 0755 -D $(init) $(TARGET_DIR)/etc/init.d/$(notdir $(init)))))

>  	$($(PKG)_INSTALL_TARGET_CMDS)
>  	$(foreach hook,$($(PKG)_POST_INSTALL_TARGET_HOOKS),$(call $(hook))$(sep))
>  	$(Q)touch $@
> @@ -384,6 +388,8 @@ $(BUILD_DIR)/%/.stamp_uninstalled:
>  	rm -f $($(PKG)_TARGET_INSTALL_STAGING)
>  	$($(PKG)_UNINSTALL_TARGET_CMDS)
>  	rm -f $($(PKG)_TARGET_INSTALL_TARGET)
> +	$(foreach init, $($(PKG)_INIT_SYSV), rm -f $(TARGET_DIR)/etc/init.d/$(notdir $(init)))
> +	$(foreach init, $($(PKG)_INIT_SYSTEMD), rm -f $(TARGET_DIR)/etc/init.d/$(notdir $(init)))
>  
>  # Remove package sources
>  $(BUILD_DIR)/%/.stamp_dircleaned:
> @@ -479,6 +485,8 @@ endif
>  endif
>  
>  $(2)_DEPENDENCIES		?=
> +$(2)_INIT_SYSTEMD		?=
> +$(2)_INIT_SYSV			?=
>  $(2)_INSTALL_STAGING		?= NO
>  $(2)_INSTALL_IMAGES		?= NO
>  $(2)_INSTALL_TARGET		?= YES
> diff --git a/package/busybox/busybox.mk b/package/busybox/busybox.mk
> index 9e91136..73c4969 100644
> --- a/package/busybox/busybox.mk
> +++ b/package/busybox/busybox.mk
> @@ -129,6 +129,16 @@ define BUSYBOX_DISABLE_MMU_APPLETS
>  endef
>  endif
>  
> +ifeq ($(BR2_INIT_BUSYBOX),y)
> +define BUSYBOX_SET_INIT
> +	$(call KCONFIG_ENABLE_OPT,CONFIG_INIT,$(BUSYBOX_BUILD_CONFIG))
> +endef
> +else
> +define BUSYBOX_SET_INIT
> +	$(call KCONFIG_DISABLE_OPT,CONFIG_INIT,$(BUSYBOX_BUILD_CONFIG))
> +endef
> +endif
> +
 I'm not sure if I'd want to have the disable there if BR2_INIT_BUSYBOX
is not selected.  There's nothing against a parallel install of
systemd and busybox-init, selectable by 'init=...' on the kernel
command line.  (Well, except that systemd's symlinks destroy busybox init.)

>  define BUSYBOX_INSTALL_LOGGING_SCRIPT
>  	if grep -q CONFIG_SYSLOGD=y $(@D)/.config; then \
>  		[ -f $(TARGET_DIR)/etc/init.d/S01logging ] || \
> @@ -145,6 +155,7 @@ define BUSYBOX_CONFIGURE_CMDS
>  	$(BUSYBOX_SET_BB_PWD)
>  	$(BUSYBOX_SET_LARGEFILE)
>  	$(BUSYBOX_SET_IPV6)
> +	$(BUSYBOX_SET_INIT)
>  	$(BUSYBOX_SET_RPC)
>  	$(BUSYBOX_PREFER_STATIC)
>  	$(BUSYBOX_SET_MDEV)
> diff --git a/package/systemd/Config.in b/package/systemd/Config.in
> index 09cedb9..33d5ccf 100644
> --- a/package/systemd/Config.in
> +++ b/package/systemd/Config.in
> @@ -1,5 +1,6 @@
>  config BR2_PACKAGE_SYSTEMD
>  	bool "systemd"
> +	depends on BR2_INIT_SYSTEMD
 Again, there is no reason why you can't have sysvinit and systemd in
parallel (except for the symlinks).  Also, if you really want them to
be mutually exclusive, I'd prefer the more explicit
	depends on !BR2_PACKAGE_SYSVINIT

>  	depends on BR2_PACKAGE_UDEV
>  	depends on BR2_PACKAGE_DBUS
>  	select BR2_PACKAGE_LIBCAP
> diff --git a/package/sysvinit/Config.in b/package/sysvinit/Config.in
> index 34ec391..d91c643 100644
> --- a/package/sysvinit/Config.in
> +++ b/package/sysvinit/Config.in
> @@ -1,5 +1,6 @@
>  config BR2_PACKAGE_SYSVINIT
>  	bool "sysvinit"
> +	depends on BR2_INIT_SYSV
>  	help
>  	  /sbin/init - parent of all processes
>  
> diff --git a/package/sysvinit/sysvinit.mk b/package/sysvinit/sysvinit.mk
> index 0d65c43..163ba9b 100644
> --- a/package/sysvinit/sysvinit.mk
> +++ b/package/sysvinit/sysvinit.mk
> @@ -8,11 +8,6 @@ SYSVINIT_SOURCE  = sysvinit_$(SYSVINIT_VERSION)dsf.orig.tar.gz
>  SYSVINIT_PATCH   = sysvinit_$(SYSVINIT_VERSION)dsf-13.1.diff.gz
>  SYSVINIT_SITE    = $(BR2_DEBIAN_MIRROR)/debian/pool/main/s/sysvinit
>  
> -# Override Busybox implementations if Busybox is enabled.
> -ifeq ($(BR2_PACKAGE_BUSYBOX),y)
> -SYSVINIT_DEPENDENCIES = busybox
> -endif
> -
>  define SYSVINIT_DEBIAN_PATCHES
>  	if [ -d $(@D)/debian/patches ]; then \
>  		support/scripts/apply-patches.sh $(@D) $(@D)/debian/patches \*.patch; \
> diff --git a/target/generic/Config.in b/target/generic/Config.in
> index a91de32..d9b93af 100644
> --- a/target/generic/Config.in
> +++ b/target/generic/Config.in
> @@ -32,6 +32,25 @@ config BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_UDEV
>  
>  endchoice
>  
> +choice
> +	prompt "Init system"
> +	default BR2_INIT_BUSYBOX
> +
> +config BR2_INIT_BUSYBOX
> +	bool "Busybox init"
> +	select BR2_PACKAGE_BUSYBOX
> +
> +config BR2_INIT_SYSTEMD
> +	bool "Use systemd"
> +	depends on BR2_PACKAGE_UDEV
 Missing:
	depends on BR2_PACKAGE_DBUS
 Also missing the comment in case the dependencies are not met.
> +	select BR2_PACKAGE_SYSTEMD
> +
> +config BR2_INIT_SYSV
> +	bool "Use systemV init"
> +	select BR2_PACKAGE_SYSVINIT
> +
> +endchoice
> +
 I'd prefer the ordering to be busybox, sysvinit, systemd, because:
- systemd is newer
- systemd has more dependencies


 Regards,
 Arnout


>  config BR2_ROOTFS_DEVICE_TABLE
>  	string "Path to the permission tables"
>  	default "target/generic/device_table.txt"
> 

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
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:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43


------------------------------

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

End of buildroot Digest, Vol 66, Issue 97
*****************************************



More information about the buildroot mailing list