[Buildroot] Patchwork cleanup #7: triaging proposal

[Buildroot] Patchwork cleanup #7: triaging proposal

[Thomas De Schampheleire]

Hi all,

Here is a first patchwork cleanup based on the new patchwork cleanup
proposal [1]. Let's see how this goes and evaluate after one or more
sessions.

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 three 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.

- 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:

A. Patches to keep:
-------------------

directfb-lua: new package
http://patchwork.ozlabs.org/patch/262971/

[v2] Standardisation of $(BUILD)/.root name
http://patchwork.ozlabs.org/patch/265680/

[2/2] arch/Config.in: Allow ARM to select BR2_BINFMT_FLAT
http://patchwork.ozlabs.org/patch/272450/

arch/Config.in: Allow arm7tdmi to select BR2_BINFMT_FLAT
http://patchwork.ozlabs.org/patch/273066/

[Note: the above two patches are related. The feedback in the patch is
to introduce a split between ARCH_HAS_MMU and BR2_USE_MMU, and thus
requires quite some work in the core infrastructure.]


[RFC] uclibc: Don't build shared library if !HAVE_SHARED
http://patchwork.ozlabs.org/patch/273175/

Add pyside + shiboken packages
http://patchwork.ozlabs.org/patch/275929/

[v2,1/1] package: remove the trailing slash sign from $(PKG)_SITE variable
http://patchwork.ozlabs.org/patch/276237/

[v2,1/1] u-boot: allow to pass a custom configuration file
http://patchwork.ozlabs.org/patch/276286/

[v3,01/11] udev: explicitly include pthreads
http://patchwork.ozlabs.org/patch/278298

[v3,02/11] sunxi-mali: add explicit pthread/dl/rt dependencies
http://patchwork.ozlabs.org/patch/278295

[v3,05/11] sunxi-cedarx: bump to newer version, use armel2 binaries, add demo
http://patchwork.ozlabs.org/patch/278299

[v3,08/11] libpng12: new package
http://patchwork.ozlabs.org/patch/278300

[v3,09/11] libpng: ensure libpng12 is installed before libpng
http://patchwork.ozlabs.org/patch/278301

[v3,10/11] glmark2: new package
http://patchwork.ozlabs.org/patch/278304

[v3,11/11] mesa3d-demos: new package
http://patchwork.ozlabs.org/patch/278305


B. Patches to reject:
---------------------

infra: display current task as title of the term window
http://patchwork.ozlabs.org/patch/265214/

[Reason: as stated in the patch discussion, there is a problem when
interrupting the build. An alternative has been suggested: update the
MESSAGEs with a progress indication instead. The patch submitter could
send a new patch implementing this proposal if he is interested.]


C. Unsure / need more investigation:
------------------------------------

[RESEND] package/Makefile.in: Fix dependency for selecting uclinux as TARGET_OS
http://patchwork.ozlabs.org/patch/277119/

libgcc erroneously built as armv5 for arm920t(armv4t)
http://patchwork.ozlabs.org/patch/278212/



Thanks for your feedback,
Thomas


[1] http://lists.busybox.net/pipermail/buildroot/2014-March/091677.html

[Buildroot] Patchwork cleanup #7: triaging proposal

[Yann E. MORIN]

Thomas, All,

On 2014-03-16 08:48 +0100, Thomas De Schampheleire spake thusly:
> Here is a first patchwork cleanup based on the new patchwork cleanup
> proposal [1]. Let's see how this goes and evaluate after one or more
> sessions.
[--SNIP--]

Thanks for putting up this list! :-)

> A. Patches to keep:
> -------------------
> 
> directfb-lua: new package
> http://patchwork.ozlabs.org/patch/262971/

    Vote: A, keep.

> [v2] Standardisation of $(BUILD)/.root name
> http://patchwork.ozlabs.org/patch/265680/

    Vote C: unsure.

> [2/2] arch/Config.in: Allow ARM to select BR2_BINFMT_FLAT
> http://patchwork.ozlabs.org/patch/272450/
>
> arch/Config.in: Allow arm7tdmi to select BR2_BINFMT_FLAT
> http://patchwork.ozlabs.org/patch/273066/
> 
> [Note: the above two patches are related. The feedback in the patch is
> to introduce a split between ARCH_HAS_MMU and BR2_USE_MMU, and thus
> requires quite some work in the core infrastructure.]

As Thomas said, they can't go in as-is. It would be better to add
generic config options (_HAS_MMU, _USE_MMU et al.) first.

