[Buildroot] Patchwork cleanup week #24

[Buildroot] Patchwork cleanup week #24

[Thomas Petazzoni]

Hello,

The previous patchwork cleanup period being over, it's time to start
the second period, with 10 other patches. We're on June 15th, so I'll
give people until June 30th to react on the following patches. If
there's no reaction, like no interest from either the original
submitter nor any other Buildroot developer, the patch will be marked
Rejected on June 30th.

If you are in To: of this e-mail, then one or several of the patches
below have been authored by you, so you should be interested :-)

Thanks,

Thomas

 1. board: add support for Chromebook Snow
    http://patchwork.ozlabs.org/patch/563197/

    This one has not been reviewed. It would be sad not to merge it,
    because we have merged some specific packages that are needed for
    this defconfig (host-vboot-utils).

 2. pyqtgraph: new package
    http://patchwork.ozlabs.org/patch/529864/

    It seems to be a pretty straightforward package, but nobody
    reviewed it.

 3. toolchain-wrapper: prevent use of unsupported -fstack-protector*
    http://patchwork.ozlabs.org/patch/545315/

    This patch proposes to make the toolchain wrapper fail immediately
    when -fstack-protector is passed to gcc, but SSP support is not
    available. This helps with some packages that assume that compiling
    with -fstack-protector is enough to determine if SSP support is
    available, while in several cases, doing a link test is necessary.

    I personally don't really like this change, as I believe it's
    adding even more sorcery to our toolchain wrapper. Instead, the
    problematic upstream packages should be fixed. Plus, at the time,
    we had a few packages in this situation, but nowadays, I don't
    think we have build failures due to this.

    So, my proposal would be to reject this patch.

 4. uboot: install multiple spl images
    http://patchwork.ozlabs.org/patch/595980/

 5. Fix for the makeinfo / missing issue, proposal from Romain
    http://patchwork.ozlabs.org/patch/595041/
    http://patchwork.ozlabs.org/patch/595042/
    http://patchwork.ozlabs.org/patch/595043/

    We need to take a decision on this one. The problem also occurs for
    gdb and binutils on ARC, for which we've added a custom hack
    recently.

    I tried to play with timestamps by touch'ing the .info files before
    the build, it worked with one of gdb or binutils, but failed for
    the other.

    So either we take Romain's approach, or we bite the bullet and add
    a host-makeinfo package on which we depend when gdb/binutils are
    fetched from Git.

 6. wget download: 'scheme missing' results in empty output file
    http://patchwork.ozlabs.org/patch/599387/

 7. Fortran support
    http://patchwork.ozlabs.org/patch/599678/
    http://patchwork.ozlabs.org/patch/599679/
    http://patchwork.ozlabs.org/patch/599680/

    Nobody reviewed this.

 8. new package: alsacap
    http://patchwork.ozlabs.org/patch/607045/

    Isn't there already a tool in alsa-utils that does the same thing
    more or less?

 9. overlay: Add archive-based (tar) rootfs overlays
    http://patchwork.ozlabs.org/patch/610752/

10. Improvements to kernel headers version selection
    http://patchwork.ozlabs.org/patch/612316/
    http://patchwork.ozlabs.org/patch/612315/
    http://patchwork.ozlabs.org/patch/612313/

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

[Buildroot] Patchwork cleanup week #24

[Thomas Petazzoni]

Hello,

(Re-adding the Buildroot mailing list in Cc)

On Wed, 15 Jun 2016 13:59:03 -0700, Benjamin Kamath wrote:
> We needed the fortran / lapack patches for a project at work and I suppose
> there isn't too much interest in them in general, so feel free to mark as
> rejected.

Actually, there is some interest. We recently merged a package for
openmpi, in which we could not enable the Fortran support due to your
series not being applied.

> I'm personally much more interested in Samuel Martin's patches related to
> creating relocatable host-tools / toolchains, which I think could allow
> buildroot to much more easily create/distribute SDKs to go along with
> images.

Then, don't hesitate to review, or at least test Samuel's patches. Your
feedback is very valuable to help his series move forward. Samuel's
work is pretty complicated, so it will necessarily take some time to
get merged. But at least, it's good to know there is some interest in
this feature.

Thanks for your feedback!

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

[Buildroot] Patchwork cleanup week #24

[Thomas De Schampheleire]

Hi Thomas,

On Wed, Jun 15, 2016 at 10:06 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> The previous patchwork cleanup period being over, it's time to start
> the second period, with 10 other patches. We're on June 15th, so I'll
> give people until June 30th to react on the following patches. If
> there's no reaction, like no interest from either the original
> submitter nor any other Buildroot developer, the patch will be marked
> Rejected on June 30th.
>
> If you are in To: of this e-mail, then one or several of the patches
> below have been authored by you, so you should be interested :-)

>
[..]
>  6. wget download: 'scheme missing' results in empty output file
>     http://patchwork.ozlabs.org/patch/599387/
>

The mail thread where this patch originated from is at:
http://lists.busybox.net/pipermail/buildroot/2016-February/153953.html

There was no further response on this patch, but as far as I'm
concerned the issue is still present and could use a fix.

