[Buildroot] Open bug overview: help wanted!

[Buildroot] Open bug overview: help wanted!

[Thomas De Schampheleire]

Hello,

Here is a brief overview of the currently open bugs. Ideally we can
close many of them in the context of buildroot-2014.08.
Contributions in this area are more than welcome!

https://bugs.busybox.net/show_bug.cgi?id=7208 critical
unassigned at buildroot.uclibc.org Glibc C++ aplications crash if they
use exceptions.
This problem is caused by a patch adding musl support. How to proceed?

https://bugs.busybox.net/show_bug.cgi?id=7010 enhancement
unassigned at buildroot.uclibc.org jamvm builds and runs fine under mips
(be)
This problem will be solved once jamvm 1.6.0 is released. The
maintainer of Jamvm has promised this already for some time, but so
far the release hasn't been made yet.

https://bugs.busybox.net/show_bug.cgi?id=7154 major
patrickdepinguin at gmail.com Local uClibc config file gets overwritten
using make uclibc-update-config
I'm working on this.

https://bugs.busybox.net/show_bug.cgi?id=7124 major
thomas.petazzoni at free-electrons.com Use BR toolchain externally
results a non-bootable root filesystem
ThomasP: you assigned this bug to yourself, have you been able to
reproduce/analyze this already?

https://bugs.busybox.net/show_bug.cgi?id=7172 major
unassigned at buildroot.uclibc.org Name collision of rpath token
expansion and internal variables
The puzzle pieces for a solution are present in this bug report. All
it needs is someone caring enough to create a proper patch for this.
Any candidates?

https://bugs.busybox.net/show_bug.cgi?id=7250 minor
thomas.petazzoni at free-electrons.com Cannot build with -std=c++11
ThomasP attached a patch to the bug report, and the submitter
confirmed it to work. So I guess this patch can be submitted to the
list now?

https://bugs.busybox.net/show_bug.cgi?id=6944 minor
unassigned at buildroot.uclibc.org building toolchain for sh4 fails
ThomasP: you discussed this patch with the submitter, but there is no
final conclusion yet. How to proceed?

https://bugs.busybox.net/show_bug.cgi?id=6950 normal
gustavo at zacarias.com.ar Full unicode support in ncurses
Gustavo is working on this.

https://bugs.busybox.net/show_bug.cgi?id=4790 normal jacmet at uclibc.org
Running udhcpc on a system with NFS root kills NFS
We discussed this patch in the context of the last release cycle. I
believe the end conclusion is that we shouldn't try to be too smart
with respect to the init scripts/configuration files and instead
document the gotchas in the manual. Any takers?

https://bugs.busybox.net/show_bug.cgi?id=5900 normal
unassigned at buildroot.uclibc.org config flags to the Xenomai build
system ...
This problem should be investigated a little to see if there is
actually a problem or not, and if so where the problem is: in
buildroot or in Xenomai. Any takers?

https://bugs.busybox.net/show_bug.cgi?id=7262 normal
unassigned at buildroot.uclibc.org Generating locale en_US.UTF-8 fails on
64bit fedora linux host
Anyone willing to investigate this?

Then there are a number of bug reports that I currently care less about.
Several of them are related to new packages (no bugs), some of them
are there to indicate that certain packages are disabled on a given
configuration, and some are real problems.
Takers for these bugs?

6230 minor unassigned at buildroot.uclibc.org Cannot compile gcc without
threads (uClibc-based)
7118 enhancement abrodkin at synopsys.com Package "thrift" requires
atomic operations
3427 enhancement s.martin49 at gmail.com New package: nginx
261 enhancement unassigned at buildroot.uclibc.org New package: wxWidgets
325 enhancement unassigned at buildroot.uclibc.org New package: ratpoison
405 enhancement unassigned at buildroot.uclibc.org New package: OpenVZ tools
1309 enhancement unassigned at buildroot.uclibc.org New package: rdiff-backup
3655 enhancement unassigned at buildroot.uclibc.org New package: libav
3991 enhancement unassigned at buildroot.uclibc.org New Package:
open-vm-tools (Vmware Tools)
6878 minor abrodkin at synopsys.com dmraid: disabled on ARC
7088 minor sonic.zhang at analog.com elfutils on Blackfin doesn't build
6872 minor unassigned at buildroot.uclibc.org gpsd: disabled on microblaze
7136 normal thomas.petazzoni at free-electrons.com ecryptfs-utils needs
gettext to run when glibc/eglibc is used
7142 normal thomas.petazzoni at free-electrons.com ecryptfs needs getent to run


Best regards,
Thomas

[Buildroot] Open bug overview: help wanted!

[Gustavo Zacarias]

On 07/12/2014 03:50 PM, Thomas De Schampheleire wrote:

> https://bugs.busybox.net/show_bug.cgi?id=6950 normal
> gustavo at zacarias.com.ar Full unicode support in ncurses
> Gustavo is working on this.

Feedback given on the patch, no response so far.
It just needs a slight fix for static builds like i mentioned, worst
case scenario i can add a patch for that besides the two i've sent
fixing nano and statserial.