So I'd rather say:
    Vote: C, unsure: we do not want _these_ patches, but a better way
    to express such a configuration.
 
> [RFC] uclibc: Don't build shared library if !HAVE_SHARED
> http://patchwork.ozlabs.org/patch/273175/

    Vote: A, keep.

> Add pyside + shiboken packages
> http://patchwork.ozlabs.org/patch/275929/

    Vote: A, keep. Needs heavy refresh, though.

> [v2,1/1] package: remove the trailing slash sign from $(PKG)_SITE variable
> http://patchwork.ozlabs.org/patch/276237/

    Vote: A, keep. Needs heavy refresh, though. Pretty trivial to do,
    and very easy to automate. I'll take.

> [v2,1/1] u-boot: allow to pass a custom configuration file
> http://patchwork.ozlabs.org/patch/276286/

    Vote: C, unsure. This is likely to overwrite a uboot source file
    with a local file, so we won't be able to generate conpliant
    legal-info when a custom comnfig file is used.

> [v3,01/11] udev: explicitly include pthreads
> http://patchwork.ozlabs.org/patch/278298

    Vote: C, unsure. There was no feedback on the reason why the change
    was needed in the first place (Peter tested and it worked).
 
> [v3,02/11] sunxi-mali: add explicit pthread/dl/rt dependencies
> http://patchwork.ozlabs.org/patch/278295

    Vote: C, unsure. Same as above.

> [v3,05/11] sunxi-cedarx: bump to newer version, use armel2 binaries, add demo
> http://patchwork.ozlabs.org/patch/278299

    Vote: A, keep.

> [v3,08/11] libpng12: new package
> http://patchwork.ozlabs.org/patch/278300
> 
> [v3,09/11] libpng: ensure libpng12 is installed before libpng
> http://patchwork.ozlabs.org/patch/278301

    Vote: A, keep both.

> [v3,10/11] glmark2: new package
> http://patchwork.ozlabs.org/patch/278304

    Vote: A, keep.

> [v3,11/11] mesa3d-demos: new package
> http://patchwork.ozlabs.org/patch/278305

    Vote: A, keep.

> B. Patches to reject:
> ---------------------
> 
> infra: display current task as title of the term window
> http://patchwork.ozlabs.org/patch/265214/

    Vote: B, reject.

> C. Unsure / need more investigation:
> ------------------------------------
> 
> [RESEND] package/Makefile.in: Fix dependency for selecting uclinux as TARGET_OS
> http://patchwork.ozlabs.org/patch/277119/

    Vote: C, unsure. It looks related to the two other patches above:
        [2/2] arch/Config.in: Allow ARM to select BR2_BINFMT_FLAT
        arch/Config.in: Allow arm7tdmi to select BR2_BINFMT_FLAT

> libgcc erroneously built as armv5 for arm920t(armv4t)
> http://patchwork.ozlabs.org/patch/278212/

    Vote: B, reject. Should be fixed by:
    d3539dd5: arch: pass cpu option instead of tune option on ARM

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

[Yann E. MORIN]

Micha?l, All,

Please, do not send HTML mails, they do not make it to the list.
HTML mail is frowned upon on this list.

On 2014-03-16 17:56 +0100, Micha?l Zweers spake thusly:
> Yann E. MORIN wrote:
> 
>  [v3,02/11] sunxi-mali: add explicit pthread/dl/rt dependencies
>  [1]http://patchwork.ozlabs.org/patch/278295
> 
>     Vote: C, unsure. There was no feedback on the reason why the change
>     was needed in the first place (Peter tested and it worked).
>
> When cross compiling Qt5 for Olinuxino A13 I needed to link every Opengl program to
> -ldl -lrt -lpthread otherwise they would die during init. The sunxi OpenGl (framebuffer) binary blops probably needs them to function properly.
> (From my error logs, may be incomplete i don't really remember):
> #0  0x00000000 in ?? () #1  0x4020a584 in __pthread_initialize_minimal_internal ()
>    from /lib/libpthread.so.0 #2  0x40208bec in _init () from /lib/libpthread.so.0
> #3  0x4000e0d0 in ?? () from /lib/ld-linux.so.3
> #4  0xbefffcac in ?? () (gdb)
>
> So A, keep :)

Can you share your .config, please, so we can try to reproduce your build
failure?

You are reporting the exact same synptoms as the original submitter, but
that does not help understand what the problem actually is.

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

[Arnout Vandecappelle]