What do you think about the proposed solution?

/Thomas

[Buildroot] Patchwork cleanup week #24

[Thomas Petazzoni]

Thomas,

Thanks for giving some feedback!

On Thu, 16 Jun 2016 09:18:37 +0200, Thomas De Schampheleire wrote:

> [..]
> >  6. wget download: 'scheme missing' results in empty output file
> >     http://patchwork.ozlabs.org/patch/599387/
> >  
> 
> The mail thread where this patch originated from is at:
> http://lists.busybox.net/pipermail/buildroot/2016-February/153953.html
> 
> There was no further response on this patch, but as far as I'm
> concerned the issue is still present and could use a fix.
> 
> What do you think about the proposed solution?

I am not sure what is the best solution between:

 - Defining <foo>_SITE to undefined when no value is specified by the
   package (which is your proposal)

 - Do not add to <pkg>_ALL_DOWNLOADS the files for which there is
   no :// in the URL, and <pkg>_SITE is empty. This was the proposal
   made by Yann in
   http://lists.busybox.net/pipermail/buildroot/2016-February/153999.html.

 - Error out when both <pkg>_SITE is empty and <pkg>_SOURCE is
   non-empty.

In any case, the patch in patchwork is not applicable as-is, as it
doesn't contain a proper description + SoB line.

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

[Buildroot] Patchwork cleanup week #24

[Thomas De Schampheleire]

Hi Thomas,

On Thu, Jun 16, 2016 at 9:32 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Thomas,
>
> Thanks for giving some feedback!
>
> On Thu, 16 Jun 2016 09:18:37 +0200, Thomas De Schampheleire wrote:
>
>> [..]
>> >  6. wget download: 'scheme missing' results in empty output file
>> >     http://patchwork.ozlabs.org/patch/599387/
>> >
>>
>> The mail thread where this patch originated from is at:
>> http://lists.busybox.net/pipermail/buildroot/2016-February/153953.html
>>
>> There was no further response on this patch, but as far as I'm
>> concerned the issue is still present and could use a fix.
>>
>> What do you think about the proposed solution?
>
> I am not sure what is the best solution between:
>
>  - Defining <foo>_SITE to undefined when no value is specified by the
>    package (which is your proposal)
>
>  - Do not add to <pkg>_ALL_DOWNLOADS the files for which there is
>    no :// in the URL, and <pkg>_SITE is empty. This was the proposal
>    made by Yann in
>    http://lists.busybox.net/pipermail/buildroot/2016-February/153999.html.

This does not give the intended result. It was in the thread but in
March, so mailman fails to link it (meh...)
http://lists.busybox.net/pipermail/buildroot/2016-March/156416.html

>
>  - Error out when both <pkg>_SITE is empty and <pkg>_SOURCE is
>    non-empty.

I guess this could also work. If you prefer this I can cook up a real patch.
Input from others is welcome too, of course.

Thanks,
Thomas

[Buildroot] Patchwork cleanup week #24

[Thomas Petazzoni]

Hello,

On Thu, 16 Jun 2016 11:52:29 +0200, Thomas De Schampheleire wrote:

> > I am not sure what is the best solution between:
> >
> >  - Defining <foo>_SITE to undefined when no value is specified by the
> >    package (which is your proposal)
> >
> >  - Do not add to <pkg>_ALL_DOWNLOADS the files for which there is
> >    no :// in the URL, and <pkg>_SITE is empty. This was the proposal
> >    made by Yann in
> >    http://lists.busybox.net/pipermail/buildroot/2016-February/153999.html.  
> 
> This does not give the intended result. It was in the thread but in
> March, so mailman fails to link it (meh...)
> http://lists.busybox.net/pipermail/buildroot/2016-March/156416.html

Ah, yes. Stupid mailman.

In any case, for such situations, it is good if a new patch gets sent,
which summarizes the problem, the different approaches, and why the
proposed approach was chosen.

It is really hard to remember all the details of this discussion that
happened months ago.

> >  - Error out when both <pkg>_SITE is empty and <pkg>_SOURCE is
> >    non-empty.  
> 
> I guess this could also work. If you prefer this I can cook up a real patch.
> Input from others is welcome too, of course.

Let's wait a bit for others to speak up.

What I find a bit with with the "undefined" idea, is that people will
get download failure due to http://undefined/foo not being available.
To me, it seems to make more sense to error out when _SITE is empty, we
will provide an even clearer error than a weird download failure on
http://undefined/foo.

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

[Buildroot] Patchwork cleanup week #24

[Yann E. MORIN]

Thomas?, All,

