[Buildroot] Missing 'sys/queue.h' on musl

[Buildroot] Missing 'sys/queue.h' on musl

[Sergio Prado]

Dear all,

Musl does not provide a 'sys/queue.h' implementation [1].

This is causing problems with some packages that depends on it, like
f2fs-tools [2] and others packages that are already fixed like libtirpc [3].

Adding an implementation of 'sys/queue.h' as a patch (like in [3]) is a
proper way to fix this problem?

What about creating a package with the 'sys/queue.h' implementation and
installing it in the staging directory. Then we would just need to make all
packages that need it depend on it when compiling with musl. Is this a good
solution?

Any other suggestion?

[1]
http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_sys.2Fqueue.h_not_included_.3F
[2]
http://autobuild.buildroot.net/results/24bad2d06ab40024dacf136bee722072d587f84e
[3]
http://git.buildroot.net/buildroot/commit/?id=633d3320c16b5a3c6c4df82e89b9748daa9fd1fb

Best regards,

Sergio Prado
Embedded Labworks
Office: +55 11 2628-3461
Mobile: +55 11 97123-3420
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151128/86af57a1/attachment.html>

[Buildroot] Missing 'sys/queue.h' on musl

[Thomas Petazzoni]

Sergio,

On Sat, 28 Nov 2015 15:31:36 -0200, Sergio Prado wrote:

> Musl does not provide a 'sys/queue.h' implementation [1].
> 
> This is causing problems with some packages that depends on it, like
> f2fs-tools [2] and others packages that are already fixed like libtirpc [3].
> 
> Adding an implementation of 'sys/queue.h' as a patch (like in [3]) is a
> proper way to fix this problem?
> 
> What about creating a package with the 'sys/queue.h' implementation and
> installing it in the staging directory. Then we would just need to make all
> packages that need it depend on it when compiling with musl. Is this a good
> solution?

This seems like a very good idea to me: creating a package that
installs sys/queue.h. It's a lot better than patching all the packages
that use sys/queue.h to make them build with musl.

Do you volunteer to work on this?

Thanks!

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

[Buildroot] Missing 'sys/queue.h' on musl

[Sergio Prado]

Hi Thomas,

2015-11-28 15:49 GMT-02:00 Thomas Petazzoni <
thomas.petazzoni@free-electrons.com>:

> Sergio,
>
> On Sat, 28 Nov 2015 15:31:36 -0200, Sergio Prado wrote:
>
> > Musl does not provide a 'sys/queue.h' implementation [1].
> >
> > This is causing problems with some packages that depends on it, like
> > f2fs-tools [2] and others packages that are already fixed like libtirpc
> [3].
> >
> > Adding an implementation of 'sys/queue.h' as a patch (like in [3]) is a
> > proper way to fix this problem?
> >
> > What about creating a package with the 'sys/queue.h' implementation and
> > installing it in the staging directory. Then we would just need to make
> all
> > packages that need it depend on it when compiling with musl. Is this a
> good
> > solution?
>
> This seems like a very good idea to me: creating a package that
> installs sys/queue.h. It's a lot better than patching all the packages
> that use sys/queue.h to make them build with musl.
>
> Do you volunteer to work on this?
>

Yep. I'll do it.

The idea is use the implementation from NetBSD. Should queue.h stays inside
its package directory or should we create a repository for it? Another
option is to download the NetBSD sources from [1] but it is too big
(~140M). What is the best option?

[1] ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0/source/sets/


> Thanks!
>

Best regards,


>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151128/5d8345ed/attachment.html>

[Buildroot] Missing 'sys/queue.h' on musl

[Thomas Petazzoni]

Dear Sergio Prado,

On Sat, 28 Nov 2015 16:18:27 -0200, Sergio Prado wrote:

> The idea is use the implementation from NetBSD. Should queue.h stays inside
> its package directory or should we create a repository for it? Another
> option is to download the NetBSD sources from [1] but it is too big
> (~140M). What is the best option?

Just add it inside the package directory. See package/makedevs/ for an
example.

Thanks!

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

[Buildroot] Missing 'sys/queue.h' on musl

[Sergio Prado]

Instead of making each package that needs 'sys/queue.h' select this
package, it would be better to select this package automatically when a
musl toolchain is used. That way, we won't need to change any package.

