[Buildroot] Patchwork cleanup #9: triaging proposal

[Buildroot] Patchwork cleanup #9: triaging proposal

[Thomas De Schampheleire]

Hi all,

This is the first part of patchwork cleanup session #9.

Quick recap:
- in this mail, a decision for a number of patches (exact number can
vary) is already proposed. Buildroot developers should provide
feedback stating their agreement/disagreement with this proposed
decision.

- patches are triaged into four categories:
    A. We want this patch and someone should refresh and resend it.
    B. We don't want this patch as it goes against Buildroot principles.
    C. We're not sure and want to know if the submitter is still
interested in pursuing this patch.
    D. We accept the problem that the patch is fixing, but the patch
can't be integrated in its current state. More work is needed, for
example on the core buildroot infrastructure. Therefore, the patch
will be added to the buildroot TODO list.

- after the brief agreement/disagreement phase, patch submitters are
notified and get two weeks to provide feedback and/or fight the
decision. Patchwork is already updated at the beginning of these two
weeks, but closed patches can always be reopened.

- during this two week cool-off period, new cleanup sessions can already start.


Triage proposal for this session:


[1/1] Option to copy Linaro gconv libs to target
Stanislav Vasic <svlasic@gmail.com>
http://patchwork.ozlabs.org/patch/288022

C unsure: the commit message mentions this is needed for xbmc, but
xbmc has been merged now without this change.


[RFC] core: Download all package sources
Clayton Shotwell <clshotwe@rockwellcollins.com>
http://patchwork.ozlabs.org/patch/288224

C unsure: there was some debate as to this patch is the right way to
proceed, or whether the buildroot mirror should contain more packages,
or provide a way to create a local buildroot mirror.


perf: libelf is required to compile perf
Andi Shyti <andi@etezian.org>
http://patchwork.ozlabs.org/patch/288534

B reject. Manually selecting libelf if you're using older kernel
versions works fine.


[1/1] add support for congatec conga-qmx6
Fabien Lahoudere (ECASINTERS) <fabien.lahoudere@openwide.fr>
http://patchwork.ozlabs.org/patch/288951

A accept


gcc: use generic infrastructure for patches
Arnout Vandecappelle <arnout@mind.be>
http://patchwork.ozlabs.org/patch/289052

C unsure. There has been some discussion on this, and it's unclear to
me if we want this and what the final solution should be. Arnout can
probably provide more input.


[1/2] util-linux: nommu: Add patch to use vfork in nommu arch.
Sonic Zhang <sonic.adi@gmail.com>
http://patchwork.ozlabs.org/patch/290234

[v2,1/3] e2fsprogs: nommu: Add patch to use vfork in nommu arch.
Sonic Zhang <sonic.adi@gmail.com>
http://patchwork.ozlabs.org/patch/291514

All two patches: C unsure: the first patch has received several
comments but does not seem to have a follow-up version. What to do
with all these Blackfin vfork patches is also unclear to me: should we
wait for upstream to accept them or not?


audiofile: needs dynamic library
Simon Dawson <spdawson@gmail.com>
http://patchwork.ozlabs.org/patch/290552