On 2016-06-16 11:56 +0200, Thomas Petazzoni spake thusly:
> On Thu, 16 Jun 2016 11:52:29 +0200, Thomas De Schampheleire wrote:
> > > I am not sure what is the best solution between:
> > >
> > >  - Defining <foo>_SITE to undefined when no value is specified by the
> > >    package (which is your proposal)
> > >
> > >  - Do not add to <pkg>_ALL_DOWNLOADS the files for which there is
> > >    no :// in the URL, and <pkg>_SITE is empty. This was the proposal
> > >    made by Yann in
> > >    http://lists.busybox.net/pipermail/buildroot/2016-February/153999.html.  
> > 
> > This does not give the intended result. It was in the thread but in
> > March, so mailman fails to link it (meh...)
> > http://lists.busybox.net/pipermail/buildroot/2016-March/156416.html
> 
> Ah, yes. Stupid mailman.
> 
> In any case, for such situations, it is good if a new patch gets sent,
> which summarizes the problem, the different approaches, and why the
> proposed approach was chosen.
> 
> It is really hard to remember all the details of this discussion that
> happened months ago.
> 
> > >  - Error out when both <pkg>_SITE is empty and <pkg>_SOURCE is
> > >    non-empty.  
> > 
> > I guess this could also work. If you prefer this I can cook up a real patch.
> > Input from others is welcome too, of course.
> 
> Let's wait a bit for others to speak up.

Well, I prefer Thomas P. proposal: bail out if <pkg>_SITE is empty and
<pkg>_SOURCE is not.

> What I find a bit with with the "undefined" idea, is that people will
> get download failure due to http://undefined/foo not being available.
> To me, it seems to make more sense to error out when _SITE is empty, we
> will provide an even clearer error than a weird download failure on
> http://undefined/foo.

Yes, this is definitely not user-friendly. Maybe:

    http://you-forgot-to-set-<pkg>_SITE/pkg-version-blabla

Just kidding. ;-]

Regards,
Yann E. MORIN.

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

-- 
.-----------------.--------------------.------------------.--------------------.
|  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] Patchwork cleanup week #24

[Yann E. MORIN]

Thomas?, All,

On 2016-06-16 11:52 +0200, Thomas De Schampheleire spake thusly:
> On Thu, Jun 16, 2016 at 9:32 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > Thomas,
> >
> > Thanks for giving some feedback!
> >
> > On Thu, 16 Jun 2016 09:18:37 +0200, Thomas De Schampheleire wrote:
> >
> >> [..]
> >> >  6. wget download: 'scheme missing' results in empty output file
> >> >     http://patchwork.ozlabs.org/patch/599387/
> >> >
> >>
> >> The mail thread where this patch originated from is at:
> >> http://lists.busybox.net/pipermail/buildroot/2016-February/153953.html
> >>
> >> There was no further response on this patch, but as far as I'm
> >> concerned the issue is still present and could use a fix.
> >>
> >> What do you think about the proposed solution?
> >
> > I am not sure what is the best solution between:
> >
> >  - Defining <foo>_SITE to undefined when no value is specified by the
> >    package (which is your proposal)
> >
> >  - Do not add to <pkg>_ALL_DOWNLOADS the files for which there is
> >    no :// in the URL, and <pkg>_SITE is empty. This was the proposal
> >    made by Yann in
> >    http://lists.busybox.net/pipermail/buildroot/2016-February/153999.html.
> 
> This does not give the intended result. It was in the thread but in
> March, so mailman fails to link it (meh...)
> http://lists.busybox.net/pipermail/buildroot/2016-March/156416.html

OK, now I remember this thread.

I just tried:

    $ wget /foo/bar
    /foo/bart: Scheme missing.
    $ echo $?
    1

So, what? My wget does exit in error...

    $ wget --version
    GNU Wget 1.17.1 built on linux-gnu.

What's yours?

Regards,
Yann E. MORIN.

> >
> >  - Error out when both <pkg>_SITE is empty and <pkg>_SOURCE is
> >    non-empty.
> 
> I guess this could also work. If you prefer this I can cook up a real patch.
> Input from others is welcome too, of course.
> 
> Thanks,
> Thomas

-- 
.-----------------.--------------------.------------------.--------------------.
|  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] Patchwork cleanup week #24

[Thomas Petazzoni]

Hello,

On Thu, 16 Jun 2016 19:23:23 +0200, Yann E. MORIN wrote:

> I just tried:
> 
>     $ wget /foo/bar
>     /foo/bart: Scheme missing.
>     $ echo $?
>     1
> 
> So, what? My wget does exit in error...
> 
>     $ wget --version
>     GNU Wget 1.17.1 built on linux-gnu.
> 
> What's yours?

Thomas DS is running with an old RHEL, which has a old version of wget
that does return 0 in this case, which is what prompted the original
patch from Thomas.

Best regards,

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

[Buildroot] Patchwork cleanup week #24

[Romain Naour]

Hi Thomas, Alexey, Vlad, All,

Le 15/06/2016 ? 22:06, Thomas Petazzoni a ?crit :
> Hello,
> 
> The previous patchwork cleanup period being over, it's time to start
> the second period, with 10 other patches. We're on June 15th, so I'll
> give people until June 30th to react on the following patches. If
> there's no reaction, like no interest from either the original
> submitter nor any other Buildroot developer, the patch will be marked
> Rejected on June 30th.
> 
> If you are in To: of this e-mail, then one or several of the patches
> below have been authored by you, so you should be interested :-)
> 
> Thanks,
> 
> Thomas
> 
>  5. Fix for the makeinfo / missing issue, proposal from Romain
>     http://patchwork.ozlabs.org/patch/595041/
>     http://patchwork.ozlabs.org/patch/595042/
>     http://patchwork.ozlabs.org/patch/595043/
> 
>     We need to take a decision on this one. The problem also occurs for
>     gdb and binutils on ARC, for which we've added a custom hack
>     recently.
> 
>     I tried to play with timestamps by touch'ing the .info files before
>     the build, it worked with one of gdb or binutils, but failed for
>     the other.
> 
>     So either we take Romain's approach, or we bite the bullet and add
>     a host-makeinfo package on which we depend when gdb/binutils are
>     fetched from Git.
> 