It is possible to do that?

Sergio Prado
Embedded Labworks
Office: +55 11 2628-3461
Mobile: +55 11 97123-3420

2015-11-28 16:20 GMT-02:00 Thomas Petazzoni <
thomas.petazzoni@free-electrons.com>:

> Dear Sergio Prado,
>
> On Sat, 28 Nov 2015 16:18:27 -0200, Sergio Prado wrote:
>
> > The idea is use the implementation from NetBSD. Should queue.h stays
> inside
> > its package directory or should we create a repository for it? Another
> > option is to download the NetBSD sources from [1] but it is too big
> > (~140M). What is the best option?
>
> Just add it inside the package directory. See package/makedevs/ for an
> example.
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151128/dad23612/attachment.html>

[Buildroot] Missing 'sys/queue.h' on musl

[Thomas Petazzoni]

Hello,

On Sat, 28 Nov 2015 18:42:37 -0200, Sergio Prado wrote:
> Instead of making each package that needs 'sys/queue.h' select this
> package, it would be better to select this package automatically when a
> musl toolchain is used. That way, we won't need to change any package.
> 
> It is possible to do that?

Well, we could probably put this logic in the toolchain virtual
package, since it is the common point between the internal toolchain
and external toolchain backends (and we need sys/queue.h in both cases).

However, I am not sure if I wouldn't prefer packages that need
sys/queue.h to have an explicit dependency on the package installing
sys/queue.h. Since such package would itself have no dependency, it
would be just a matter of adding "select BR2_PACKAGE_SYS_QUEUE" in
Config.in and adding "sys-queue" in <pkg>_DEPENDENCIES.

Peter, Arnout, Yann, your opinion?

Thanks,

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

[Buildroot] Missing 'sys/queue.h' on musl

[Yann E. MORIN]

Thomas, All,

On 2015-11-29 09:28 +0100, Thomas Petazzoni spake thusly:
> On Sat, 28 Nov 2015 18:42:37 -0200, Sergio Prado wrote:
> > Instead of making each package that needs 'sys/queue.h' select this
> > package, it would be better to select this package automatically when a
> > musl toolchain is used. That way, we won't need to change any package.
> > 
> > It is possible to do that?
> 
> Well, we could probably put this logic in the toolchain virtual
> package, since it is the common point between the internal toolchain
> and external toolchain backends (and we need sys/queue.h in both cases).
> 
> However, I am not sure if I wouldn't prefer packages that need
> sys/queue.h to have an explicit dependency on the package installing
> sys/queue.h. Since such package would itself have no dependency, it
> would be just a matter of adding "select BR2_PACKAGE_SYS_QUEUE" in
> Config.in and adding "sys-queue" in <pkg>_DEPENDENCIES.
> 
> Peter, Arnout, Yann, your opinion?

I think it is best to handle it as a dependency of the toolchain
package. That way, it is transparent to packages.

That musl refuses to carry a sys/queue.h on philosophical reasons (as
they explain in their FAQ) while all the other main C libraries do (even
newlib!) is not ground for making it difficult for packagers to add a
new package.

Adding such a package would be a Buildroot peculiarity, which I would
prefer we avoid.

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] Missing 'sys/queue.h' on musl

[Arnout Vandecappelle]

On 29-11-15 10:53, Yann E. MORIN wrote:
> Thomas, All,
> 
> On 2015-11-29 09:28 +0100, Thomas Petazzoni spake thusly:
>> On Sat, 28 Nov 2015 18:42:37 -0200, Sergio Prado wrote:
>>> Instead of making each package that needs 'sys/queue.h' select this
>>> package, it would be better to select this package automatically when a
>>> musl toolchain is used. That way, we won't need to change any package.
>>>
>>> It is possible to do that?
>>
>> Well, we could probably put this logic in the toolchain virtual
>> package, since it is the common point between the internal toolchain
>> and external toolchain backends (and we need sys/queue.h in both cases).
>>
>> However, I am not sure if I wouldn't prefer packages that need
>> sys/queue.h to have an explicit dependency on the package installing
>> sys/queue.h. Since such package would itself have no dependency, it
>> would be just a matter of adding "select BR2_PACKAGE_SYS_QUEUE" in
>> Config.in and adding "sys-queue" in <pkg>_DEPENDENCIES.
>>
>> Peter, Arnout, Yann, your opinion?
> 
> I think it is best to handle it as a dependency of the toolchain
> package. That way, it is transparent to packages.
> 
> That musl refuses to carry a sys/queue.h on philosophical reasons (as
> they explain in their FAQ) while all the other main C libraries do (even
> newlib!) is not ground for making it difficult for packagers to add a
> new package.
> 
> Adding such a package would be a Buildroot peculiarity, which I would
> prefer we avoid.

 +1 to that.

 Also take into account that we only install it to staging, so there is really
