[Buildroot] Patchwork cleanup, week #22

[Buildroot] Patchwork cleanup, week #22

[Thomas Petazzoni]

Hello,

Our patchwork currently has ~270 patches pending, so we need to do
something to clean up the backlog of patches. To do this, I will try to
revive an initiative that was started by Thomas De Schampheleire a few
years ago, which had proven to be useful.

Every two weeks, I will pick ~10 patches from the backlog. The goal is
to find out:

 1/ What is blocking the integration of those patches
 2/ Whether the original contributor is still interested
 3/ Whether a well-known Buildroot contributor/developer is willing to
    help, either by adopting the patch or by working with the original
    contributor.

So: if you are the original contributor of one the patch listed below,
please speak up if you're still interested in seeing your patch merged.

If there is no interest shown in a given patch, either by the original
contributor or by another Buildroot developer within the two weeks
time, I'll mark the patch as "Rejected" due to the lack of interest.
I'm sending this e-mail on June 1st, so on June 15th, for the patches
that have not seen any discussion or activity, I'll mark them as
Rejected.

Here is the list of week #22 :

 1/ package/libgpg-error: bump to version 1.21
    http://patchwork.ozlabs.org/patch/562100/

    I don't really have any comments, other than the fact that it is
    super annoying for a package with so many dependencies to start
    having architecture dependencies. Could someone refresh and
    validate this patch?

 2/ mysql/maria-db patches
    http://patchwork.ozlabs.org/patch/538042/
    http://patchwork.ozlabs.org/patch/538045/
    http://patchwork.ozlabs.org/patch/538043/
    http://patchwork.ozlabs.org/patch/538198/

    These are pretty big patches, and they turn MySQL into a virtual
    package, which has all sort of consequences. It would be good if
    some other Buildroot developer could do some in-depth
    review/testing of these patches.

 3/ RFC: adding customizable linux logo
    http://patchwork.ozlabs.org/patch/577638/

    This creates a "Linux extension" to easily customize the Linux
    logo. Do we care? The current implementation assumes imagemagick is
    available on the host, which probably isn't good. Probably the
    customlogo package is not needed, and convert the image to the
    appropriate format can be done directly in the
    CUSTOMLOGO_PREPARE_KERNEL hook.

    Do we want such a feature?

 4/ coreutils: allow selection of installed programs
    http://patchwork.ozlabs.org/patch/577829/

    There's been a lengthy discussion, but no real conclusion. Of
    course, we are questioning the value of having so many fine-grained
    Config.in options.

 5/ [PATCH 1/1] uboot: Strip "-Wl," from LDFLAGS
    http://patchwork.ozlabs.org/patch/581438/

    U-Boot uses LDFLAGS directly with the linker, with fails if you
    pass some -Wl,xyz options in BR2_TARGET_LDFLAGS. Do we care about
    fixing this issue? On the other hand, the fix is easy.

 6/ Makefile: Fix overlay overwriting everything
    http://patchwork.ozlabs.org/patch/581463/

    A problem with the merged /usr option, and when the rootfs overlay
    contains specific directories. Discussion has happened, no decision.

 7/ apply-patches.sh: handle any file name as *.patch
    http://patchwork.ozlabs.org/patch/595693/

 8/ util-linux: rework utilities menu for finer control
    http://patchwork.ozlabs.org/patch/589889/

 9/ host-fakeroot: re-run autotools to fix build on ppc64le host
    http://patchwork.ozlabs.org/patch/591255/

    I am not happy with having to force everyone to autoreconf for
    host-fakeroot (as it's a package part of the default Buildroot
    build), just for the few folks who use Buildroot on a ppc64le host.
    So either we make it conditional, or we get upstream to make a new
    release, or we find a minimal patch for the configure script that
    allows it to work on ppc64le. Suggestions?

 10/ The remaining "help text" related patches from Yann
     http://patchwork.ozlabs.org/patch/596393/
     http://patchwork.ozlabs.org/patch/596396/
     http://patchwork.ozlabs.org/patch/596397/
     http://patchwork.ozlabs.org/patch/596398/
     http://patchwork.ozlabs.org/patch/596399/
     http://patchwork.ozlabs.org/patch/596395/

     Do we want this?

     I like the general idea personally, but I continue to dislike the
     fact that the formatting is enforced at the infra level, with this
     weird syntax. I'd prefer packages to simply contribute a
     HELP_CMDS, or register a hook, where they can use "echo" to display
     whatever they want.