IHMO the real problem is that binutils/gdb doesn't support --disable-docs
option. When present on the command line, this option must completely disable
the documentation (man, info, pdf etc) and let the build continue.

It seems that this issue was already discussed back in 2007 [1].
Last year I submitted a patch upstream to do that but it was not complete and
not tested due to autoconf version mismatch [2].

If we want to autoreconf binutils/gdb in Buildroot we must downgrade autoconf to
2.64 and automake to 1.12.6.

Alexey, Vlad, I would suggest to rework your patch [3] and add --disable-docs
option instead of testing missing 127 return value.
If you succeed, we can reject my proposal from patchwork :)

Best regards,
Romain

[1] https://sourceware.org/ml/gdb-patches/2007-11/msg00102.html
[2] https://sourceware.org/ml/gdb-patches/2015-09/msg00073.html
[3] http://lists.busybox.net/pipermail/buildroot/2016-June/163037.html

[Buildroot] Patchwork cleanup week #24

[Alexey Brodkin]

Hi Romain,

On Sat, 2016-06-18 at 16:07 +0200, Romain Naour wrote:
> Hi Thomas, Alexey, Vlad, All,
> 
> Le 15/06/2016 ? 22:06, Thomas Petazzoni a ?crit :
> > 
> > Hello,
> > 
> > The previous patchwork cleanup period being over, it's time to start
> > the second period, with 10 other patches. We're on June 15th, so I'll
> > give people until June 30th to react on the following patches. If
> > there's no reaction, like no interest from either the original
> > submitter nor any other Buildroot developer, the patch will be marked
> > Rejected on June 30th.
> > 
> > If you are in To: of this e-mail, then one or several of the patches
> > below have been authored by you, so you should be interested :-)
> > 
> > Thanks,
> > 
> > Thomas
> > 
> > ?5. Fix for the makeinfo / missing issue, proposal from Romain
> > ????http://patchwork.ozlabs.org/patch/595041/
> > ????http://patchwork.ozlabs.org/patch/595042/
> > ????http://patchwork.ozlabs.org/patch/595043/
> > 
> > ????We need to take a decision on this one. The problem also occurs for
> > ????gdb and binutils on ARC, for which we've added a custom hack
> > ????recently.
> > 
> > ????I tried to play with timestamps by touch'ing the .info files before
> > ????the build, it worked with one of gdb or binutils, but failed for
> > ????the other.
> > 
> > ????So either we take Romain's approach, or we bite the bullet and add
> > ????a host-makeinfo package on which we depend when gdb/binutils are
> > ????fetched from Git.
> > 
> IHMO the real problem is that binutils/gdb doesn't support --disable-docs
> option. When present on the command line, this option must completely disable
> the documentation (man, info, pdf etc) and let the build continue.
> 
> It seems that this issue was already discussed back in 2007 [1].
> Last year I submitted a patch upstream to do that but it was not complete and
> not tested due to autoconf version mismatch [2].
> 
> If we want to autoreconf binutils/gdb in Buildroot we must downgrade autoconf to
> 2.64 and automake to 1.12.6.
> 
> Alexey, Vlad, I would suggest to rework your patch [3] and add --disable-docs
> option instead of testing missing 127 return value.
> If you succeed, we can reject my proposal from patchwork :)

Right, that's what we're looking at now.
Stay tuned and patch(es) will follow :)

-Alexey

[Buildroot] Patchwork cleanup week #24

[Vlad Zakharov]

Hello,?