nothing to gain from installing it conditionally.

 The only question is whether to do it in the toolchain virtual package (which
would be unusual to say the least), or duplicate it in the musl and external
toolchain packages. I actually think the latter is the way to go.

 When adding this, there's a small issue to take into account: a
buildroot-generated musl toolchain will already have queue.h, so for the
external toolchain support you probably have to check if it exists already in
the toolchain itself.


 Regards,
 Arnout

> 
> Regards,
> Yann E. MORIN.
> 


-- 
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] Missing 'sys/queue.h' on musl

[Thomas Petazzoni]

Hello,

On Sun, 29 Nov 2015 23:14:48 +0100, Arnout Vandecappelle wrote:

> > Adding such a package would be a Buildroot peculiarity, which I would
> > prefer we avoid.
> 
>  +1 to that.
> 
>  Also take into account that we only install it to staging, so there is really
> nothing to gain from installing it conditionally.
> 
>  The only question is whether to do it in the toolchain virtual package (which
> would be unusual to say the least), or duplicate it in the musl and external
> toolchain packages. I actually think the latter is the way to go.

That's all fine with me. It is a lot better than duplicating
sys/queue.h everywhere. It is kind of adding a patch on top of musl
that we would have to keep on our side forever, but since it's just a
separate header file, there's no maintenance cost, so I think it's fine.

Regarding doing it in the toolchain virtual package or duplicate in
musl and external toolchain packages, I don't have a strong opinion
either way, so if Arnout feels like doing the duplication is better
then so be it. Despite the duplication I also believe it is more
logical to have it in the musl and external toolchain packages, since
doing that in the toolchain virtual package would make that package no
longer purely virtual.

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

[Buildroot] Missing 'sys/queue.h' on musl

[Sergio Prado]

2015-11-29 20:33 GMT-02:00 Thomas Petazzoni <
thomas.petazzoni@free-electrons.com>:

> Hello,
>
> On Sun, 29 Nov 2015 23:14:48 +0100, Arnout Vandecappelle wrote:
>
> > > Adding such a package would be a Buildroot peculiarity, which I would
> > > prefer we avoid.
> >
> >  +1 to that.
> >
> >  Also take into account that we only install it to staging, so there is
> really
> > nothing to gain from installing it conditionally.
> >
> >  The only question is whether to do it in the toolchain virtual package
> (which
> > would be unusual to say the least), or duplicate it in the musl and
> external
> > toolchain packages. I actually think the latter is the way to go.
>
> That's all fine with me. It is a lot better than duplicating
> sys/queue.h everywhere. It is kind of adding a patch on top of musl
> that we would have to keep on our side forever, but since it's just a
> separate header file, there's no maintenance cost, so I think it's fine.
>
> Regarding doing it in the toolchain virtual package or duplicate in
> musl and external toolchain packages, I don't have a strong opinion
> either way, so if Arnout feels like doing the duplication is better
> then so be it. Despite the duplication I also believe it is more
> logical to have it in the musl and external toolchain packages, since
> doing that in the toolchain virtual package would make that package no
> longer purely virtual.
>

Thank you all.

I'll be sending the patch today.

Best regards,


>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151130/89066f94/attachment.html>