Thanks for your help,

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

[Buildroot] Patchwork cleanup, week #22

[Peter Seiderer]

Hello Thomas,

On Wed, 1 Jun 2016 23:26:54 +0200, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

[...]
>  6/ Makefile: Fix overlay overwriting everything
>     http://patchwork.ozlabs.org/patch/581463/
> 
>     A problem with the merged /usr option, and when the rootfs overlay
>     contains specific directories. Discussion has happened, no decision.
> 
[...]

Was not aware of this patch (and the discussion) but the same change is
already committed with a slightly different reasoning ([1])...

Regards,
Peter

[1] https://git.busybox.net/buildroot/commit/Makefile?id=0db34529f48a0ca76a4aadd08c9af57d37366d18

[Buildroot] Patchwork cleanup, week #22

[Thomas Petazzoni]

Hello,

On Wed, 1 Jun 2016 23:53:54 +0200, Peter Seiderer wrote:

> >  6/ Makefile: Fix overlay overwriting everything
> >     http://patchwork.ozlabs.org/patch/581463/
> > 
> >     A problem with the merged /usr option, and when the rootfs overlay
> >     contains specific directories. Discussion has happened, no decision.
> >   
> [...]
> 
> Was not aware of this patch (and the discussion) but the same change is
> already committed with a slightly different reasoning ([1])...

Thanks for the feedback. When I looked at Maxime's patch, I also had
the impression that the problem had already been fixed, but couldn't
spot the fix (I thought we fixed it in a different way, in the skeleton
package).

However, in the review of Maxime's patch, a number of issues have been
raised, so I'm wondering we have in the end merged your patch which
does the same, without answering those concerns.

Yann?

Best regards,

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

[Buildroot] Patchwork cleanup, week #22

[Jeroen Roovers]

On 1 June 2016 at 23:26, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
>
>  5/ [PATCH 1/1] uboot: Strip "-Wl," from LDFLAGS
>     http://patchwork.ozlabs.org/patch/581438/
>
>     U-Boot uses LDFLAGS directly with the linker, with fails if you
>     pass some -Wl,xyz options in BR2_TARGET_LDFLAGS. Do we care about
>     fixing this issue? On the other hand, the fix is easy.

I care about this. :)

It's useful to be able to globally use ld options like --as-needed,
and I found only uboot breaking (as it's the only package that
interprets LDFLAGS differently).

Alternatively, I could of course locally carry the patch indefinitely.

Kind regards,
     jer

[Buildroot] Patchwork cleanup, week #22

[Thomas Petazzoni]

Hello,

On Thu, 2 Jun 2016 09:41:29 +0200, Jeroen Roovers wrote:

> It's useful to be able to globally use ld options like --as-needed,
> and I found only uboot breaking (as it's the only package that
> interprets LDFLAGS differently).
> 
> Alternatively, I could of course locally carry the patch indefinitely.

What bothers me a bit is that LDFLAGS are not supposed to be passed to
"ld" directly, but to "gcc". So essentially, we are working-around a
bug in U-Boot. Though I agree that the workaround is not too big or
horrible.

But have you tried reporting this problem to upstream U-Boot, and see
what they say?

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

[Buildroot] Patchwork cleanup, week #22

[Jeroen Roovers]

On 2 June 2016 at 09:49, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> What bothers me a bit is that LDFLAGS are not supposed to be passed to
> "ld" directly, but to "gcc". So essentially, we are working-around a
> bug in U-Boot. Though I agree that the workaround is not too big or
> horrible.
>
> But have you tried reporting this problem to upstream U-Boot, and see
> what they say?