> https://bugs.busybox.net/show_bug.cgi?id=4790 normal jacmet at uclibc.org
> Running udhcpc on a system with NFS root kills NFS
> We discussed this patch in the context of the last release cycle. I
> believe the end conclusion is that we shouldn't try to be too smart
> with respect to the init scripts/configuration files and instead
> document the gotchas in the manual. Any takers?

> 6230 minor unassigned at buildroot.uclibc.org Cannot compile gcc without
> threads (uClibc-based)

This one is basically closed via
befab216a29927f598e0a3ba0b012f7e822bb235 (WONTFIX) for ARM7.

> 7118 enhancement abrodkin at synopsys.com Package "thrift" requires
> atomic operations

Already solved.
Regards.

[Buildroot] Open bug overview: help wanted!

[Yann E. MORIN]

Thomas, All,

On 2014-07-12 20:50 +0200, Thomas De Schampheleire spake thusly:
> Here is a brief overview of the currently open bugs. Ideally we can
> close many of them in the context of buildroot-2014.08.
> Contributions in this area are more than welcome!

Thanks for this summary! :-)

> https://bugs.busybox.net/show_bug.cgi?id=7208 critical
> unassigned at buildroot.uclibc.org Glibc C++ aplications crash if they
> use exceptions.
> This problem is caused by a patch adding musl support. How to proceed?

Well, those patches are huge, and they touch very critical pieces of
gcc. I would mark musl support broken and remove the patches, until the
patches are fixed.

Unfortunately, that's already been part of a release, so we can't
silently hide it... :-(

> https://bugs.busybox.net/show_bug.cgi?id=7010 enhancement
> unassigned at buildroot.uclibc.org jamvm builds and runs fine under mips
> (be)
> This problem will be solved once jamvm 1.6.0 is released. The
> maintainer of Jamvm has promised this already for some time, but so
> far the release hasn't been made yet.

No release, no mipseb support. The submitter should press the jamvm
maintainer to do a release.

> https://bugs.busybox.net/show_bug.cgi?id=7172 major
> unassigned at buildroot.uclibc.org Name collision of rpath token
> expansion and internal variables
> The puzzle pieces for a solution are present in this bug report. All
> it needs is someone caring enough to create a proper patch for this.
> Any candidates?

I'm not a fan of all this rpath trickery.

Basically, the submitter (probably) wants this to run his
buildroot-built system from somewhere else than / and does not want to
chroot into it.

Should we add complexity to Buildroot for this use-case?

> https://bugs.busybox.net/show_bug.cgi?id=5900 normal
> unassigned at buildroot.uclibc.org config flags to the Xenomai build
> system ...
> This problem should be investigated a little to see if there is
> actually a problem or not, and if so where the problem is: in
> buildroot or in Xenomai. Any takers?

This one is indeed a bit tricky. I looked at what the Xenomai guys said:

---8<---
Xenomai does not do anything special, it uses the autotools default
which is:
- if you pass CFLAGS and LDFLAGS on the right hand of the configure
command line, the generated makefiles are hardcoded with these flags
values, and you need not do anything special later on to get these flags
used for all the compilations. This has been the recommended way of
passing CFLAGS and LDFLAGS when building autotools-based projects for
many years.

- if you want to pass them as environment variables (so, on the left
hand of the configure command line), the makefiles are not generated
with these flags, so, you have to pass them in the environment of the
"make" command.
---8<---

Which indeed makes sense. And we do pass them as environment variables
in package/pkg-autotools:

    [...]
    $$(TARGET_CONFIGURE_OPTS) \
    $$(TARGET_CONFIGURE_ARGS) \
    $$($$(PKG)_CONF_ENV) \
    ./configure \
    [...]

So we should probably pass them after ./configure, i.e. on the right-hand
side of ./configure.

> https://bugs.busybox.net/show_bug.cgi?id=7262 normal
> unassigned at buildroot.uclibc.org Generating locale en_US.UTF-8 fails on
> 64bit fedora linux host
> Anyone willing to investigate this?

I can have a look...

> 6230 minor unassigned at buildroot.uclibc.org Cannot compile gcc without
> threads (uClibc-based)

ARM noMMU is basically broken, as Gustavo said in a comment.

> 7118 enhancement abrodkin at synopsys.com Package "thrift" requires
> atomic operations

Should be closed, the patch has been applied:
    http://git.buildroot.org/buildroot/commit/package/thrift?id=1aaa14d84f1c920423ed0286b78f64a2b4b2b575

> 3427 enhancement s.martin49 at gmail.com New package: nginx
> 261 enhancement unassigned at buildroot.uclibc.org New package: wxWidgets
> 325 enhancement unassigned at buildroot.uclibc.org New package: ratpoison
> 405 enhancement unassigned at buildroot.uclibc.org New package: OpenVZ tools
> 1309 enhancement unassigned at buildroot.uclibc.org New package: rdiff-backup
> 3655 enhancement unassigned at buildroot.uclibc.org New package: libav
> 3991 enhancement unassigned at buildroot.uclibc.org New Package:
> open-vm-tools (Vmware Tools)

New packages should be posted to the list.

> 7088 minor sonic.zhang at analog.com elfutils on Blackfin doesn't build

> 6878 minor abrodkin at synopsys.com dmraid: disabled on ARC
> 6872 minor unassigned at buildroot.uclibc.org gpsd: disabled on microblaze

For those two, the packages are disabled because of an ICE. WE can't do
much more than disabling the packages. Which is already done. Close
those bugs?

> 7136 normal thomas.petazzoni at free-electrons.com ecryptfs-utils needs
> gettext to run when glibc/eglibc is used

Patches on the list.

> 7142 normal thomas.petazzoni at free-electrons.com ecryptfs needs getent to run

I can have a look.

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] Open bug overview: help wanted!