On Wed, 2016-06-22 at 05:45 +0000, Alexey Brodkin wrote:
> Hi Romain,
> 
> On Sat, 2016-06-18 at 16:07 +0200, Romain Naour wrote:
> > 
> > Hi Thomas, Alexey, Vlad, All,
> > 
> > Le 15/06/2016 ? 22:06, Thomas Petazzoni a ?crit :
> > > 
> > > 
> > > Hello,
> > > 
> > > The previous patchwork cleanup period being over, it's time to start
> > > the second period, with 10 other patches. We're on June 15th, so I'll
> > > give people until June 30th to react on the following patches. If
> > > there's no reaction, like no interest from either the original
> > > submitter nor any other Buildroot developer, the patch will be marked
> > > Rejected on June 30th.
> > > 
> > > If you are in To: of this e-mail, then one or several of the patches
> > > below have been authored by you, so you should be interested :-)
> > > 
> > > Thanks,
> > > 
> > > Thomas
> > > 
> > > ?5. Fix for the makeinfo / missing issue, proposal from Romain
> > > ????http://patchwork.ozlabs.org/patch/595041/
> > > ????http://patchwork.ozlabs.org/patch/595042/
> > > ????http://patchwork.ozlabs.org/patch/595043/
> > > 
> > > ????We need to take a decision on this one. The problem also occurs for
> > > ????gdb and binutils on ARC, for which we've added a custom hack
> > > ????recently.
> > > 
> > > ????I tried to play with timestamps by touch'ing the .info files before
> > > ????the build, it worked with one of gdb or binutils, but failed for
> > > ????the other.
> > > 
> > > ????So either we take Romain's approach, or we bite the bullet and add
> > > ????a host-makeinfo package on which we depend when gdb/binutils are
> > > ????fetched from Git.
> > > 
> > IHMO the real problem is that binutils/gdb doesn't support --disable-docs
> > option. When present on the command line, this option must completely disable
> > the documentation (man, info, pdf etc) and let the build continue.
> > 
> > It seems that this issue was already discussed back in 2007 [1].
> > Last year I submitted a patch upstream to do that but it was not complete and
> > not tested due to autoconf version mismatch [2].
> > 
> > If we want to autoreconf binutils/gdb in Buildroot we must downgrade autoconf to
> > 2.64 and automake to 1.12.6.
> > 
> > Alexey, Vlad, I would suggest to rework your patch [3] and add --disable-docs
> > option instead of testing missing 127 return value.
> > If you succeed, we can reject my proposal from patchwork :)
> Right, that's what we're looking at now.
> Stay tuned and patch(es) will follow :)
> 
> -Alexey

I looked around adding --disable-docs option and faced some difficulties.
Configuration process is rather difficult in binutils.
?* "configure" scripts are generated for each package from corresponding template file.
?* "configure" script is generated from "configure.ac",?
?* "configure" script generates Makefiles from "Makefile.in" files, also it runs "configure" scripts in sub-directories, etc.
?* Build is recursive.?
?* Doc targets for some packages are added to separate directory, for other the are not.

Also I don't have required versions of autoconf (v. 2.64) and automake (v.1.11.6).
It is required to use particular versions to avoid introducing subtle bugs in configure and/or Makefile.in.
For example:
https://sourceware.org/ml/binutils/2013-04/msg00210.html

So implementing this option doesn't seem to be a low-hanging fruit after all.

Returning to the problem. Real issue is that build fails when "makeinfo" is missing on build host.
So a nice and much easier idea is to add "makeinfo" package and make binutils and gdb dependent on the "host-makeinfo" package.

--?
Best regards,
Vlad Zakharov <vzakhar@synopsys.com>

[Buildroot] Patchwork cleanup week #24

[Thomas Petazzoni]

Hello,

On Fri, 24 Jun 2016 07:24:37 +0000, Vlad Zakharov wrote:

> Returning to the problem. Real issue is that build fails when "makeinfo" is missing on build host.
> So a nice and much easier idea is to add "makeinfo" package and make
> binutils and gdb dependent on the "host-makeinfo" package.

I indeed start to think that it's the only reasonable solution. The
only thing I would like to see is this dependency being added only for
binutils/gdb version that want to re-generate their documentation.
Normally, binutils/gdb versions from release tarballs are fine and
don't try to regenerate their documentation.