No, I did not, because uboot interprets LDFLAGS as linker flags
instead of compiler flags all over the place, so in buildroot the
patch is almost trivial whereas replacing all the linker flags in
uboot with compiler flags would not be. Also, the name of the variable
isn't a bug in uboot per se; GNU make interprets LDFLAGS as compiler
flags but there is nothing canonical about that and uboot obviously
overrides the implicit variable everywhere.


Kind regards,
      jer

[Buildroot] Patchwork cleanup, week #22

[Yann E. MORIN]

Thomas, All,

On 2016-06-01 23:26 +0200, Thomas Petazzoni spake thusly:
> Our patchwork currently has ~270 patches pending, so we need to do
> something to clean up the backlog of patches. To do this, I will try to
> revive an initiative that was started by Thomas De Schampheleire a few
> years ago, which had proven to be useful.

Thanks for re-starting this! :-)

>  1/ package/libgpg-error: bump to version 1.21
>     http://patchwork.ozlabs.org/patch/562100/
> 
>     I don't really have any comments, other than the fact that it is
>     super annoying for a package with so many dependencies to start
>     having architecture dependencies. Could someone refresh and
>     validate this patch?

Hmm... Fact is, upstream has not been very responsive to the proposal
for dumping the architecture detection:

    http://comments.gmane.org/gmane.comp.encryption.gpg.devel/21150
    http://comments.gmane.org/gmane.comp.encryption.gpg.devel/21176

They don't even seem to understand the problem... :-(

So, either we get stuck with the current version, but as Gustavo
noticed, that would preclude updtating libgcrypt, or we bump and have to
suffer this arch limitation...

>  3/ RFC: adding customizable linux logo
>     http://patchwork.ozlabs.org/patch/577638/
> 
>     This creates a "Linux extension" to easily customize the Linux
>     logo. Do we care? The current implementation assumes imagemagick is
>     available on the host, which probably isn't good. Probably the
>     customlogo package is not needed, and convert the image to the
>     appropriate format can be done directly in the
>     CUSTOMLOGO_PREPARE_KERNEL hook.
> 
>     Do we want such a feature?

Well, we can certainly accept that, but as I replied, let's just expect
the user to provide already rendered ppm/pbm images.

However, the ppm/pbm files are just text file. A user could provide a
patch to change the logo, and we already have the necessary infra to
apply patches...

>  6/ Makefile: Fix overlay overwriting everything
>     http://patchwork.ozlabs.org/patch/581463/
> 
>     A problem with the merged /usr option, and when the rootfs overlay
>     contains specific directories. Discussion has happened, no decision.

As already pointed out, this is supposedly fixed. I replied to Maxime,
askign him that he confirms the fix we already have works for him and if
so, that he marks his patch as superseded in patchwork.

>  7/ apply-patches.sh: handle any file name as *.patch
>     http://patchwork.ozlabs.org/patch/595693/

I am absolutely not decided on that one. Surely, it has the potential to
cause quite some harm...

>  10/ The remaining "help text" related patches from Yann
>      http://patchwork.ozlabs.org/patch/596393/
>      http://patchwork.ozlabs.org/patch/596396/
>      http://patchwork.ozlabs.org/patch/596397/
>      http://patchwork.ozlabs.org/patch/596398/
>      http://patchwork.ozlabs.org/patch/596399/
>      http://patchwork.ozlabs.org/patch/596395/
> 
>      Do we want this?
> 
>      I like the general idea personally, but I continue to dislike the
>      fact that the formatting is enforced at the infra level, with this
>      weird syntax. I'd prefer packages to simply contribute a
>      HELP_CMDS, or register a hook, where they can use "echo" to display
>      whatever they want.

I have been thinking about that one. As I asid, I'm not too fond of
letting packages handle their own formatting. But I can understand that
you do not like it (why? ;-] ).

So, I'll rework the series shortly. In the meantime, I've marked it as
changes-requested in patchwork.

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

[Yann E. MORIN]

Thomas, All,