On 03/16/14 19:43, Yann E. MORIN wrote:
> Micha?l, All,
> 
> Please, do not send HTML mails, they do not make it to the list.
> HTML mail is frowned upon on this list.
> 
> On 2014-03-16 17:56 +0100, Micha?l Zweers spake thusly:
>> Yann E. MORIN wrote:
>>
>>  [v3,02/11] sunxi-mali: add explicit pthread/dl/rt dependencies
>>  [1]http://patchwork.ozlabs.org/patch/278295
>>
>>     Vote: C, unsure. There was no feedback on the reason why the change
>>     was needed in the first place (Peter tested and it worked).
>>
>> When cross compiling Qt5 for Olinuxino A13 I needed to link every Opengl program to
>> -ldl -lrt -lpthread otherwise they would die during init. The sunxi OpenGl (framebuffer) binary blops probably needs them to function properly.
>> (From my error logs, may be incomplete i don't really remember):
>> #0  0x00000000 in ?? () #1  0x4020a584 in __pthread_initialize_minimal_internal ()
>>    from /lib/libpthread.so.0 #2  0x40208bec in _init () from /lib/libpthread.so.0
>> #3  0x4000e0d0 in ?? () from /lib/ld-linux.so.3
>> #4  0xbefffcac in ?? () (gdb)
>>
>> So A, keep :)
> 
> Can you share your .config, please, so we can try to reproduce your build
> failure?
> 
> You are reporting the exact same synptoms as the original submitter, but
> that does not help understand what the problem actually is.

 But Michael made it clear that it's a runtime failure, not a build failure:

"otherwise they would die during init"

 Looking at the backtrace,though, it doesn't make sense to me: the
dynamic linker does resolve into /lib/libpthread.so.0, so how will an
additional -lpthread at link time make a difference?


 Regards,
 Arnout


> 
> Regards,
> Yann E. MORIN.
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Patchwork cleanup #7: triaging proposal

[Ezequiel García]

On 16 March 2014 13:07, Yann E. MORIN <yann.morin.1998@free.fr> wrote:
>>
>> directfb-lua: new package
>> http://patchwork.ozlabs.org/patch/262971/
>
>     Vote: A, keep.
>

Quick context for directfb-lua.

This is a little languange binding I created a few years ago when I was working
close to DirectFB. However, it's no longer the case, and I won't be
improving it.
Of course, I'm still here and I can try to maintain it.

Probably it should be integrated into DirectFB itself, as a automated-test tool
or something, but that's something the DFB people should do.

I thought about submitting the package to Buildroot, as otherwise it would fall
into oblivion. The tool itself is handy for anyone working on DFB; at
least to run
quick API tests.

That said, I'm happy to provide a v2, addressing Fran?ois' feedback.
I just need to find some time to do it.

Regards,
-- 
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar

[Buildroot] Patchwork cleanup #7: triaging proposal

[Thomas Petazzoni]

Dear Ezequiel Garc?a,

On Sun, 16 Mar 2014 20:51:53 -0300, Ezequiel Garc?a wrote:

> Quick context for directfb-lua.
> 
> This is a little languange binding I created a few years ago when I was working
> close to DirectFB. However, it's no longer the case, and I won't be
> improving it.
> Of course, I'm still here and I can try to maintain it.
> 
> Probably it should be integrated into DirectFB itself, as a automated-test tool
> or something, but that's something the DFB people should do.
> 
> I thought about submitting the package to Buildroot, as otherwise it would fall
> into oblivion. The tool itself is handy for anyone working on DFB; at
> least to run
> quick API tests.
> 
> That said, I'm happy to provide a v2, addressing Fran?ois' feedback.
> I just need to find some time to do it.

If you don't use it, you don't really develop it anymore, and there
isn't interest from other users, then maybe it isn't worth the effort
to add this package in Buildroot?

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

[Buildroot] Patchwork cleanup #7: triaging proposal

[Ezequiel García]

On 18 March 2014 01:54, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Sun, 16 Mar 2014 20:51:53 -0300, Ezequiel Garc?a wrote:
>
>> Quick context for directfb-lua.
>>
>> This is a little languange binding I created a few years ago when I was working
>> close to DirectFB. However, it's no longer the case, and I won't be
>> improving it.
>> Of course, I'm still here and I can try to maintain it.
>>
>> Probably it should be integrated into DirectFB itself, as a automated-test tool
>> or something, but that's something the DFB people should do.
>>
>> I thought about submitting the package to Buildroot, as otherwise it would fall
>> into oblivion. The tool itself is handy for anyone working on DFB; at
>> least to run
>> quick API tests.
>>
>> That said, I'm happy to provide a v2, addressing Fran?ois' feedback.
>> I just need to find some time to do it.
>
> If you don't use it, you don't really develop it anymore, and there
> isn't interest from other users, then maybe it isn't worth the effort
> to add this package in Buildroot?
>