[Mike Zick]

On Sat, 12 Jul 2014 23:53:53 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> > https://bugs.busybox.net/show_bug.cgi?id=7172 major
> > unassigned at buildroot.uclibc.org Name collision of rpath token
> > expansion and internal variables
> > The puzzle pieces for a solution are present in this bug report. All
> > it needs is someone caring enough to create a proper patch for this.
> > Any candidates?  
> 
> I'm not a fan of all this rpath trickery.
> 
> Basically, the submitter (probably) wants this to run his
> buildroot-built system from somewhere else than / and does not want to
> chroot into it.
> 
> Should we add complexity to Buildroot for this use-case?
>

Some members here in the past have expressed interest in supporting
after-market firmware creation for consumer devices.

Most have remained non-committal.

Buildroot does provide the string field for the end-user to pass
custom link-time options.

The point is, it should either work or be documented as to its
limitations.
That meets any definition of a "bug" in Buildroot.
Not a "unsupported use case", a "bug", as in "broke" by implementation".

I would be glad to fix it for you if I could.

Mike

[Buildroot] Open bug overview: help wanted!

[Yann E. MORIN]

Mike, All,

On 2014-07-12 20:54 -0500, Mike Zick spake thusly:
> On Sat, 12 Jul 2014 23:53:53 +0200
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> 
> > > https://bugs.busybox.net/show_bug.cgi?id=7172 major
> > > unassigned at buildroot.uclibc.org Name collision of rpath token
> > > expansion and internal variables
> > > The puzzle pieces for a solution are present in this bug report. All
> > > it needs is someone caring enough to create a proper patch for this.
> > > Any candidates?  
> > 
> > I'm not a fan of all this rpath trickery.
> > 
> > Basically, the submitter (probably) wants this to run his
> > buildroot-built system from somewhere else than / and does not want to
> > chroot into it.
> > 
> > Should we add complexity to Buildroot for this use-case?
> >
> 
> Some members here in the past have expressed interest in supporting
> after-market firmware creation for consumer devices.

And I am completely OK with that. What I'm arguing about is whether we
want to support running a Buildroot system out-side of / , ie. when the
root of the generated filesystem is not the root at runtime.

What I'm saying is that, if one wants to run the Buildroot generated
system as a complement to an existing system, that should be done by
chrooting into the Buildroot system, so that / is seen as / .

> Buildroot does provide the string field for the end-user to pass
> custom link-time options.
> 
> The point is, it should either work or be documented as to its
> limitations.

OK, I agree.

> That meets any definition of a "bug" in Buildroot.
> Not a "unsupported use case", a "bug", as in "broke" by implementation".

Well, this is a bit borderline, IMHO. ;-)

But OK, either we make it work (without adding too much complexity), or
we document it as a limitation.

> I would be glad to fix it for you if I could.

Oh, but you already provided quite a good analysis of the problem, and
even hinted to a possible solution. That's already good! :-)

Of course, the above is just my own feelings on the issue. I'd like to
get ThomasP's feelings on the issue, and your proposed solution.

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] Open bug overview: help wanted!

[Mike Zick]

On Sun, 13 Jul 2014 11:05:35 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> Mike, All,
> 
> On 2014-07-12 20:54 -0500, Mike Zick spake thusly:
> > On Sat, 12 Jul 2014 23:53:53 +0200
> > "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> > 
> > > > https://bugs.busybox.net/show_bug.cgi?id=7172 major
> > > > unassigned at buildroot.uclibc.org Name collision of rpath token
> > > > expansion and internal variables
> > > > The puzzle pieces for a solution are present in this bug
> > > > report. All it needs is someone caring enough to create a
> > > > proper patch for this. Any candidates?  
> > > 
> > > I'm not a fan of all this rpath trickery.
> > > 
> > > Basically, the submitter (probably) wants this to run his
> > > buildroot-built system from somewhere else than / and does not
> > > want to chroot into it.
> > > 
> > > Should we add complexity to Buildroot for this use-case?
> > >
> > 
> > Some members here in the past have expressed interest in supporting
> > after-market firmware creation for consumer devices.
> 
> And I am completely OK with that. What I'm arguing about is whether we
> want to support running a Buildroot system out-side of / , ie. when
> the root of the generated filesystem is not the root at runtime.
> 
> What I'm saying is that, if one wants to run the Buildroot generated
> system as a complement to an existing system, that should be done by
> chrooting into the Buildroot system, so that / is seen as / .
>

Well, in this application of after-market support (the Amazon Kindle)
that is how we run Debian on the grayscale e-books.
In fact, have been doing that for about 4 years now. ;)
http://www.mobileread.com/forums/showthread.php?t=96048