On 2016-06-02 09:17 +0200, Thomas Petazzoni spake thusly:
> On Wed, 1 Jun 2016 23:53:54 +0200, Peter Seiderer wrote:
> 
> > >  6/ Makefile: Fix overlay overwriting everything
> > >     http://patchwork.ozlabs.org/patch/581463/
> > > 
> > >     A problem with the merged /usr option, and when the rootfs overlay
> > >     contains specific directories. Discussion has happened, no decision.
> > >   
> > [...]
> > 
> > Was not aware of this patch (and the discussion) but the same change is
> > already committed with a slightly different reasoning ([1])...
> 
> Thanks for the feedback. When I looked at Maxime's patch, I also had
> the impression that the problem had already been fixed, but couldn't
> spot the fix (I thought we fixed it in a different way, in the skeleton
> package).
> 
> However, in the review of Maxime's patch, a number of issues have been
> raised, so I'm wondering we have in the end merged your patch which
> does the same, without answering those concerns.

I've re-read Armout's conerns, and I don't think they are valid. And it
would not break any further than it is broken today.

Arnout's concern was that an overlay could be deliberately setup to
override a directory, like /var/spool (which is a symlink to ../tmp in
our skeleton) to make it a real directory with subdirs in there.

That patch would break this use-case, true.

However, let's take another example: /var/log is a symlink to ../tmp. If
a package install a sub-directory in there [*] the the directory would
end up as a sub-dir in /tmp/ on the target.

Now if an overlay is setup to override /var/log@ to a real directory,
then the previous behaviour (before that patch) would create a broken
system already. The patch at least makes it so the system is no longer
broken.

So, all in all, both cases are broken, either before or after the patch.

And I prefer the brokenness we have now than the one we had before.

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

[Yegor Yefremov]

On Fri, Jun 3, 2016 at 12:38 AM, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> Thomas, All,
>
> On 2016-06-01 23:26 +0200, Thomas Petazzoni spake thusly:
>> Our patchwork currently has ~270 patches pending, so we need to do
>> something to clean up the backlog of patches. To do this, I will try to
>> revive an initiative that was started by Thomas De Schampheleire a few
>> years ago, which had proven to be useful.
>
> Thanks for re-starting this! :-)
>
>>  1/ package/libgpg-error: bump to version 1.21
>>     http://patchwork.ozlabs.org/patch/562100/
>>
>>     I don't really have any comments, other than the fact that it is
>>     super annoying for a package with so many dependencies to start
>>     having architecture dependencies. Could someone refresh and
>>     validate this patch?
>
> Hmm... Fact is, upstream has not been very responsive to the proposal
> for dumping the architecture detection:
>
>     http://comments.gmane.org/gmane.comp.encryption.gpg.devel/21150
>     http://comments.gmane.org/gmane.comp.encryption.gpg.devel/21176
>
> They don't even seem to understand the problem... :-(
>
> So, either we get stuck with the current version, but as Gustavo
> noticed, that would preclude updtating libgcrypt, or we bump and have to
> suffer this arch limitation...
>
>>  3/ RFC: adding customizable linux logo
>>     http://patchwork.ozlabs.org/patch/577638/
>>
>>     This creates a "Linux extension" to easily customize the Linux
>>     logo. Do we care? The current implementation assumes imagemagick is
>>     available on the host, which probably isn't good. Probably the
>>     customlogo package is not needed, and convert the image to the
>>     appropriate format can be done directly in the
>>     CUSTOMLOGO_PREPARE_KERNEL hook.
>>
>>     Do we want such a feature?
>
> Well, we can certainly accept that, but as I replied, let's just expect
> the user to provide already rendered ppm/pbm images.
>
> However, the ppm/pbm files are just text file. A user could provide a
> patch to change the logo, and we already have the necessary infra to
> apply patches...
>
>>  6/ Makefile: Fix overlay overwriting everything
>>     http://patchwork.ozlabs.org/patch/581463/
>>
>>     A problem with the merged /usr option, and when the rootfs overlay
>>     contains specific directories. Discussion has happened, no decision.
>
> As already pointed out, this is supposedly fixed. I replied to Maxime,
> askign him that he confirms the fix we already have works for him and if
> so, that he marks his patch as superseded in patchwork.
>
>>  7/ apply-patches.sh: handle any file name as *.patch
>>     http://patchwork.ozlabs.org/patch/595693/
>
> I am absolutely not decided on that one. Surely, it has the potential to
> cause quite some harm...