I'm fine either way. As I said, I believe this should be integrated
into DFB's core,
rather than here. But since that won't seem to happen, I thought it would
be better to put it here and maybe "attract" some new users.
-- 
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar

[Buildroot] Patchwork cleanup #7: triaging proposal

[Jérôme Pouiller]

On Sunday 16 March 2014 17:07:12 Yann E. MORIN wrote:
> Thomas, All,
> 
> On 2014-03-16 08:48 +0100, Thomas De Schampheleire spake thusly:
[...]
> > [v2] Standardisation of $(BUILD)/.root name
> > http://patchwork.ozlabs.org/patch/265680/
> 
>     Vote C: unsure.
I am also unsure:
  - With integration of parallel make, i think this patch does no more apply 
correctly to master.

  - It looks like stamps/ directory is no more used. So, it may be possible to 
drop stamps/. I continue to think .root should be more visible, but I am not 
sure about where to place it.


-- 
J?r?me Pouiller, Sysmic
Embedded Linux specialist
http://www.sysmic.fr

[Buildroot] Patchwork cleanup #7: triaging proposal

[Thomas De Schampheleire]

Hi Jerome,

On Tue, Mar 18, 2014 at 1:00 PM, J?r?me Pouiller <jezz@sysmic.org> wrote:
> On Sunday 16 March 2014 17:07:12 Yann E. MORIN wrote:
>> Thomas, All,
>>
>> On 2014-03-16 08:48 +0100, Thomas De Schampheleire spake thusly:
> [...]
>> > [v2] Standardisation of $(BUILD)/.root name
>> > http://patchwork.ozlabs.org/patch/265680/
>>
>>     Vote C: unsure.
> I am also unsure:
>   - With integration of parallel make, i think this patch does no more apply
> correctly to master.
>
>   - It looks like stamps/ directory is no more used. So, it may be possible to
> drop stamps/. I continue to think .root should be more visible, but I am not
> sure about where to place it.

Arnout has sent a patch removing stamps and related lines, it has been
integrated already.
I also don't know what could be a better place than output/build/.root though.

Best regards,
Thomas

[Buildroot] Patchwork cleanup #7: triaging proposal

[Arnout Vandecappelle]

On 03/16/14 08:48, Thomas De Schampheleire wrote:
> [v2] Standardisation of $(BUILD)/.root name
> http://patchwork.ozlabs.org/patch/265680/

 Vote B: Reject

 This patch moves $(BUILD_DIR)/.root to
$(STAMP_DIR)/skeleton-target-installed, but since the migration of
toolchains to the package infrastructure, the $(STAMP_DIR) is no longer
used (and in fact should be removed).

 While I'm not a big fan of $(BUILD_DIR)/.root, I don't think that moving
it to the now-unused $(STAMP_DIR) is a good idea.


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

[Thomas De Schampheleire]

All,

On Sun, Mar 16, 2014 at 8:48 AM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> Hi all,
>
> Here is a first patchwork cleanup based on the new patchwork cleanup
> proposal [1]. Let's see how this goes and evaluate after one or more
> sessions.
>
> 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 three 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.
>
> - 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.
>

A little later than expected, here is the conclusion of this triaging
session. As announced, a two-week cool-off period will be initiated
after notifying the submitters (in a separate mail), allowing them to
provide feedback. In the mean time, new triaging sessions can be
started.

>
> Triage proposal for this session:
>
> A. Patches to keep:
> -------------------
>
> directfb-lua: new package
> http://patchwork.ozlabs.org/patch/262971/

Ezequiel Garcia is no longer actively developing/using this tool. He
is willing to refresh the patch, but as ThomasP pointed out: if no-one
is using the tool it is not really needed to add it as a buildroot
package.
Based on this feedback, I will mark the patch as 'Changes requested'.
Ezequiel can still refresh the patch if/when he wants, but there is no
pressure at all.

>
> [v2] Standardisation of $(BUILD)/.root name
> http://patchwork.ozlabs.org/patch/265680/