As I said earlier, I tried to touch the relevant .info files to have
their timestamp to be later than the source files. It worked fine for
one of binutils or gdb (don't remember which one), but wasn't working
for the other one.

Best regards,

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

[Buildroot] Patchwork cleanup week #24

[Alexey Brodkin]

Hi Thomas,

On Fri, 2016-06-24 at 09:32 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 24 Jun 2016 07:24:37 +0000, Vlad Zakharov wrote:
> 
> > 
> > Returning to the problem. Real issue is that build fails when "makeinfo" is missing on build host.
> > So a nice and much easier idea is to add "makeinfo" package and make
> > binutils and gdb dependent on the "host-makeinfo" package.
> I indeed start to think that it's the only reasonable solution. The
> only thing I would like to see is this dependency being added only for
> binutils/gdb version that want to re-generate their documentation.
> Normally, binutils/gdb versions from release tarballs are fine and
> don't try to regenerate their documentation.

Agree. And we have necessary hooks already in place (remember that trick with "missing"
script) so that should be easy.

Still we'll need first to add makeinfo/texinfo package, right?

-Alexey

[Buildroot] Patchwork cleanup week #24

[Thomas Petazzoni]

Hello,

On Fri, 24 Jun 2016 09:13:09 +0000, Alexey Brodkin wrote:

> Agree. And we have necessary hooks already in place (remember that trick with "missing"
> script) so that should be easy.
> 
> Still we'll need first to add makeinfo/texinfo package, right?

Yes. But we used to have a host texinfo package
(https://git.busybox.net/buildroot/commit/?id=69aeb066a68108e0f78af34d5baf770c490954d0)
so it should be easy to re-introduce it.

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

[Buildroot] Patchwork cleanup week #24

[Alexey Brodkin]

Hi Thomas,

On Fri, 2016-06-24 at 11:15 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 24 Jun 2016 09:13:09 +0000, Alexey Brodkin wrote:
> 
> > 
> > Agree. And we have necessary hooks already in place (remember that trick with "missing"
> > script) so that should be easy.
> > 
> > Still we'll need first to add makeinfo/texinfo package, right?
> Yes. But we used to have a host texinfo package
> (https://git.busybox.net/buildroot/commit/?id=69aeb066a68108e0f78af34d5baf770c490954d0)
> so it should be easy to re-introduce it.

Yeah I was pretty sure I saw something like that in past thus was the question :)

Thanks for the pointer!

-Alexey

[Buildroot] Patchwork cleanup week #24

[Romain Naour]

Hi Vlad,

Le 24/06/2016 ? 09:24, Vlad Zakharov a ?crit :
> Hello, 
> 
> On Wed, 2016-06-22 at 05:45 +0000, Alexey Brodkin wrote:
>> Hi Romain,
>>
>> On Sat, 2016-06-18 at 16:07 +0200, Romain Naour wrote:
>>>
>>> Hi Thomas, Alexey, Vlad, All,
>>>
>>> Le 15/06/2016 ? 22:06, Thomas Petazzoni a ?crit :
>>>>
>>>>
>>>> Hello,
>>>>
>>>> The previous patchwork cleanup period being over, it's time to start
>>>> the second period, with 10 other patches. We're on June 15th, so I'll
>>>> give people until June 30th to react on the following patches. If
>>>> there's no reaction, like no interest from either the original
>>>> submitter nor any other Buildroot developer, the patch will be marked
>>>> Rejected on June 30th.
>>>>
>>>> If you are in To: of this e-mail, then one or several of the patches
>>>> below have been authored by you, so you should be interested :-)
>>>>
>>>> Thanks,
>>>>
>>>> Thomas
>>>>
>>>>  5. Fix for the makeinfo / missing issue, proposal from Romain
>>>>     http://patchwork.ozlabs.org/patch/595041/
>>>>     http://patchwork.ozlabs.org/patch/595042/
>>>>     http://patchwork.ozlabs.org/patch/595043/
>>>>
>>>>     We need to take a decision on this one. The problem also occurs for
>>>>     gdb and binutils on ARC, for which we've added a custom hack
>>>>     recently.
>>>>
>>>>     I tried to play with timestamps by touch'ing the .info files before
>>>>     the build, it worked with one of gdb or binutils, but failed for
>>>>     the other.
>>>>
>>>>     So either we take Romain's approach, or we bite the bullet and add
>>>>     a host-makeinfo package on which we depend when gdb/binutils are
>>>>     fetched from Git.
>>>>
>>> IHMO the real problem is that binutils/gdb doesn't support --disable-docs
>>> option. When present on the command line, this option must completely disable
>>> the documentation (man, info, pdf etc) and let the build continue.
>>>
>>> It seems that this issue was already discussed back in 2007 [1].
>>> Last year I submitted a patch upstream to do that but it was not complete and
>>> not tested due to autoconf version mismatch [2].
>>>
>>> If we want to autoreconf binutils/gdb in Buildroot we must downgrade autoconf to
>>> 2.64 and automake to 1.12.6.
>>>
>>> Alexey, Vlad, I would suggest to rework your patch [3] and add --disable-docs
>>> option instead of testing missing 127 return value.
>>> If you succeed, we can reject my proposal from patchwork :)
>> Right, that's what we're looking at now.
>> Stay tuned and patch(es) will follow :)
>>
>> -Alexey
> 
> I looked around adding --disable-docs option and faced some difficulties.
> Configuration process is rather difficult in binutils.
>  * "configure" scripts are generated for each package from corresponding template file.
>  * "configure" script is generated from "configure.ac", 
>  * "configure" script generates Makefiles from "Makefile.in" files, also it runs "configure" scripts in sub-directories, etc.
>  * Build is recursive. 
>  * Doc targets for some packages are added to separate directory, for other the are not.
> 
> Also I don't have required versions of autoconf (v. 2.64) and automake (v.1.11.6).
> It is required to use particular versions to avoid introducing subtle bugs in configure and/or Makefile.in.
> For example:
> https://sourceware.org/ml/binutils/2013-04/msg00210.html

You can build the required versions of autoconf and automake using Buildroot, if
you want to try with [1]...

> 
> So implementing this option doesn't seem to be a low-hanging fruit after all.
> 
> Returning to the problem. Real issue is that build fails when "makeinfo" is missing on build host.
> So a nice and much easier idea is to add "makeinfo" package and make binutils and gdb dependent on the "host-makeinfo" package.

Well, ok lets re-introduce "host-texinfo" package when binutils/gdb are build
from a git repository. Then you can revert some patches for binutils [2] and gdb
[3] [4].

Thanks,

Best regards,
Romain

[1] https://github.com/RomainNaour/buildroot/tree/autoconf-2.64
[2]
https://git.busybox.net/buildroot/commit/?id=f3e99991591c6356df8d55a794ed64fd20154654
[3]
https://git.busybox.net/buildroot/commit/?id=1180bafd8e1de2b12db3c7c235b128c9e48d4abb
[4]
https://git.busybox.net/buildroot/commit/?id=3aecfbd03dd2a8d49c97f1e68df42b077dbbd396
> 
> -- 
> Best regards,
> Vlad Zakharov <vzakhar@synopsys.com>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