Still had no time to make further testing. Will try to do this in the
next weeks.

>>  10/ The remaining "help text" related patches from Yann
>>      http://patchwork.ozlabs.org/patch/596393/
>>      http://patchwork.ozlabs.org/patch/596396/
>>      http://patchwork.ozlabs.org/patch/596397/
>>      http://patchwork.ozlabs.org/patch/596398/
>>      http://patchwork.ozlabs.org/patch/596399/
>>      http://patchwork.ozlabs.org/patch/596395/
>>
>>      Do we want this?
>>
>>      I like the general idea personally, but I continue to dislike the
>>      fact that the formatting is enforced at the infra level, with this
>>      weird syntax. I'd prefer packages to simply contribute a
>>      HELP_CMDS, or register a hook, where they can use "echo" to display
>>      whatever they want.
>
> I have been thinking about that one. As I asid, I'm not too fond of
> letting packages handle their own formatting. But I can understand that
> you do not like it (why? ;-] ).
>
> So, I'll rework the series shortly. In the meantime, I've marked it as
> changes-requested in patchwork.
>
> 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] Patchwork cleanup, week #22

[Carlos Santos]

> 8/ util-linux: rework utilities menu for finer control
>    http://patchwork.ozlabs.org/patch/589889/

I need to recollect the original discussion around that patch. I will take a look over the weekend.

Carlos Santos (Casantos)
DATACOM, P&D

[Buildroot] Patchwork cleanup, week #22

[Thomas Petazzoni]

Hello,

Since we're one week after the announcement, and one week away from the
deadline, here is a quick status on the 10 patches.

On Wed, 1 Jun 2016 23:26:54 +0200, Thomas Petazzoni wrote:

>  1/ package/libgpg-error: bump to version 1.21
>     http://patchwork.ozlabs.org/patch/562100/
> 
>     I don't really have any comments, other than the fact that it is
>     super annoying for a package with so many dependencies to start
>     having architecture dependencies. Could someone refresh and
>     validate this patch?

Nobody cared.

>  2/ mysql/maria-db patches
>     http://patchwork.ozlabs.org/patch/538042/
>     http://patchwork.ozlabs.org/patch/538045/
>     http://patchwork.ozlabs.org/patch/538043/
>     http://patchwork.ozlabs.org/patch/538198/
> 
>     These are pretty big patches, and they turn MySQL into a virtual
>     package, which has all sort of consequences. It would be good if
>     some other Buildroot developer could do some in-depth
>     review/testing of these patches.

Nobody cared. I will clearly throw away those patches if nobody is
interested in them, it's too much work to go through them if nobody
cares.

>  3/ RFC: adding customizable linux logo
>     http://patchwork.ozlabs.org/patch/577638/
> 
>     This creates a "Linux extension" to easily customize the Linux
>     logo. Do we care? The current implementation assumes imagemagick is
>     available on the host, which probably isn't good. Probably the
>     customlogo package is not needed, and convert the image to the
>     appropriate format can be done directly in the
>     CUSTOMLOGO_PREPARE_KERNEL hook.
> 
>     Do we want such a feature?

The patch has been reviewed, and several improvements have been
suggested. Therefore, the patch has been marked as Superseded. It has
not be resubmitted so far.

>  4/ coreutils: allow selection of installed programs
>     http://patchwork.ozlabs.org/patch/577829/
> 
>     There's been a lengthy discussion, but no real conclusion. Of
>     course, we are questioning the value of having so many fine-grained
>     Config.in options.

Nobody cared.

>  5/ [PATCH 1/1] uboot: Strip "-Wl," from LDFLAGS
>     http://patchwork.ozlabs.org/patch/581438/
> 
>     U-Boot uses LDFLAGS directly with the linker, with fails if you
>     pass some -Wl,xyz options in BR2_TARGET_LDFLAGS. Do we care about
>     fixing this issue? On the other hand, the fix is easy.