But a chroot (by design) does place significant limits on what parts
of the existing system outside of the chroot can be used/accessed.
 
> > Buildroot does provide the string field for the end-user to pass
> > custom link-time options.
> > 
> > The point is, it should either work or be documented as to its
> > limitations.
> 
> OK, I agree.
>

Of the, what? three?, ld.so tokens, only one of them has a conflict
with the buildsystem (token string: $ORIGIN and the BR output variable
$O)

Something that I imagine is rarely used at a system level.
It is more of a custom application building thing than a system build.

And, in fact, I found that I don't need to use it.
Going down that usage path lead to too many complications.  ;)

> > That meets any definition of a "bug" in Buildroot.
> > Not a "unsupported use case", a "bug", as in "broke" by
> > implementation".
> 
> Well, this is a bit borderline, IMHO. ;-)
> 
> But OK, either we make it work (without adding too much complexity),
> or we document it as a limitation.
> 

I don't think it is a major limitation to the Buildroot user community.

A mention in the options help text, a mention in the manual and an
addition to the known bugs list should be enough until someone really 
needs it fixed.

Which may be never.  ;)

> > I would be glad to fix it for you if I could.
> 
> Oh, but you already provided quite a good analysis of the problem, and
> even hinted to a possible solution. That's already good! :-)
> 
> Of course, the above is just my own feelings on the issue. I'd like to
> get ThomasP's feelings on the issue, and your proposed solution.
>

I would be all right with just mentioning that the ld.so token "$ORIGIN"
can not be included in the custom link options field.

- - - - topic change - - - -

The existing packages that do not recognize that field can be a separate
(individual package) issue.

I have no idea how many packages that might be, it isn't a field that
gets tested by the autobuilders.

I don't think the autobuilder script handles "expected fail" defconfigs.
And an "expected pass" system can't distinguish between an option
correctly passed and used
vs
an option that never gets passed (and does not cause the build to fail).

For an example of packages needing help (in the lua-infrastructure):
The Lua-5.1 package ignores it, the LuaJit-2.0.3 package recognizes
and uses the custom link options field.

Mike

> Regards,
> Yann E. MORIN.
> 

[Buildroot] Open bug overview: help wanted!

[Yann E. MORIN]

Mike, All,

On 2014-07-13 08:29 -0500, Mike Zick spake thusly:
> On Sun, 13 Jul 2014 11:05:35 +0200
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> > On 2014-07-12 20:54 -0500, Mike Zick spake thusly:
> > > Some members here in the past have expressed interest in supporting
> > > after-market firmware creation for consumer devices.
> > 
> > And I am completely OK with that. What I'm arguing about is whether we
> > want to support running a Buildroot system out-side of / , ie. when
> > the root of the generated filesystem is not the root at runtime.
> > 
> > What I'm saying is that, if one wants to run the Buildroot generated
> > system as a complement to an existing system, that should be done by
> > chrooting into the Buildroot system, so that / is seen as / .
> >
> 
> Well, in this application of after-market support (the Amazon Kindle)
> that is how we run Debian on the grayscale e-books.
> In fact, have been doing that for about 4 years now. ;)
> http://www.mobileread.com/forums/showthread.php?t=96048

Everything I could see in that post actually uses a chroot, and is not
running the Debian stuff from outside the chroot.

> But a chroot (by design) does place significant limits on what parts
> of the existing system outside of the chroot can be used/accessed.

Well, the post you pointed to has explicit explanations on how to do
that for the kindle. It points to:
    http://wiki.mobileread.com/wiki/Debi...n_Kindle_Touch

which contains:
    In case you want to have access to userstore from debian execute
    before chrooting:
    mount -o bind /mnt/us /mnt/debian/mnt/us

[--SNIP--]
> And, in fact, I found that I don't need to use it.
> Going down that usage path lead to too many complications.  ;)

Yes, I can imagine that. Programs that expects things (e.g.) in /etc
will be very unpleased when that stuff is in fact in /somewhere-else/etc.

So, what about the bug report? Should we close it?

[--SNIP--]
> > But OK, either we make it work (without adding too much complexity),
> > or we document it as a limitation.
> 
> I don't think it is a major limitation to the Buildroot user community.

I tried to add the script approach, but I bailed out after I banged my
head for two hours.

> A mention in the options help text, a mention in the manual and an
> addition to the known bugs list should be enough until someone really 
> needs it fixed.

Yep, that's the way I've gone with. If the maintainers don;t agree, then
someone will need to do the job. I tried, I failed. :-(

> I would be all right with just mentioning that the ld.so token "$ORIGIN"
> can not be included in the custom link options field.

I have been a bit more conservative in my change, in that I document
that as soon as there is a $ sign, expansion of the variable is
unpredictable, so it is not supported.

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] Open bug overview: help wanted!

[Károly Kasza]

Hello,


> Then there are a number of bug reports that I currently care less about.
> Several of them are related to new packages (no bugs), some of them
> are there to indicate that certain packages are disabled on a given
> configuration, and some are real problems.
> Takers for these bugs?
>
> 3427 enhancement s.martin49 at gmail.com New package: nginx
>