[Buildroot] Missing 'sys/queue.h' on musl

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Hello,
 > On Sun, 29 Nov 2015 23:14:48 +0100, Arnout Vandecappelle wrote:

 >> > Adding such a package would be a Buildroot peculiarity, which I would
 >> > prefer we avoid.
 >> 
 >> +1 to that.
 >> 
 >> Also take into account that we only install it to staging, so there is really
 >> nothing to gain from installing it conditionally.
 >> 
 >> The only question is whether to do it in the toolchain virtual package (which
 >> would be unusual to say the least), or duplicate it in the musl and external
 >> toolchain packages. I actually think the latter is the way to go.

 > That's all fine with me. It is a lot better than duplicating
 > sys/queue.h everywhere. It is kind of adding a patch on top of musl
 > that we would have to keep on our side forever, but since it's just a
 > separate header file, there's no maintenance cost, so I think it's fine.

 > Regarding doing it in the toolchain virtual package or duplicate in
 > musl and external toolchain packages, I don't have a strong opinion
 > either way, so if Arnout feels like doing the duplication is better
 > then so be it. Despite the duplication I also believe it is more
 > logical to have it in the musl and external toolchain packages, since
 > doing that in the toolchain virtual package would make that package no
 > longer purely virtual.

Indeed, I agree with Arnout here.

-- 
Bye, Peter Korsgaard

[Buildroot] Missing 'sys/queue.h' on musl

[Sergio Prado]

Hello All,

I'm not so familiar with the toolchain infrastructure, so I need some help
from buildroot wizards...:)

I have created a package called sys-queue that will only install queue.h on
the staging dir.

Then to make musl generated toolchain depends on sys-queue, I added the
following lines to toolchain/toolchain-buildroot/toolchain-buildroot.mk:

ifeq ($(BR2_TOOLCHAIN_BUILDROOT_MUSL),y)
TOOLCHAIN_BUILDROOT_DEPENDENCIES += sys-queue
endif

It worked like a charm. Is this the correct approach?

Also, I am struggling to find out a way to do the same thing on the
external toolchain. Using the DEPENDENCIES approach, it will process the
sys-queue package before the external toolchain package, and it is best to
do it after. Any ideas?

Thanks!

Sergio Prado
Embedded Labworks
Office: +55 11 2628-3461
Mobile: +55 11 97123-3420

2015-11-30 8:54 GMT-02:00 Peter Korsgaard <peter@korsgaard.com>:

> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> writes:
>
>  > Hello,
>  > On Sun, 29 Nov 2015 23:14:48 +0100, Arnout Vandecappelle wrote:
>
>  >> > Adding such a package would be a Buildroot peculiarity, which I would
>  >> > prefer we avoid.
>  >>
>  >> +1 to that.
>  >>
>  >> Also take into account that we only install it to staging, so there is
> really
>  >> nothing to gain from installing it conditionally.
>  >>
>  >> The only question is whether to do it in the toolchain virtual package
> (which
>  >> would be unusual to say the least), or duplicate it in the musl and
> external
>  >> toolchain packages. I actually think the latter is the way to go.
>
>  > That's all fine with me. It is a lot better than duplicating
>  > sys/queue.h everywhere. It is kind of adding a patch on top of musl
>  > that we would have to keep on our side forever, but since it's just a
>  > separate header file, there's no maintenance cost, so I think it's fine.
>
>  > Regarding doing it in the toolchain virtual package or duplicate in
>  > musl and external toolchain packages, I don't have a strong opinion
>  > either way, so if Arnout feels like doing the duplication is better
>  > then so be it. Despite the duplication I also believe it is more
>  > logical to have it in the musl and external toolchain packages, since
>  > doing that in the toolchain virtual package would make that package no
>  > longer purely virtual.
>
> Indeed, I agree with Arnout here.
>
> --
> Bye, Peter Korsgaard
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151130/d90f7f70/attachment.html>

[Buildroot] Missing 'sys/queue.h' on musl

[Thomas Petazzoni]

Dear Sergio Prado,

On Mon, 30 Nov 2015 13:07:36 -0200, Sergio Prado wrote:

> I have created a package called sys-queue that will only install queue.h on
> the staging dir.
> 
> Then to make musl generated toolchain depends on sys-queue, I added the
> following lines to toolchain/toolchain-buildroot/toolchain-buildroot.mk:
> 
> ifeq ($(BR2_TOOLCHAIN_BUILDROOT_MUSL),y)
> TOOLCHAIN_BUILDROOT_DEPENDENCIES += sys-queue
> endif
> 
> It worked like a charm. Is this the correct approach?

No, because this will only work for internal toolchains. So instead,
you need to put this dependency in two places:

 1/ In package/musl/musl.mk, where it should be an unconditional
    dependency.

 2/ In toolchain/toolchain-external/toolchain-external.mk, where it
    should be conditional on BR2_TOOLCHAIN_USES_MUSL.