There has been some discussion between mean and Jeroen, and we
concluded that the patch was not necessary since anyway we are
currently not passing our LDFLAGS down to U-Boot. It has been marked as
Rejected.

>  6/ Makefile: Fix overlay overwriting everything
>     http://patchwork.ozlabs.org/patch/581463/
> 
>     A problem with the merged /usr option, and when the rootfs overlay
>     contains specific directories. Discussion has happened, no decision.

This patch was no longer needed, as the issue was already fixed, so it
has been marked as Supersed.

>  7/ apply-patches.sh: handle any file name as *.patch
>     http://patchwork.ozlabs.org/patch/595693/

Yegor said he would do more testing in the next weeks.

>  8/ util-linux: rework utilities menu for finer control
>     http://patchwork.ozlabs.org/patch/589889/

Carlos has resubmitted a newer version:
http://patchwork.ozlabs.org/patch/631262/

>  9/ host-fakeroot: re-run autotools to fix build on ppc64le host
>     http://patchwork.ozlabs.org/patch/591255/
> 
>     I am not happy with having to force everyone to autoreconf for
>     host-fakeroot (as it's a package part of the default Buildroot
>     build), just for the few folks who use Buildroot on a ppc64le host.
>     So either we make it conditional, or we get upstream to make a new
>     release, or we find a minimal patch for the configure script that
>     allows it to work on ppc64le. Suggestions?

Nobody cared. I'll throw it away if nobody comes back with a proper
solution.

>  10/ The remaining "help text" related patches from Yann
>      http://patchwork.ozlabs.org/patch/596393/
>      http://patchwork.ozlabs.org/patch/596396/
>      http://patchwork.ozlabs.org/patch/596397/
>      http://patchwork.ozlabs.org/patch/596398/
>      http://patchwork.ozlabs.org/patch/596399/
>      http://patchwork.ozlabs.org/patch/596395/
> 
>      Do we want this?
> 
>      I like the general idea personally, but I continue to dislike the
>      fact that the formatting is enforced at the infra level, with this
>      weird syntax. I'd prefer packages to simply contribute a
>      HELP_CMDS, or register a hook, where they can use "echo" to display
>      whatever they want.

Yann did a newer version, and after some changes I merged it. I believe
this topic is closed.

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

[Buildroot] Patchwork cleanup, week #22

[Romain Izard]

2016-06-08 22:13 GMT+02:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> Since we're one week after the announcement, and one week away from the
> deadline, here is a quick status on the 10 patches.
>
>
>>  4/ coreutils: allow selection of installed programs
>>     http://patchwork.ozlabs.org/patch/577829/
>>
>>     There's been a lengthy discussion, but no real conclusion. Of
>>     course, we are questioning the value of having so many fine-grained
>>     Config.in options.
>
> Nobody cared.

Please drop it, I'm not using it anymore.

Best regards,
-- 
Romain Izard

[Buildroot] Patchwork cleanup, week #22

[Thomas Petazzoni]

Hello,

On Thu, 9 Jun 2016 10:02:50 +0200, Romain Izard wrote:

> >>  4/ coreutils: allow selection of installed programs
> >>     http://patchwork.ozlabs.org/patch/577829/
> >>
> >>     There's been a lengthy discussion, but no real conclusion. Of
> >>     course, we are questioning the value of having so many fine-grained
> >>     Config.in options.  
> >
> > Nobody cared.  
> 
> Please drop it, I'm not using it anymore.

Thanks for your feedback. To be honest, I believe it was really too
fine-grained, and potentially something a bit annoying to maintain over
time.

You can always use a post-build script to get rid of unused tools.

Best regards,

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

[Buildroot] Patchwork cleanup, week #22

[Thomas Petazzoni]

Hello,

On Wed, 1 Jun 2016 23:26:54 +0200, Thomas Petazzoni wrote:

> If there is no interest shown in a given patch, either by the original
> contributor or by another Buildroot developer within the two weeks
> time, I'll mark the patch as "Rejected" due to the lack of interest.
> I'm sending this e-mail on June 1st, so on June 15th, for the patches
> that have not seen any discussion or activity, I'll mark them as
> Rejected.

We are on June 15th.

> Here is the list of week #22 :
> 
>  1/ package/libgpg-error: bump to version 1.21
>     http://patchwork.ozlabs.org/patch/562100/
> 
>     I don't really have any comments, other than the fact that it is
>     super annoying for a package with so many dependencies to start
>     having architecture dependencies. Could someone refresh and
>     validate this patch?

I'm keeping this one around, since we really want to bump libgpg-error
at some point.

>  2/ mysql/maria-db patches
>     http://patchwork.ozlabs.org/patch/538042/
>     http://patchwork.ozlabs.org/patch/538045/
>     http://patchwork.ozlabs.org/patch/538043/
>     http://patchwork.ozlabs.org/patch/538198/
> 
>     These are pretty big patches, and they turn MySQL into a virtual
>     package, which has all sort of consequences. It would be good if
>     some other Buildroot developer could do some in-depth
>     review/testing of these patches.

Nobody has reacted on those patches, so I'm marking them as Rejected.
They are still available on the mailing list if anyone wants to revive
them some day.

>  3/ RFC: adding customizable linux logo
>     http://patchwork.ozlabs.org/patch/577638/
> 
>     This creates a "Linux extension" to easily customize the Linux
>     logo. Do we care? The current implementation assumes imagemagick is
>     available on the host, which probably isn't good. Probably the
>     customlogo package is not needed, and convert the image to the
>     appropriate format can be done directly in the
>     CUSTOMLOGO_PREPARE_KERNEL hook.
> 
>     Do we want such a feature?

This one had already been marked "Changes Requested".

> 
>  4/ coreutils: allow selection of installed programs
>     http://patchwork.ozlabs.org/patch/577829/
> 
>     There's been a lengthy discussion, but no real conclusion. Of
>     course, we are questioning the value of having so many fine-grained
>     Config.in options.

In agreement with the author, this one has been marked Rejected.

> 
>  5/ [PATCH 1/1] uboot: Strip "-Wl," from LDFLAGS
>     http://patchwork.ozlabs.org/patch/581438/
> 
>     U-Boot uses LDFLAGS directly with the linker, with fails if you
>     pass some -Wl,xyz options in BR2_TARGET_LDFLAGS. Do we care about
>     fixing this issue? On the other hand, the fix is easy.

After testing and discussion with the author it has been marked
Rejected.

> 
>  6/ Makefile: Fix overlay overwriting everything
>     http://patchwork.ozlabs.org/patch/581463/
> 
>     A problem with the merged /usr option, and when the rootfs overlay
>     contains specific directories. Discussion has happened, no decision.

This had already been fixed differently, so it has already been marked
Superseded.

>  7/ apply-patches.sh: handle any file name as *.patch
>     http://patchwork.ozlabs.org/patch/595693/

This one has several comments that have not been taken into account, so
I'm marking it as Changes Requested.

> 
>  8/ util-linux: rework utilities menu for finer control
>     http://patchwork.ozlabs.org/patch/589889/

This one has already been marked as Superseded, since Carlos did a
newer version: http://patchwork.ozlabs.org/patch/631262/.

>  9/ host-fakeroot: re-run autotools to fix build on ppc64le host
>     http://patchwork.ozlabs.org/patch/591255/
> 
>     I am not happy with having to force everyone to autoreconf for
>     host-fakeroot (as it's a package part of the default Buildroot
>     build), just for the few folks who use Buildroot on a ppc64le host.
>     So either we make it conditional, or we get upstream to make a new
>     release, or we find a minimal patch for the configure script that
>     allows it to work on ppc64le. Suggestions?

Nobody has suggested a better solution, and it's a corner case, so I
marked it has rejected.