nginx is not using a "normal" autoconfigure/automake system, so
cross-compiling it is nearly impossible. I've some experimental patch,
which still needs a lot of work. I'm not sure if it can be integrated
without completely rewriting the nginx build infrastructure.


> 3991 enhancement unassigned at buildroot.uclibc.org New Package:
> open-vm-tools (Vmware Tools)
>

I've sent 2 patches to make this work,
http://patchwork.ozlabs.org/patch/338483/ is the second one based on the
comments of Thomas.
It's broken now, because of the procps -> procps-ng change, and also a new
version of openvmtools is out since. I'll send a new updated patch in the
near future. Any feedback is appreciated.

BR
Karoly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140715/6b6799fc/attachment.html>

[Buildroot] Open bug overview: help wanted!

[Thomas Petazzoni]

Dear K?roly Kasza,

On Tue, 15 Jul 2014 21:27:51 +0200, K?roly Kasza wrote:

> > 3427 enhancement s.martin49 at gmail.com New package: nginx
> 
> nginx is not using a "normal" autoconfigure/automake system, so
> cross-compiling it is nearly impossible. I've some experimental patch,
> which still needs a lot of work. I'm not sure if it can be integrated
> without completely rewriting the nginx build infrastructure.

Looking at the Yocto/OpenEmbedded recipe might be useful:
http://cgit.openembedded.org/meta-openembedded/commit/?id=c6e1be52b71c9c234de6aebd036a0e7898a89338.

> > 3991 enhancement unassigned at buildroot.uclibc.org New Package:
> > open-vm-tools (Vmware Tools)
> >
> 
> I've sent 2 patches to make this work,
> http://patchwork.ozlabs.org/patch/338483/ is the second one based on the
> comments of Thomas.
> It's broken now, because of the procps -> procps-ng change, and also a new
> version of openvmtools is out since. I'll send a new updated patch in the
> near future. Any feedback is appreciated.

Make sure to also include <pkg>_LICENSE and <pkg>_LICENSE_FILES when
you send a new version of the open-vm-tools package.

Thanks!

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

[Buildroot] Open bug overview: help wanted!

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Sat, 12 Jul 2014 20:50:42 +0200, Thomas De Schampheleire wrote:

> https://bugs.busybox.net/show_bug.cgi?id=7208 critical
> unassigned at buildroot.uclibc.org Glibc C++ aplications crash if they
> use exceptions.
> This problem is caused by a patch adding musl support. How to proceed?

A solution was suggested by Rich Felker in the bug report. My plan is
to work on implementing this solution, but I was hoping to fix bug
#7250 first, which also affects the toolchain.

> https://bugs.busybox.net/show_bug.cgi?id=7124 major
> thomas.petazzoni at free-electrons.com Use BR toolchain externally
> results a non-bootable root filesystem
> ThomasP: you assigned this bug to yourself, have you been able to
> reproduce/analyze this already?

Not yet.

> https://bugs.busybox.net/show_bug.cgi?id=7250 minor
> thomas.petazzoni at free-electrons.com Cannot build with -std=c++11
> ThomasP attached a patch to the bug report, and the submitter
> confirmed it to work. So I guess this patch can be submitted to the
> list now?

The patch I submitted was only for gcc 4.8.x, but I've since then
written patches for gcc 4.7, 4.8 and 4.9, I only lack the same patch
for the ARC special version. I'll work on this, but probably not this
week, since I'm taking care of merging patches this week.

> https://bugs.busybox.net/show_bug.cgi?id=6944 minor
> unassigned at buildroot.uclibc.org building toolchain for sh4 fails
> ThomasP: you discussed this patch with the submitter, but there is no
> final conclusion yet. How to proceed?

I don't know. I don't know SuperH stuff, and it builds a multilib
toolchain by default, causing some issues. Needs investigation/thoughts
to see what could be the solution. Problem is that I don't personally
care much about SuperH, and we don't have a lot of contributors/users
using this architecture, so it reduces quite a bit the incentive to
work on such issues.

> https://bugs.busybox.net/show_bug.cgi?id=4790 normal jacmet at uclibc.org
> Running udhcpc on a system with NFS root kills NFS
> We discussed this patch in the context of the last release cycle. I
> believe the end conclusion is that we shouldn't try to be too smart
> with respect to the init scripts/configuration files and instead
> document the gotchas in the manual. Any takers?

I agree with the solution.

> 6878 minor abrodkin at synopsys.com dmraid: disabled on ARC
> 7088 minor sonic.zhang at analog.com elfutils on Blackfin doesn't build
> 6872 minor unassigned at buildroot.uclibc.org gpsd: disabled on microblaze

These ones are mainly here to remind the respective architecture
maintainers that they should do something about these packages: we have
temporarily solve the situation by excluding those packages using
"depends on !<problematic architecture>", but ultimately there's no
technical reason for those packages to be disabled on those
architectures. So to not forget, I submitted those bug reports instead.
Here the intent is to distinguish packages that for some technical
reason do not support a given architecture (such as webkit, or jamvm,
that really do have some architecture-specific code) from packages
currently broken on a given architecture, but which could potentially
work.