C unsure: the autobuild problem this patch is supposed to fixed is
still present (http://autobuild.buildroot.org/?reason=audiofile-0.3.6)
but the correctness of the patch has been under discussion. Gustavo
may possibly provide more details.


[v2,2/3] e2fsprogs: flat: Add patch to append uuid link flag after the
blkid link flags when checking the blkid library in the FLAT binary
mode.
Sonic Zhang <sonic.adi@gmail.com>
http://patchwork.ozlabs.org/patch/291515

B reject: according to me this patch is superseded by commit
http://git.buildroot.org/buildroot/commit/?id=a8da3cd61aafd3e2fd44b87725fcc14b60b93be8.
ThomasP: could you confirm?


[v2] util-linux: flat: Add patch to skip creating dynamic libraries
Sonic Zhang <sonic.adi@gmail.com>
http://patchwork.ozlabs.org/patch/291522

C unsure, is this still relevant? Is the solution correct? I couldn't
answer it...


[2/2] mpg123: use code optimized for ARM NEON SIMD engine if available
Sven Neumann <neumann@teufel.de>
http://patchwork.ozlabs.org/patch/293605

C unsure: Peter asked a question about this patch that never got answered.


Thanks for the feedback,
Thomas

[Buildroot] Patchwork cleanup #9: triaging proposal

[Arnout Vandecappelle]

On 24/04/14 21:46, Thomas De Schampheleire wrote:
> gcc: use generic infrastructure for patches
> Arnout Vandecappelle <arnout@mind.be>
> http://patchwork.ozlabs.org/patch/289052
> 
> C unsure. There has been some discussion on this, and it's unclear to
> me if we want this and what the final solution should be. Arnout can
> probably provide more input.


 There were comments from Peter and from ThomasP, and I believe I
addressed those.

 Note that now gcc 4.9 has been merged, the patch is not valid anymore.
Peter, ThomasP: should I first refresh and resubmit so you can comment on
it again?


 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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Patchwork cleanup #9: triaging proposal

[Thomas De Schampheleire]

On Fri, Apr 25, 2014 at 12:21 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 24/04/14 21:46, Thomas De Schampheleire wrote:
>> gcc: use generic infrastructure for patches
>> Arnout Vandecappelle <arnout@mind.be>
>> http://patchwork.ozlabs.org/patch/289052
>>
>> C unsure. There has been some discussion on this, and it's unclear to
>> me if we want this and what the final solution should be. Arnout can
>> probably provide more input.
>
>
>  There were comments from Peter and from ThomasP, and I believe I
> addressed those.
>
>  Note that now gcc 4.9 has been merged, the patch is not valid anymore.
> Peter, ThomasP: should I first refresh and resubmit so you can comment on
> it again?

Peter, ThomasP: your feedback on this patch?

Thanks,
Thomas

[Buildroot] Patchwork cleanup #9: triaging proposal

[Yann E. MORIN]

On 2014-04-24 21:46 +0200, Thomas De Schampheleire spake thusly:
> Hi all,
> 
> This is the first part of patchwork cleanup session #9.
> 
> Quick recap:
> - in this mail, a decision for a number of patches (exact number can
> vary) is already proposed. Buildroot developers should provide
> feedback stating their agreement/disagreement with this proposed
> decision.
> 
> - patches are triaged into four categories:
>     A. We want this patch and someone should refresh and resend it.
>     B. We don't want this patch as it goes against Buildroot principles.
>     C. We're not sure and want to know if the submitter is still
> interested in pursuing this patch.
>     D. We accept the problem that the patch is fixing, but the patch
> can't be integrated in its current state. More work is needed, for
> example on the core buildroot infrastructure. Therefore, the patch
> will be added to the buildroot TODO list.
> 
> - after the brief agreement/disagreement phase, patch submitters are
> notified and get two weeks to provide feedback and/or fight the
> decision. Patchwork is already updated at the beginning of these two
> weeks, but closed patches can always be reopened.
> 
> - during this two week cool-off period, new cleanup sessions can already start.
> 
> 
> Triage proposal for this session:
> 
> 
> [1/1] Option to copy Linaro gconv libs to target
> Stanislav Vasic <svlasic@gmail.com>
> http://patchwork.ozlabs.org/patch/288022
> 
> C unsure: the commit message mentions this is needed for xbmc, but
> xbmc has been merged now without this change.

I now Maxime has had a few issues with XBMC because it was lacking the
gconv stuff. It did manifest itself with broken (ie not rendering)
subtitles, due to missing charsets.

Sure, this is not required for XBMC to build and run properly, but it
seems it is needed for proper rendering of subtitles.

However, the patch limits it to Linaro gnueabihf toolchains, when it is
in fact a property og the C library. It should probably be switched to
"depends on glibc" instead.

So, I'd say: A, adopt, refresh, resend. I think I can find sometime for
this in the coming days, or Maxime might look at it since he's the one
that needs to read subtitles. ;-)

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 #9: triaging proposal

[clshotwe at rockwellcollins.com]

Thomas,