[Buildroot] Patchwork cleanup week #24

[Cam Hutchison]

On 16 June 2016 at 06:06, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
> Hello,
>
> The previous patchwork cleanup period being over, it's time to start
> the second period, with 10 other patches. We're on June 15th, so I'll
> give people until June 30th to react on the following patches. If
> there's no reaction, like no interest from either the original
> submitter nor any other Buildroot developer, the patch will be marked
> Rejected on June 30th.
>
> If you are in To: of this e-mail, then one or several of the patches
> below have been authored by you, so you should be interested :-)
>
> [...]
>
>  9. overlay: Add archive-based (tar) rootfs overlays
>     http://patchwork.ozlabs.org/patch/610752/

I did post this patch, but I'm not sure how I'm meant to react to this
email. Do I just wait for someone to comment and if they don't, it
gets rejected?

[Buildroot] Patchwork cleanup week #24

[Cam Hutchison]

On 22 June 2016 at 16:14, Cam Hutchison <camh@xdna.net> wrote:
> On 16 June 2016 at 06:06, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>>
>> Hello,
>>
>> The previous patchwork cleanup period being over, it's time to start
>> the second period, with 10 other patches. We're on June 15th, so I'll
>> give people until June 30th to react on the following patches. If
>> there's no reaction, like no interest from either the original
>> submitter nor any other Buildroot developer, the patch will be marked
>> Rejected on June 30th.
>>
>> If you are in To: of this e-mail, then one or several of the patches
>> below have been authored by you, so you should be interested :-)
>>
>> [...]
>>
>>  9. overlay: Add archive-based (tar) rootfs overlays
>>     http://patchwork.ozlabs.org/patch/610752/
>
> I did post this patch, but I'm not sure how I'm meant to react to this
> email. Do I just wait for someone to comment and if they don't, it
> gets rejected?

So June 30th is here and I'm still not sure what I'm meant to do.

Does my patch just get marked as rejected now?

[Buildroot] Patchwork cleanup week #24

[Thomas Petazzoni]

Hello,

On Fri, 1 Jul 2016 09:51:07 +1000, Cam Hutchison wrote:

> >>  9. overlay: Add archive-based (tar) rootfs overlays
> >>     http://patchwork.ozlabs.org/patch/610752/  
> >
> > I did post this patch, but I'm not sure how I'm meant to react to this
> > email. Do I just wait for someone to comment and if they don't, it
> > gets rejected?  
> 
> So June 30th is here and I'm still not sure what I'm meant to do.
> 
> Does my patch just get marked as rejected now?

No, since you said you are still interested, we'll keep it in the
queue, and hopefully someone will review it. We precisely have a
Buildroot meeting this WE, so we'll try to handle it as part of our
discussions.

Thanks,

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

[Buildroot] Patchwork cleanup week #24

[Arnout Vandecappelle]

On 15-06-16 22:06, Thomas Petazzoni wrote:
>  3. toolchain-wrapper: prevent use of unsupported -fstack-protector*
>     http://patchwork.ozlabs.org/patch/545315/
> 
>     This patch proposes to make the toolchain wrapper fail immediately
>     when -fstack-protector is passed to gcc, but SSP support is not
>     available. This helps with some packages that assume that compiling
>     with -fstack-protector is enough to determine if SSP support is
>     available, while in several cases, doing a link test is necessary.
> 
>     I personally don't really like this change, as I believe it's
>     adding even more sorcery to our toolchain wrapper. Instead, the
>     problematic upstream packages should be fixed. Plus, at the time,
>     we had a few packages in this situation, but nowadays, I don't
>     think we have build failures due to this.
> 
>     So, my proposal would be to reject this patch.

 I originally advocated for this patch (see
https://patchwork.ozlabs.org/patch/543115/ ). My reasoning was that it's very
hard to write a reliable test for stackprotector, because optimisations can
easily elide so much from the test that the stackprotector disappears.
Therefore, a test that works fine for the current compiler may break down with
future gcc releases.

 Also, I prefer to be able to resolve entire classes of build problems rather
than patching individual packages. The toolchain wrapper is a clear example of
this: it only exists because packages don't reliable handle CFLAGS, otherwise we
could just pass --sysroot etc. in CFLAGS.

 On the other hand, for this particular case, autobuilder errors will appear for
failing packages, so at least it's not a hidden issue.

 Regards,
 Arnout

-- 
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] Patchwork cleanup week #24

[Jörg Krause]

On Mi, 2016-06-15 at 22:06 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> The previous patchwork cleanup period being over, it's time to start
> the second period, with 10 other patches. We're on June 15th, so I'll
> give people until June 30th to react on the following patches. If
> there's no reaction, like no interest from either the original
> submitter nor any other Buildroot developer, the patch will be marked
> Rejected on June 30th.
> 
> If you are in To: of this e-mail, then one or several of the patches
> below have been authored by you, so you should be interested :-)
> 
> 
> ?8. new package: alsacap
> ????http://patchwork.ozlabs.org/patch/607045/
> 
> ????Isn't there already a tool in alsa-utils that does the same thing
> ????more or less?