That being said, while I'm pretty sure the dmraid issue on ARC will be
solved at some point, I have less hopes for the elfutils on Blackfin
and gpsd on Microblaze issues, since we don't receive much help to
maintain those two architectures in Buildroot...

> 7136 normal thomas.petazzoni at free-electrons.com ecryptfs-utils needs
> gettext to run when glibc/eglibc is used

Patches already sent. People were a little bit worried about the
consequences of the patches, but I don't think there's any other
solution, so I'd appreciate some review on the patches.

> 7142 normal thomas.petazzoni at free-electrons.com ecryptfs needs getent to run

Yeah, I remember this issue, it was debugged on IRC, and the bug report
is a reminder to do some work to fix it properly.

Thanks,

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

[Buildroot] Open bug overview: help wanted!

[Johan Oudinet]

Dear K?roly,

On Tue, Jul 15, 2014 at 9:27 PM, K?roly Kasza <kaszak@gmail.com> wrote:
>> 3427 enhancement s.martin49 at gmail.com New package: nginx
>
> nginx is not using a "normal" autoconfigure/automake system, so
> cross-compiling it is nearly impossible. I've some experimental patch, which
> still needs a lot of work. I'm not sure if it can be integrated without
> completely rewriting the nginx build infrastructure.

I do use a working nginx patch for my buildroot. It comes from tSed
github, which claims to fix #3427:
https://github.com/tSed/buildroot/commit/9d319a3333b76532e68fb94238feb3cbc2e55d5f

I think he's planning to submit it to this mailing list soon.

Best,

-- 
Johan

[Buildroot] Open bug overview: help wanted!

[Thomas De Schampheleire]

Hi Gustavo,

On Sat, Jul 12, 2014 at 10:12 PM, Gustavo Zacarias
<gustavo@zacarias.com.ar> wrote:
> On 07/12/2014 03:50 PM, Thomas De Schampheleire wrote:
>
>> https://bugs.busybox.net/show_bug.cgi?id=6950 normal
>> gustavo at zacarias.com.ar Full unicode support in ncurses
>> Gustavo is working on this.
>
> Feedback given on the patch, no response so far.
> It just needs a slight fix for static builds like i mentioned, worst
> case scenario i can add a patch for that besides the two i've sent
> fixing nano and statserial.

Thanks a lot for working on this.
If Jeremy or you could respin the main patch, that'd be great. But I
assume it can only be applied once all the package fixes are in?
Are nano and statserial the only ones needing fixing?

>
>> 6230 minor unassigned at buildroot.uclibc.org Cannot compile gcc without
>> threads (uClibc-based)
>
> This one is basically closed via
> befab216a29927f598e0a3ba0b012f7e822bb235 (WONTFIX) for ARM7.
>
>> 7118 enhancement abrodkin at synopsys.com Package "thrift" requires
>> atomic operations
>
> Already solved.

Thanks, both marked as such.

Best regards,
Thomas

[Buildroot] Open bug overview: help wanted!

[Gustavo Zacarias]

On 07/16/2014 02:08 PM, Thomas De Schampheleire wrote:

> Thanks a lot for working on this.
> If Jeremy or you could respin the main patch, that'd be great. But I
> assume it can only be applied once all the package fixes are in?
> Are nano and statserial the only ones needing fixing?

statserial is a generic fix so it was applied yesterday by Thomas P.
nano depends on the ncursesw config knob - it can be applied but
technically it's a no-op until ncursesw is in so should be part of the
series or at least applied immediately after ncursesw.
allyespackageconfig was my test run and yes, there shouldn't be any
unpleasant surprises with the patches applied, just maybe a couple of
sneaked new/bumped packages since my test tree run and now but unlikely
given that only 2 packages "complained".
Of course i couldn't finish a similar run on static because that would
require to fix all static build failures :)
Regarding the respin we can wait for Jeremy, modify his patch or just do
an extra patch with the static fix - we still need the nano fix anyway.
I'd go with the 3rd option since it's pretty straightforward.
Regards.

[Buildroot] Open bug overview: help wanted!

[Thomas De Schampheleire]

Hi Yann,

On Sat, Jul 12, 2014 at 11:53 PM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Thomas, All,
>
> On 2014-07-12 20:50 +0200, Thomas De Schampheleire spake thusly:
>> Here is a brief overview of the currently open bugs. Ideally we can
>> close many of them in the context of buildroot-2014.08.
>> Contributions in this area are more than welcome!
>
> Thanks for this summary! :-)

And thanks to all who provided feedback!

>
>> https://bugs.busybox.net/show_bug.cgi?id=7010 enhancement
>> unassigned at buildroot.uclibc.org jamvm builds and runs fine under mips
>> (be)
>> This problem will be solved once jamvm 1.6.0 is released. The
>> maintainer of Jamvm has promised this already for some time, but so
>> far the release hasn't been made yet.
>
> No release, no mipseb support. The submitter should press the jamvm
> maintainer to do a release.
>

I have been doing this a few times, and the release was to happen Real
Soon Now... :)
Looking at the commit log, it seems he is now fixing warnings and
such, I'll wait a while and then bug him again.