> Also, I am struggling to find out a way to do the same thing on the
> external toolchain. Using the DEPENDENCIES approach, it will process the
> sys-queue package before the external toolchain package, and it is best to
> do it after. Any ideas?

Is it really a problem if it is processed before?

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

[Buildroot] Missing 'sys/queue.h' on musl

[Arnout Vandecappelle]

On 30-11-15 17:32, Thomas Petazzoni wrote:
> Dear Sergio Prado,
> 
> On Mon, 30 Nov 2015 13:07:36 -0200, Sergio Prado wrote:
> 
>> I have created a package called sys-queue that will only install queue.h on
>> the staging dir.
>>
>> Then to make musl generated toolchain depends on sys-queue, I added the
>> following lines to toolchain/toolchain-buildroot/toolchain-buildroot.mk:
>>
>> ifeq ($(BR2_TOOLCHAIN_BUILDROOT_MUSL),y)
>> TOOLCHAIN_BUILDROOT_DEPENDENCIES += sys-queue
>> endif
>>
>> It worked like a charm. Is this the correct approach?
> 
> No, because this will only work for internal toolchains. So instead,
> you need to put this dependency in two places:

 That's what Sergio was doing...

> 
>  1/ In package/musl/musl.mk, where it should be an unconditional
>     dependency.
> 
>  2/ In toolchain/toolchain-external/toolchain-external.mk, where it
>     should be conditional on BR2_TOOLCHAIN_USES_MUSL.
> 
>> Also, I am struggling to find out a way to do the same thing on the
>> external toolchain. Using the DEPENDENCIES approach, it will process the
>> sys-queue package before the external toolchain package, and it is best to
>> do it after. Any ideas?
> 
> Is it really a problem if it is processed before?

 It's actually good if it is processed before, so if there is a queue.h in the
external toolchain after all (e.g. for a buildroot-built external toolchain), it
will overwrite ours. At least, I think that that is what we want.

 Regards,
 Arnout

> 
> Thomas
> 


-- 
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] Missing 'sys/queue.h' on musl

[Sergio Prado]

2015-11-30 19:34 GMT-02:00 Arnout Vandecappelle <arnout@mind.be>:

> On 30-11-15 17:32, Thomas Petazzoni wrote:
> > Dear Sergio Prado,
> >
> > On Mon, 30 Nov 2015 13:07:36 -0200, Sergio Prado wrote:
> >
> >> I have created a package called sys-queue that will only install
> queue.h on
> >> the staging dir.
> >>
> >> Then to make musl generated toolchain depends on sys-queue, I added the
> >> following lines to toolchain/toolchain-buildroot/toolchain-buildroot.mk
> :
> >>
> >> ifeq ($(BR2_TOOLCHAIN_BUILDROOT_MUSL),y)
> >> TOOLCHAIN_BUILDROOT_DEPENDENCIES += sys-queue
> >> endif
> >>
> >> It worked like a charm. Is this the correct approach?
> >
> > No, because this will only work for internal toolchains. So instead,
> > you need to put this dependency in two places:
>
>  That's what Sergio was doing...
>

Yes, that's what I was doing. I will move the change to the musl package.


>
> >
> >  1/ In package/musl/musl.mk, where it should be an unconditional
> >     dependency.
> >
> >  2/ In toolchain/toolchain-external/toolchain-external.mk, where it
> >     should be conditional on BR2_TOOLCHAIN_USES_MUSL.
> >
> >> Also, I am struggling to find out a way to do the same thing on the
> >> external toolchain. Using the DEPENDENCIES approach, it will process the
> >> sys-queue package before the external toolchain package, and it is best
> to
> >> do it after. Any ideas?
> >
> > Is it really a problem if it is processed before?
>
>  It's actually good if it is processed before, so if there is a queue.h in
> the
> external toolchain after all (e.g. for a buildroot-built external
> toolchain), it
> will overwrite ours. At least, I think that that is what we want.
>

OK. I thought that maybe the staging directory would be cleared out when
processing the external toolchain, but seems that's not the case.

Thanks!


>  Regards,
>  Arnout
>
> >
> > Thomas
> >
>
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20151130/3cfa9910/attachment.html>