>[RFC] core: Download all package sources
>Clayton Shotwell <clshotwe@rockwellcollins.com>
>http://patchwork.ozlabs.org/patch/288224
>
>C unsure: there was some debate as to this patch is the right way to
>proceed, or whether the buildroot mirror should contain more
>packages,
>or provide a way to create a local buildroot mirror.

I would like to drop this patch. I will have to come up with
another approach to cover all of the corner cases of downloading
the different versions of the packages.

Thanks,
Clayton

[Buildroot] Patchwork cleanup #9: triaging proposal

[Thomas De Schampheleire]

Hi Clayton,

On Mon, Apr 28, 2014 at 4:05 PM,  <clshotwe@rockwellcollins.com> wrote:
> Thomas,
>
>>[RFC] core: Download all package sources
>>Clayton Shotwell <clshotwe@rockwellcollins.com>
>>http://patchwork.ozlabs.org/patch/288224
>>
>>C unsure: there was some debate as to this patch is the right way to
>>proceed, or whether the buildroot mirror should contain more
>>packages,
>>or provide a way to create a local buildroot mirror.
>
> I would like to drop this patch. I will have to come up with
> another approach to cover all of the corner cases of downloading
> the different versions of the packages.

Thanks for the feedback, I'll mark the patch as such.

Best regards,
Thomas

[Buildroot] Patchwork cleanup #9: triaging proposal

[Thomas De Schampheleire]

On Thu, Apr 24, 2014 at 9:46 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> audiofile: needs dynamic library
> Simon Dawson <spdawson@gmail.com>
> http://patchwork.ozlabs.org/patch/290552
>
> C unsure: the autobuild problem this patch is supposed to fixed is
> still present (http://autobuild.buildroot.org/?reason=audiofile-0.3.6)
> but the correctness of the patch has been under discussion. Gustavo
> may possibly provide more details.


Gustavo: could you provide more details about this audiofile
situation, and what to do with the mentioned patch?

Thanks,
Thomas

[Buildroot] Patchwork cleanup #9: triaging proposal

[Gustavo Zacarias]

On 04/30/2014 04:53 AM, Thomas De Schampheleire wrote:

> On Thu, Apr 24, 2014 at 9:46 PM, Thomas De Schampheleire
> <patrickdepinguin@gmail.com> wrote:
>> audiofile: needs dynamic library
>> Simon Dawson <spdawson@gmail.com>
>> http://patchwork.ozlabs.org/patch/290552
>>
>> C unsure: the autobuild problem this patch is supposed to fixed is
>> still present (http://autobuild.buildroot.org/?reason=audiofile-0.3.6)
>> but the correctness of the patch has been under discussion. Gustavo
>> may possibly provide more details.
> 
> 
> Gustavo: could you provide more details about this audiofile
> situation, and what to do with the mentioned patch?

Hi.
After some testing with latest git i've got:

Blackfin external 2013R1 FLAT builds audiofile (mpd can't because nommu).
Sourcery external 2013.11 ARM builds mpd with audiofile fine.

Mipsel internal defaults (+stdc +wchar) is fine too building mpd+audiofile.

Now that libstdc++.a is being copying it seems at least some common
cases work fine.
Maybe i'm missing something?

Regards.

[Buildroot] Patchwork cleanup #9: triaging proposal

[Gustavo Zacarias]

On 04/30/2014 08:57 AM, Gustavo Zacarias wrote:

>> Gustavo: could you provide more details about this audiofile
>> situation, and what to do with the mentioned patch?
> 
> Hi.
> After some testing with latest git i've got:
> 
> Blackfin external 2013R1 FLAT builds audiofile (mpd can't because nommu).
> Sourcery external 2013.11 ARM builds mpd with audiofile fine.
> 
> Mipsel internal defaults (+stdc +wchar) is fine too building mpd+audiofile.
> 
> Now that libstdc++.a is being copying it seems at least some common
> cases work fine.
> Maybe i'm missing something?

D'oh indeed i am, forgot to enable static for internal (and can't for
sourcery).
Blackfin works though since FLAT forces static.
I'll try some tricks and get back, but getting static rolling isn't a
big priority for me.
Regards.