>> https://bugs.busybox.net/show_bug.cgi?id=7172 major
>> unassigned at buildroot.uclibc.org Name collision of rpath token
>> expansion and internal variables
>> The puzzle pieces for a solution are present in this bug report. All
>> it needs is someone caring enough to create a proper patch for this.
>> Any candidates?
>
> I'm not a fan of all this rpath trickery.
>
> Basically, the submitter (probably) wants this to run his
> buildroot-built system from somewhere else than / and does not want to
> chroot into it.
>
> Should we add complexity to Buildroot for this use-case?

I agree with the patches you sent to the list: one documentation patch
and a patch adding patchelf.

>
>> https://bugs.busybox.net/show_bug.cgi?id=5900 normal
>> unassigned at buildroot.uclibc.org config flags to the Xenomai build
>> system ...
>> This problem should be investigated a little to see if there is
>> actually a problem or not, and if so where the problem is: in
>> buildroot or in Xenomai. Any takers?
>
> This one is indeed a bit tricky. I looked at what the Xenomai guys said:
>
> ---8<---
> Xenomai does not do anything special, it uses the autotools default
> which is:
> - if you pass CFLAGS and LDFLAGS on the right hand of the configure
> command line, the generated makefiles are hardcoded with these flags
> values, and you need not do anything special later on to get these flags
> used for all the compilations. This has been the recommended way of
> passing CFLAGS and LDFLAGS when building autotools-based projects for
> many years.
>
> - if you want to pass them as environment variables (so, on the left
> hand of the configure command line), the makefiles are not generated
> with these flags, so, you have to pass them in the environment of the
> "make" command.
> ---8<---
>
> Which indeed makes sense. And we do pass them as environment variables
> in package/pkg-autotools:
>
>     [...]
>     $$(TARGET_CONFIGURE_OPTS) \
>     $$(TARGET_CONFIGURE_ARGS) \
>     $$($$(PKG)_CONF_ENV) \
>     ./configure \
>     [...]
>
> So we should probably pass them after ./configure, i.e. on the right-hand
> side of ./configure.

I think we should reproduce the issue here. The xenomai guys are right
in the sense that we have to pass the same flags to the make command,
but we are normally doing that... If not then the xenomai.mk build
rules may need updating.

>
>> https://bugs.busybox.net/show_bug.cgi?id=7262 normal
>> unassigned at buildroot.uclibc.org Generating locale en_US.UTF-8 fails on
>> 64bit fedora linux host
>> Anyone willing to investigate this?
>
> I can have a look...

Thanks!

>
>> 6230 minor unassigned at buildroot.uclibc.org Cannot compile gcc without
>> threads (uClibc-based)
>
> ARM noMMU is basically broken, as Gustavo said in a comment.

Done.

>
>> 7118 enhancement abrodkin at synopsys.com Package "thrift" requires
>> atomic operations
>
> Should be closed, the patch has been applied:
>     http://git.buildroot.org/buildroot/commit/package/thrift?id=1aaa14d84f1c920423ed0286b78f64a2b4b2b575

Done.

>
>> 3427 enhancement s.martin49 at gmail.com New package: nginx
>> 261 enhancement unassigned at buildroot.uclibc.org New package: wxWidgets
>> 325 enhancement unassigned at buildroot.uclibc.org New package: ratpoison
>> 405 enhancement unassigned at buildroot.uclibc.org New package: OpenVZ tools
>> 1309 enhancement unassigned at buildroot.uclibc.org New package: rdiff-backup
>> 3655 enhancement unassigned at buildroot.uclibc.org New package: libav
>> 3991 enhancement unassigned at buildroot.uclibc.org New Package:
>> open-vm-tools (Vmware Tools)
>
> New packages should be posted to the list.

Yes that is true, but do you suggest to simply close the bugs and
reject the patches?
A nicer solution would be that someone / several people adopt these
patches and resubmit them.

>
>> 7136 normal thomas.petazzoni at free-electrons.com ecryptfs-utils needs
>> gettext to run when glibc/eglibc is used
>
> Patches on the list.
>
>> 7142 normal thomas.petazzoni at free-electrons.com ecryptfs needs getent to run
>
> I can have a look.
>

Thanks!

Best regards,
Thomas

[Buildroot] Open bug overview: help wanted!

[Thomas De Schampheleire]

Hi,


On Wed, Jul 16, 2014 at 7:18 PM, Gustavo Zacarias
<gustavo@zacarias.com.ar> wrote:
> On 07/16/2014 02:08 PM, Thomas De Schampheleire wrote:
>
>> Thanks a lot for working on this.
>> If Jeremy or you could respin the main patch, that'd be great. But I
>> assume it can only be applied once all the package fixes are in?
>> Are nano and statserial the only ones needing fixing?
>
> statserial is a generic fix so it was applied yesterday by Thomas P.
> nano depends on the ncursesw config knob - it can be applied but
> technically it's a no-op until ncursesw is in so should be part of the
> series or at least applied immediately after ncursesw.
> allyespackageconfig was my test run and yes, there shouldn't be any
> unpleasant surprises with the patches applied, just maybe a couple of
> sneaked new/bumped packages since my test tree run and now but unlikely
> given that only 2 packages "complained".
> Of course i couldn't finish a similar run on static because that would
> require to fix all static build failures :)
> Regarding the respin we can wait for Jeremy, modify his patch or just do
> an extra patch with the static fix - we still need the nano fix anyway.
> I'd go with the 3rd option since it's pretty straightforward.
> Regards.