>  10/ The remaining "help text" related patches from Yann
>      http://patchwork.ozlabs.org/patch/596393/
>      http://patchwork.ozlabs.org/patch/596396/
>      http://patchwork.ozlabs.org/patch/596397/
>      http://patchwork.ozlabs.org/patch/596398/
>      http://patchwork.ozlabs.org/patch/596399/
>      http://patchwork.ozlabs.org/patch/596395/

A newer version of this has been submitted by Yann and merged.

Summary of the cleanup: on a total of 10 patches, we have 2 left: one
that has been revived by a newer version, and one that we keep because
it is really something we want to do (bumping libgpg-error).

Best regards,

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

[Buildroot] Patchwork cleanup, week #22

[Carlos Santos]

> From: "Thomas Petazzoni" <thomas.petazzoni@free-electrons.com>
> To: buildroot at uclibc.org, "joerg krause" <joerg.krause@embedded.rocks>, "sylvain raybaud"
> <sylvain.raybaud@green-communications.fr>, "Angelo Compagnucci" <angelo.compagnucci@gmail.com>, "Romain Izard"
> <romain.izard.pro@gmail.com>, "Jeroen Roovers" <jer@airfi.aero>, "Maxime Hadjinlian" <maxime.hadjinlian@gmail.com>,
> "Yegor Yefremov" <yegorslists@googlemail.com>, "Danomi Manchego" <danomimanchego123@gmail.com>, "Carlos Santos"
> <casantos@datacom.ind.br>, "Stewart Smith" <stewart@linux.vnet.ibm.com>, "Yann E. MORIN" <yann.morin.1998@free.fr>
> Sent: Wednesday, June 15, 2016 4:52:58 PM
> Subject: Re: [Buildroot] Patchwork cleanup, week #22

> Hello,
> 
> On Wed, 1 Jun 2016 23:26:54 +0200, Thomas Petazzoni wrote:

>>  4/ coreutils: allow selection of installed programs
>>     http://patchwork.ozlabs.org/patch/577829/
>> 
>>     There's been a lengthy discussion, but no real conclusion. Of
>>     course, we are questioning the value of having so many fine-grained
>>     Config.in options.
> 
> In agreement with the author, this one has been marked Rejected.

I was sympathetic to the idea for the same reasons why I'm interested on the change in util-linux. I did not have time to work on it, however. Perhaps I will give it a try later but for the moment let's leave coreutils in peace.

>>  8/ util-linux: rework utilities menu for finer control
>>     http://patchwork.ozlabs.org/patch/589889/
> 
> This one has already been marked as Superseded, since Carlos did a
> newer version: http://patchwork.ozlabs.org/patch/631262/.

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

Carlos Santos (Casantos)
DATACOM, P&D

[Buildroot] Patchwork cleanup, week #22

[Jörg Krause]

On Mi, 2016-06-15 at 21:52 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Wed, 1 Jun 2016 23:26:54 +0200, Thomas Petazzoni wrote:
> 
> > If there is no interest shown in a given patch, either by the
> > original
> > contributor or by another Buildroot developer within the two weeks
> > time, I'll mark the patch as "Rejected" due to the lack of
> > interest.
> > I'm sending this e-mail on June 1st, so on June 15th, for the
> > patches
> > that have not seen any discussion or activity, I'll mark them as
> > Rejected.
> 
> We are on June 15th.
> 
> > Here is the list of week #22 :
> > 
> > ?1/ package/libgpg-error: bump to version 1.21
> > ????http://patchwork.ozlabs.org/patch/562100/
> > 
> > ????I don't really have any comments, other than the fact that it
> > is
> > ????super annoying for a package with so many dependencies to start
> > ????having architecture dependencies. Could someone refresh and
> > ????validate this patch?
> 
> I'm keeping this one around, since we really want to bump libgpg-
> error
> at some point.

Sorry for not taking part in the discussion yet! I suggest to put some
effort to find an upstreamable solution. As Yann has noted I did a
proposal to remove the architecture dependency. However, I do not
understand the concern of the maintainer about ABI compliance. There
was no reaction to my last mail whereupon I stopped working on this
issue for now.

Anyone else interested in helping to solve this issue?

Best regards
J?rg Krause