With the stamps/ directory being gone after converting the toolchain
packages into the standard package frameworks, this patch no longer
made sense. Arnout submitted a patch removing the last remains of
STAMP_DIR and friends.
The patch as it is is no longer desired, so will be marked as
Rejected. This does not mean the original submitter can submit an
alternate proposal for .root, though.

>
> [2/2] arch/Config.in: Allow ARM to select BR2_BINFMT_FLAT
> http://patchwork.ozlabs.org/patch/272450/
>
> arch/Config.in: Allow arm7tdmi to select BR2_BINFMT_FLAT
> http://patchwork.ozlabs.org/patch/273066/
>
> [Note: the above two patches are related. The feedback in the patch is
> to introduce a split between ARCH_HAS_MMU and BR2_USE_MMU, and thus
> requires quite some work in the core infrastructure.]

Here Yann voted C (unsure) with following explanation:
"As Thomas said, they can't go in as-is. It would be better to add
generic config options (_HAS_MMU, _USE_MMU et al.) first.
So I'd rather say:
    Vote: C, unsure: we do not want _these_ patches, but a better way
    to express such a configuration."

I think we are on the same page regarding the fact that more core work
is needed for this topic. However, my interpretation of category C was
that we'd ask input from the submitter to make a final decision. In
this case, I think we do not need such input: it is clear that work
needs to be done on the core infrastructure. At the same time, neither
A (accept) or B (reject) are good categories, so in fact we really
need a fourth category D (add to todo list).
This is what I did: add an entry to the todo list briefly describing
the problem [1], referring to the patches, and in the mean time keep
the patches around in patchwork as reminder. However, as these are not
patches that 'just' needs to be refreshed like the other patches
marked as 'delegated to pdp', I suggest to use another delegate, like
tpetazzoni to mark the difference. This doesn't mean that ThomasP
needs to do this work, to be clear.

[1] http://elinux.org/Buildroot#Core_Buildroot_infrastructure

>
>
> [RFC] uclibc: Don't build shared library if !HAVE_SHARED
> http://patchwork.ozlabs.org/patch/273175/
>
> Add pyside + shiboken packages
> http://patchwork.ozlabs.org/patch/275929/
>
> [v2,1/1] package: remove the trailing slash sign from $(PKG)_SITE variable
> http://patchwork.ozlabs.org/patch/276237/

Above three marked as 'delegated to pdp', they need to be refreshed and resent.

>
> [v2,1/1] u-boot: allow to pass a custom configuration file
> http://patchwork.ozlabs.org/patch/276286/

C, unsure, as per feedback of Yann. Let's see what the submitter says.

>
> [v3,01/11] udev: explicitly include pthreads
> http://patchwork.ozlabs.org/patch/278298
>
> [v3,02/11] sunxi-mali: add explicit pthread/dl/rt dependencies
> http://patchwork.ozlabs.org/patch/278295

For both the above:
C, unsure: there is some uncertainty regarding the exact cause of the
problem. This should be clarified first.

>
> [v3,05/11] sunxi-cedarx: bump to newer version, use armel2 binaries, add demo
> http://patchwork.ozlabs.org/patch/278299
>
> [v3,08/11] libpng12: new package
> http://patchwork.ozlabs.org/patch/278300
>
> [v3,09/11] libpng: ensure libpng12 is installed before libpng
> http://patchwork.ozlabs.org/patch/278301
>
> [v3,10/11] glmark2: new package
> http://patchwork.ozlabs.org/patch/278304
>
> [v3,11/11] mesa3d-demos: new package
> http://patchwork.ozlabs.org/patch/278305

For all the above: A (delegated to pdp).

>
>
> B. Patches to reject:
> ---------------------
>
> infra: display current task as title of the term window
> http://patchwork.ozlabs.org/patch/265214/
>
> [Reason: as stated in the patch discussion, there is a problem when
> interrupting the build. An alternative has been suggested: update the
> MESSAGEs with a progress indication instead. The patch submitter could
> send a new patch implementing this proposal if he is interested.]

B. Reject

>
>
> C. Unsure / need more investigation:
> ------------------------------------
>
> [RESEND] package/Makefile.in: Fix dependency for selecting uclinux as TARGET_OS
> http://patchwork.ozlabs.org/patch/277119/

C Unsure.

>
> libgcc erroneously built as armv5 for arm920t(armv4t)
> http://patchwork.ozlabs.org/patch/278212/

B Reject: d3539dd5: arch: pass cpu option instead of tune option on
ARM (feedback Yann)


I will try to notify the submitters of these patches soon...

Thanks for the feedback, especially Yann!

Best regards,
Thomas