I understood from IRC that you will send a patch series including all
necessary changes, thanks!

[Buildroot] Open bug overview: help wanted!

[Thomas De Schampheleire]

Hi Thomas,

On Wed, Jul 16, 2014 at 9:31 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Sat, 12 Jul 2014 20:50:42 +0200, Thomas De Schampheleire wrote:
>
>> https://bugs.busybox.net/show_bug.cgi?id=7208 critical
>> unassigned at buildroot.uclibc.org Glibc C++ aplications crash if they
>> use exceptions.
>> This problem is caused by a patch adding musl support. How to proceed?
>
> A solution was suggested by Rich Felker in the bug report. My plan is
> to work on implementing this solution, but I was hoping to fix bug
> #7250 first, which also affects the toolchain.

Ok, thanks.

>
>> https://bugs.busybox.net/show_bug.cgi?id=7124 major
>> thomas.petazzoni at free-electrons.com Use BR toolchain externally
>> results a non-bootable root filesystem
>> ThomasP: you assigned this bug to yourself, have you been able to
>> reproduce/analyze this already?
>
> Not yet.
>
>> https://bugs.busybox.net/show_bug.cgi?id=7250 minor
>> thomas.petazzoni at free-electrons.com Cannot build with -std=c++11
>> ThomasP attached a patch to the bug report, and the submitter
>> confirmed it to work. So I guess this patch can be submitted to the
>> list now?
>
> The patch I submitted was only for gcc 4.8.x, but I've since then
> written patches for gcc 4.7, 4.8 and 4.9, I only lack the same patch
> for the ARC special version. I'll work on this, but probably not this
> week, since I'm taking care of merging patches this week.

Sure, thanks.

>
>> https://bugs.busybox.net/show_bug.cgi?id=6944 minor
>> unassigned at buildroot.uclibc.org building toolchain for sh4 fails
>> ThomasP: you discussed this patch with the submitter, but there is no
>> final conclusion yet. How to proceed?
>
> I don't know. I don't know SuperH stuff, and it builds a multilib
> toolchain by default, causing some issues. Needs investigation/thoughts
> to see what could be the solution. Problem is that I don't personally
> care much about SuperH, and we don't have a lot of contributors/users
> using this architecture, so it reduces quite a bit the incentive to
> work on such issues.

Understood.
Should we consider deprecating this SuperH support or is that too drastic?

>
>> https://bugs.busybox.net/show_bug.cgi?id=4790 normal jacmet at uclibc.org
>> Running udhcpc on a system with NFS root kills NFS
>> We discussed this patch in the context of the last release cycle. I
>> believe the end conclusion is that we shouldn't try to be too smart
>> with respect to the init scripts/configuration files and instead
>> document the gotchas in the manual. Any takers?
>
> I agree with the solution.
>
>> 6878 minor abrodkin at synopsys.com dmraid: disabled on ARC
>> 7088 minor sonic.zhang at analog.com elfutils on Blackfin doesn't build
>> 6872 minor unassigned at buildroot.uclibc.org gpsd: disabled on microblaze
>
> These ones are mainly here to remind the respective architecture
> maintainers that they should do something about these packages: we have
> temporarily solve the situation by excluding those packages using
> "depends on !<problematic architecture>", but ultimately there's no
> technical reason for those packages to be disabled on those
> architectures. So to not forget, I submitted those bug reports instead.
> Here the intent is to distinguish packages that for some technical
> reason do not support a given architecture (such as webkit, or jamvm,
> that really do have some architecture-specific code) from packages
> currently broken on a given architecture, but which could potentially
> work.
>
> That being said, while I'm pretty sure the dmraid issue on ARC will be
> solved at some point, I have less hopes for the elfutils on Blackfin
> and gpsd on Microblaze issues, since we don't receive much help to
> maintain those two architectures in Buildroot...
>
>> 7136 normal thomas.petazzoni at free-electrons.com ecryptfs-utils needs
>> gettext to run when glibc/eglibc is used
>
> Patches already sent. People were a little bit worried about the
> consequences of the patches, but I don't think there's any other
> solution, so I'd appreciate some review on the patches.
>
>> 7142 normal thomas.petazzoni at free-electrons.com ecryptfs needs getent to run
>
> Yeah, I remember this issue, it was debugged on IRC, and the bug report
> is a reminder to do some work to fix it properly.
>

Thanks for your feedback on all these.

Best regards,
Thomas

[Buildroot] Open bug overview: help wanted!

[Károly Kasza]

Hello all,


> > > 3991 enhancement unassigned at buildroot.uclibc.org New Package:
> > > open-vm-tools (Vmware Tools)
>

Sent in as http://patchwork.ozlabs.org/patch/371785/ .
Any comments?

BR
Karoly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140719/03df122e/attachment.html>