I guess you mean 'alsa-info' [1]. It's a shell script which does not
run within Busybox.

[1]?http://www.alsa-project.org/alsa-info.sh

J?rg

[Buildroot] Patchwork cleanup week #24

[Thomas Petazzoni]

J?rg,

On Sun, 26 Jun 2016 13:07:21 +0200, J?rg Krause wrote:

> > ?8. new package: alsacap
> > ????http://patchwork.ozlabs.org/patch/607045/
> > 
> > ????Isn't there already a tool in alsa-utils that does the same thing
> > ????more or less?  
> 
> I guess you mean 'alsa-info' [1]. It's a shell script which does not
> run within Busybox.
> 
> [1]?http://www.alsa-project.org/alsa-info.sh

OK, so packaging alsacap makes sense, thanks for checking.

Would you volunteer to adopt this patch and send an updated version
that fixes the various comments that have been made?

Thanks!

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

[Buildroot] Patchwork cleanup week #24

[Thomas Petazzoni]

Hello,

With a huge delay, here is the conclusion of this patchwork cleanup.
Things have been mainly cleaned up during the Buildroot Summer Camp
organized in early July.

On Wed, 15 Jun 2016 22:06:34 +0200, Thomas Petazzoni wrote:

>  1. board: add support for Chromebook Snow
>     http://patchwork.ozlabs.org/patch/563197/
> 
>     This one has not been reviewed. It would be sad not to merge it,
>     because we have merged some specific packages that are needed for
>     this defconfig (host-vboot-utils).

This patch has been applied, after some tweaks.

>  2. pyqtgraph: new package
>     http://patchwork.ozlabs.org/patch/529864/
> 
>     It seems to be a pretty straightforward package, but nobody
>     reviewed it.

Maxime Hadjinlian did some review, but there was no feedback from the
original author. The patch is marked as Changes Requested, so if nobody
resends a new version, we will simply forget it.

>  3. toolchain-wrapper: prevent use of unsupported -fstack-protector*
>     http://patchwork.ozlabs.org/patch/545315/
> 
>     This patch proposes to make the toolchain wrapper fail immediately
>     when -fstack-protector is passed to gcc, but SSP support is not
>     available. This helps with some packages that assume that compiling
>     with -fstack-protector is enough to determine if SSP support is
>     available, while in several cases, doing a link test is necessary.
> 
>     I personally don't really like this change, as I believe it's
>     adding even more sorcery to our toolchain wrapper. Instead, the
>     problematic upstream packages should be fixed. Plus, at the time,
>     we had a few packages in this situation, but nowadays, I don't
>     think we have build failures due to this.
> 
>     So, my proposal would be to reject this patch.

It has been collectively decided that this patch was no longer needed.

>  4. uboot: install multiple spl images
>     http://patchwork.ozlabs.org/patch/595980/

This patch was adopted by Maxime Hadjinlian, and merged.

>  5. Fix for the makeinfo / missing issue, proposal from Romain
>     http://patchwork.ozlabs.org/patch/595041/
>     http://patchwork.ozlabs.org/patch/595042/
>     http://patchwork.ozlabs.org/patch/595043/
> 
>     We need to take a decision on this one. The problem also occurs for
>     gdb and binutils on ARC, for which we've added a custom hack
>     recently.
> 
>     I tried to play with timestamps by touch'ing the .info files before
>     the build, it worked with one of gdb or binutils, but failed for
>     the other.
> 
>     So either we take Romain's approach, or we bite the bullet and add
>     a host-makeinfo package on which we depend when gdb/binutils are
>     fetched from Git.

We've taken the approach of adding a host-texinfo package to solve this
problem. The patches are merged, and it seems to work.

>  6. wget download: 'scheme missing' results in empty output file
>     http://patchwork.ozlabs.org/patch/599387/

We've taken a different approach for this problem: ensure _SITE is not
empty. The corresponding patch has been merged.

>  7. Fortran support
>     http://patchwork.ozlabs.org/patch/599678/
>     http://patchwork.ozlabs.org/patch/599679/
>     http://patchwork.ozlabs.org/patch/599680/

Improved Fortran support has been merged during the Buildroot Summer
Camp, and we have already enabled a few Fortran-based packages. So
those patches were no longer needed.

>  8. new package: alsacap
>     http://patchwork.ozlabs.org/patch/607045/
> 
>     Isn't there already a tool in alsa-utils that does the same thing
>     more or less?

A review has been done, so we've suggested the original submitter to
contribute a new version of the patch. In the mean time, the patch has
been marked as Changes Requested.

>  9. overlay: Add archive-based (tar) rootfs overlays
>     http://patchwork.ozlabs.org/patch/610752/

We have rejected this patch, and instead added a mechanism to run
custom scripts within the fakeroot environment.

> 10. Improvements to kernel headers version selection
>     http://patchwork.ozlabs.org/patch/612316/
>     http://patchwork.ozlabs.org/patch/612315/
>     http://patchwork.ozlabs.org/patch/612313/

We've rejected some of those patches, but did a few improvements in
this area as well.

All in all, none of those 10 topics remain in patchwork today.

Best regards,

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