[Buildroot] Patchwork oldest patches cleanup #2 (deadline November 17)

[Buildroot] Patchwork oldest patches cleanup #2 (deadline November 17)

[Thomas De Schampheleire]

All,

For those who haven't seen the first patchwork cleanup session, here is
a quick recap: every session we'll be posting the list of the 10 oldest
patches, with the original patch contributors in copy. During two weeks,
we have the opportunity to discuss the patch, whether it is still
necessary or not, how it should be changed to be merged.

In particular, I'm interested in knowing if the original contributor is
still interested by the patch, or if someone else is interested in
adopting the patch and sending an updated version, or if the patch no
longer makes sense due to other changes made in Buildroot.

All patches that have not received any comment or attention before the
deadline will be removed from patchwork. This is aggressive, but we have
many 'dead' patches sitting in patchwork, and this cannot work.

For this second session, I set the deadline to November 17. Below are the
10 oldest patches (obtained with a slightly modified version of pwclient):
[ pwclient list -s New -n 10 ]


Add support for the HABA-KNX-LITE
Gregory Hermant <gregory.hermant@calao-systems.com>
http://patchwork.ozlabs.org/patch/180241

upx: high-performance executable packer with in-place decompression support
Stefan Fr?berg <stefan.froberg@petroprogram.com>
http://patchwork.ozlabs.org/patch/180285

Add custom boards support for Atmel SAM-BA software
Gregory Hermant <gregory.hermant@calao-systems.com>
http://patchwork.ozlabs.org/patch/180668

linux: add default defconfig
Arnout Vandecappelle <arnout@mind.be>
http://patchwork.ozlabs.org/patch/181185

[1/4] If linux-pam is built, enable dbm functionality in Berkeley DB
Dimitry Golubovsky <golubovsky@gmail.com>
http://patchwork.ozlabs.org/patch/182497

[2/4] Make Berkeley DB a dependency of linux-pam and make sure it is selected
Dimitry Golubovsky <golubovsky@gmail.com>
http://patchwork.ozlabs.org/patch/182498

[3/4] Provide PAM default configuration files when building linux-pam package
Dimitry Golubovsky <golubovsky@gmail.com>
http://patchwork.ozlabs.org/patch/182499

[4/4] PAM support in Busybox if linux-pam is built
Dimitry Golubovsky <golubovsky@gmail.com>
http://patchwork.ozlabs.org/patch/182500

Fixing linux-pam build failures
Stefan Fr?berg <stefan.froberg@petroprogram.com>
http://patchwork.ozlabs.org/patch/182537

[RFC] patches-from-git.sh: new support script
Arnout Vandecappelle <arnout@mind.be>
http://patchwork.ozlabs.org/patch/182856


Thanks all for your input,

Best regards,
Thomas

[Buildroot] Patchwork oldest patches cleanup #2 (deadline November 17)

[Arnout Vandecappelle]

On 01/11/13 16:09, Thomas De Schampheleire wrote:
[snip]
> linux: add default defconfig
> Arnout Vandecappelle <arnout@mind.be>
> http://patchwork.ozlabs.org/patch/181185

  This one didn't receive positive feedback, so I guess it's rejected. 
Short recap: it allows you to build the kernel with the architecture's 
default defconfig, which is typically a bloaty configuration that 
supports many boards (if an appropriate device tree is present). IIRC the 
feedback was that this wasn't usually appropriate for buildroot use cases.


[snip]
> [RFC] patches-from-git.sh: new support script
> Arnout Vandecappelle <arnout@mind.be>
> http://patchwork.ozlabs.org/patch/182856

  This one can definitely be rejected, since it was RFC and didn't 
receive comments AFAICR.

  Note: I'd to the rejects myself but as usual I'm reading this without 
internet access.

  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 oldest patches cleanup #2 (deadline November 17)

[Thomas De Schampheleire]

Hi Arnout,

Thanks for your feedback.

On Mon, Nov 4, 2013 at 8:03 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 01/11/13 16:09, Thomas De Schampheleire wrote:
> [snip]
>
>> linux: add default defconfig
>> Arnout Vandecappelle <arnout@mind.be>
>> http://patchwork.ozlabs.org/patch/181185
>
>
>  This one didn't receive positive feedback, so I guess it's rejected. Short
> recap: it allows you to build the kernel with the architecture's default
> defconfig, which is typically a bloaty configuration that supports many
> boards (if an appropriate device tree is present). IIRC the feedback was
> that this wasn't usually appropriate for buildroot use cases.
>
>
> [snip]
>
>> [RFC] patches-from-git.sh: new support script
>> Arnout Vandecappelle <arnout@mind.be>
>> http://patchwork.ozlabs.org/patch/182856
>
>
>  This one can definitely be rejected, since it was RFC and didn't receive
> comments AFAICR.

But you're also no longer interested in that feature right? What I
mean is: it's not that there was no feedback at the time that you
couldn't get feedback now. If you still think the script is useful,
you could resubmit the patch to revive the discussion.

Best regards,
Thomas

[Buildroot] Patchwork oldest patches cleanup #2 (deadline November 17)

[Arnout Vandecappelle]

On 04/11/13 09:30, Thomas De Schampheleire wrote:
> Hi Arnout,
>
> Thanks for your feedback.
>
> On Mon, Nov 4, 2013 at 8:03 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>> On 01/11/13 16:09, Thomas De Schampheleire wrote:
[snip]
>>> [RFC] patches-from-git.sh: new support script
>>> Arnout Vandecappelle <arnout@mind.be>
>>> http://patchwork.ozlabs.org/patch/182856
>>
>>
>>   This one can definitely be rejected, since it was RFC and didn't receive
>> comments AFAICR.
>
> But you're also no longer interested in that feature right? What I
> mean is: it's not that there was no feedback at the time that you
> couldn't get feedback now. If you still think the script is useful,
> you could resubmit the patch to revive the discussion.

  The script as such wasn't really useful - it should be integrated in a 
workflow to actually make the patches. We actually briefly discussed a 
possible workflow during the BR developer meeting, and this script could 
be part of that. But I'll just resubmit when the time is right.

  So yes, rejecting it is OK. I've just updated patchwork now.

  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 oldest patches cleanup #2 (deadline November 17)

[Thomas De Schampheleire]

Hi Arnout,

On Mon, Nov 4, 2013 at 8:03 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
> On 01/11/13 16:09, Thomas De Schampheleire wrote:
> [snip]
>
>> linux: add default defconfig
>> Arnout Vandecappelle <arnout@mind.be>
>> http://patchwork.ozlabs.org/patch/181185
>
>
>  This one didn't receive positive feedback, so I guess it's rejected. Short
> recap: it allows you to build the kernel with the architecture's default
> defconfig, which is typically a bloaty configuration that supports many
> boards (if an appropriate device tree is present). IIRC the feedback was
> that this wasn't usually appropriate for buildroot use cases.

One annoyance I have is that if you want to quickly test something
(for example when reviewing patches) and you enable a Linux kernel,
you also have to specify a defconfig. Your patch would fix that use
case. In such a test case, I typically don't care what is included in
the kernel, because I would only compile-test.
But I can also follow ThomasP's comments on that patch.
There was a suggestion in case of x86 though, which in many cases
would be ok for me in the above scenario. I wouldn't be against having
just that...

Best regards,
Thomas

[Buildroot] Patchwork oldest patches cleanup #2 (deadline November 17)

[Arnout Vandecappelle]

On 04/11/13 12:17, Thomas De Schampheleire wrote:
> Hi Arnout,
>
> On Mon, Nov 4, 2013 at 8:03 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>> On 01/11/13 16:09, Thomas De Schampheleire wrote:
>> [snip]
>>
>>> linux: add default defconfig
>>> Arnout Vandecappelle <arnout@mind.be>
>>> http://patchwork.ozlabs.org/patch/181185
>>
>>
>>   This one didn't receive positive feedback, so I guess it's rejected. Short
>> recap: it allows you to build the kernel with the architecture's default
>> defconfig, which is typically a bloaty configuration that supports many
>> boards (if an appropriate device tree is present). IIRC the feedback was
>> that this wasn't usually appropriate for buildroot use cases.
>
> One annoyance I have is that if you want to quickly test something
> (for example when reviewing patches) and you enable a Linux kernel,
> you also have to specify a defconfig. Your patch would fix that use
> case. In such a test case, I typically don't care what is included in
> the kernel, because I would only compile-test.

  I completely agree, that was the reason that I created the patch in the 
first place.

  Unfortunately, the x86_defconfig is _huge_. And as mentioned by 
ThomasP, the other architecture's defconfigs aren't worth much. So I 
don't think this patch is really valuable after all.

  Regards,
  Arnout

> But I can also follow ThomasP's comments on that patch.
> There was a suggestion in case of x86 though, which in many cases
> would be ok for me in the above scenario. I wouldn't be against having
> just that...
>
> Best regards,
> Thomas
>
>


-- 
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 oldest patches cleanup #2 (deadline November 17)

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Mon, 04 Nov 2013 22:40:10 +0100, Arnout Vandecappelle wrote:

>   I completely agree, that was the reason that I created the patch in
> the first place.
> 
>   Unfortunately, the x86_defconfig is _huge_. And as mentioned by 
> ThomasP, the other architecture's defconfigs aren't worth much. So I 
> don't think this patch is really valuable after all.

I agree. For anyone sane, x86_defconfig is basically unusable due to
the enormous number of options that it enables.

And for other architectures, a default defconfig doesn't make much
sense, since there usually isn't any "sane" default. I very much prefer
users to be asked loudly to provide a proper defconfig rather than
having Buildroot pick the kernel default one, and then have users
wonder why the kernel doesn't boot on their platform.

Best regards,

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

[Buildroot] Patchwork oldest patches cleanup #2 (deadline November 17)

[Thomas De Schampheleire]

On Tue, Nov 5, 2013 at 12:07 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Arnout Vandecappelle,
>
> On Mon, 04 Nov 2013 22:40:10 +0100, Arnout Vandecappelle wrote:
>
>>   I completely agree, that was the reason that I created the patch in
>> the first place.
>>
>>   Unfortunately, the x86_defconfig is _huge_. And as mentioned by
>> ThomasP, the other architecture's defconfigs aren't worth much. So I
>> don't think this patch is really valuable after all.
>
> I agree. For anyone sane, x86_defconfig is basically unusable due to
> the enormous number of options that it enables.
>
> And for other architectures, a default defconfig doesn't make much
> sense, since there usually isn't any "sane" default. I very much prefer
> users to be asked loudly to provide a proper defconfig rather than
> having Buildroot pick the kernel default one, and then have users
> wonder why the kernel doesn't boot on their platform.
>

Ok, fair enough. I have marked the patch as rejected.

2 down, 8 to go...

[Buildroot] Patchwork oldest patches cleanup #2 (deadline November 17)

[Thomas De Schampheleire]

All,

On Fri, Nov 1, 2013 at 4:09 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> All,
>
> For those who haven't seen the first patchwork cleanup session, here is
> a quick recap: every session we'll be posting the list of the 10 oldest
> patches, with the original patch contributors in copy. During two weeks,
> we have the opportunity to discuss the patch, whether it is still
> necessary or not, how it should be changed to be merged.
>
> In particular, I'm interested in knowing if the original contributor is
> still interested by the patch, or if someone else is interested in
> adopting the patch and sending an updated version, or if the patch no
> longer makes sense due to other changes made in Buildroot.
>
> All patches that have not received any comment or attention before the
> deadline will be removed from patchwork. This is aggressive, but we have
> many 'dead' patches sitting in patchwork, and this cannot work.
>
> For this second session, I set the deadline to November 17. Below are the
> 10 oldest patches (obtained with a slightly modified version of pwclient):
> [ pwclient list -s New -n 10 ]
>

Time for an intermediate reminder. Following patches are still unanswered:

>
> Add support for the HABA-KNX-LITE
> Gregory Hermant <gregory.hermant@calao-systems.com>
> http://patchwork.ozlabs.org/patch/180241
>
> Add custom boards support for Atmel SAM-BA software
> Gregory Hermant <gregory.hermant@calao-systems.com>
> http://patchwork.ozlabs.org/patch/180668
>

Gregory: are these common boards used by other people than yourself?
If so, are you still interested in getting this support in buildroot?

> upx: high-performance executable packer with in-place decompression support
> Stefan Fr?berg <stefan.froberg@petroprogram.com>
> http://patchwork.ozlabs.org/patch/180285

Stefan: are you still interested in getting this package in mainline buildroot?

>
> [1/4] If linux-pam is built, enable dbm functionality in Berkeley DB
> Dimitry Golubovsky <golubovsky@gmail.com>
> http://patchwork.ozlabs.org/patch/182497
>
> [2/4] Make Berkeley DB a dependency of linux-pam and make sure it is selected
> Dimitry Golubovsky <golubovsky@gmail.com>
> http://patchwork.ozlabs.org/patch/182498
>
> [3/4] Provide PAM default configuration files when building linux-pam package
> Dimitry Golubovsky <golubovsky@gmail.com>
> http://patchwork.ozlabs.org/patch/182499
>
> [4/4] PAM support in Busybox if linux-pam is built
> Dimitry Golubovsky <golubovsky@gmail.com>
> http://patchwork.ozlabs.org/patch/182500
>
> Fixing linux-pam build failures
> Stefan Fr?berg <stefan.froberg@petroprogram.com>
> http://patchwork.ozlabs.org/patch/182537
>

All the above patches are related to PAM. If anyone is interested in
better linux-pam support in buildroot, I'd suggest to have a look at
the above patches. I don't personally need it, and I also don't know
how common PAM usage is in embedded systems.

Any input is appreciated...

Thanks,
Thomas

[Buildroot] Patchwork oldest patches cleanup #2 (deadline November 17)

[Ryan Barnett]

Thomas, All,

Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote on 11/10/2013 
10:18:55 AM:

[...]

> > [1/4] If linux-pam is built, enable dbm functionality in Berkeley DB
> > Dimitry Golubovsky <golubovsky@gmail.com>
> > http://patchwork.ozlabs.org/patch/182497
> >
> > [2/4] Make Berkeley DB a dependency of linux-pam and make sure it is 
selected
> > Dimitry Golubovsky <golubovsky@gmail.com>
> > http://patchwork.ozlabs.org/patch/182498
> >
> > [3/4] Provide PAM default configuration files when building linux-pam 
package
> > Dimitry Golubovsky <golubovsky@gmail.com>
> > http://patchwork.ozlabs.org/patch/182499
> >
> > [4/4] PAM support in Busybox if linux-pam is built
> > Dimitry Golubovsky <golubovsky@gmail.com>
> > http://patchwork.ozlabs.org/patch/182500
> >
> > Fixing linux-pam build failures
> > Stefan Fr?berg <stefan.froberg@petroprogram.com>
> > http://patchwork.ozlabs.org/patch/182537
> >
> 
> All the above patches are related to PAM. If anyone is interested in
> better linux-pam support in buildroot, I'd suggest to have a look at
> the above patches. I don't personally need it, and I also don't know
> how common PAM usage is in embedded systems.

linux-pam will be used more once SELinux (at least that is where we use 
it) related packages are merged in. However, I don't know how applicable 
these patches since I know the version has been bumped since these patches 
were submitted. I don't have time to investigate whether these patches 
still apply, so if you haven't heard anything back on them, I would say we 
just mark them deprecated.

Thanks,
-Ryan

[Buildroot] Patchwork oldest patches cleanup #2 (deadline November 17)

[Thomas De Schampheleire]

Hi Ryan,

On Mon, Nov 11, 2013 at 2:50 PM, Ryan Barnett
<rjbarnet@rockwellcollins.com> wrote:
> Thomas, All,
>
> Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote on 11/10/2013
> 10:18:55 AM:
>
> [...]
>
>> > [1/4] If linux-pam is built, enable dbm functionality in Berkeley DB
>> > Dimitry Golubovsky <golubovsky@gmail.com>
>> > http://patchwork.ozlabs.org/patch/182497
>> >
>> > [2/4] Make Berkeley DB a dependency of linux-pam and make sure it is
> selected
>> > Dimitry Golubovsky <golubovsky@gmail.com>
>> > http://patchwork.ozlabs.org/patch/182498
>> >
>> > [3/4] Provide PAM default configuration files when building linux-pam
> package
>> > Dimitry Golubovsky <golubovsky@gmail.com>
>> > http://patchwork.ozlabs.org/patch/182499
>> >
>> > [4/4] PAM support in Busybox if linux-pam is built
>> > Dimitry Golubovsky <golubovsky@gmail.com>
>> > http://patchwork.ozlabs.org/patch/182500
>> >
>> > Fixing linux-pam build failures
>> > Stefan Fr?berg <stefan.froberg@petroprogram.com>
>> > http://patchwork.ozlabs.org/patch/182537
>> >
>>
>> All the above patches are related to PAM. If anyone is interested in
>> better linux-pam support in buildroot, I'd suggest to have a look at
>> the above patches. I don't personally need it, and I also don't know
>> how common PAM usage is in embedded systems.
>
> linux-pam will be used more once SELinux (at least that is where we use
> it) related packages are merged in. However, I don't know how applicable
> these patches since I know the version has been bumped since these patches
> were submitted. I don't have time to investigate whether these patches
> still apply, so if you haven't heard anything back on them, I would say we
> just mark them deprecated.
>

Thanks for your feedback. Unless someone steps up by Sunday, I will
indeed mark them as Rejected in patchwork.

Best regards,
Thomas

[Buildroot] Patchwork oldest patches cleanup #2 (deadline November 17)

[Thomas De Schampheleire]

All,

On Fri, Nov 1, 2013 at 4:09 PM, Thomas De Schampheleire
<patrickdepinguin@gmail.com> wrote:
> All,
>
> For those who haven't seen the first patchwork cleanup session, here is
> a quick recap: every session we'll be posting the list of the 10 oldest
> patches, with the original patch contributors in copy. During two weeks,
> we have the opportunity to discuss the patch, whether it is still
> necessary or not, how it should be changed to be merged.
>
> In particular, I'm interested in knowing if the original contributor is
> still interested by the patch, or if someone else is interested in
> adopting the patch and sending an updated version, or if the patch no
> longer makes sense due to other changes made in Buildroot.
>
> All patches that have not received any comment or attention before the
> deadline will be removed from patchwork. This is aggressive, but we have
> many 'dead' patches sitting in patchwork, and this cannot work.
>
> For this second session, I set the deadline to November 17. Below are the
> 10 oldest patches (obtained with a slightly modified version of pwclient):
> [ pwclient list -s New -n 10 ]
>
>
> Add support for the HABA-KNX-LITE
> Gregory Hermant <gregory.hermant@calao-systems.com>
> http://patchwork.ozlabs.org/patch/180241
>
> upx: high-performance executable packer with in-place decompression support
> Stefan Fr?berg <stefan.froberg@petroprogram.com>
> http://patchwork.ozlabs.org/patch/180285
>
> Add custom boards support for Atmel SAM-BA software
> Gregory Hermant <gregory.hermant@calao-systems.com>
> http://patchwork.ozlabs.org/patch/180668
>
> linux: add default defconfig
> Arnout Vandecappelle <arnout@mind.be>
> http://patchwork.ozlabs.org/patch/181185
>
> [1/4] If linux-pam is built, enable dbm functionality in Berkeley DB
> Dimitry Golubovsky <golubovsky@gmail.com>
> http://patchwork.ozlabs.org/patch/182497
>
> [2/4] Make Berkeley DB a dependency of linux-pam and make sure it is selected
> Dimitry Golubovsky <golubovsky@gmail.com>
> http://patchwork.ozlabs.org/patch/182498
>
> [3/4] Provide PAM default configuration files when building linux-pam package
> Dimitry Golubovsky <golubovsky@gmail.com>
> http://patchwork.ozlabs.org/patch/182499
>
> [4/4] PAM support in Busybox if linux-pam is built
> Dimitry Golubovsky <golubovsky@gmail.com>
> http://patchwork.ozlabs.org/patch/182500
>
> Fixing linux-pam build failures
> Stefan Fr?berg <stefan.froberg@petroprogram.com>
> http://patchwork.ozlabs.org/patch/182537
>
> [RFC] patches-from-git.sh: new support script
> Arnout Vandecappelle <arnout@mind.be>
> http://patchwork.ozlabs.org/patch/182856
>

At the end of this session, all patches have been rejected. Feel free
to revive any of the patches later when you have time.

I will postpone the next patchwork cleanup session until after
buildroot-2013.11 is released, to make sure everyone is focused on
stabilization now. Please have a look at autobuild failures in the
mean time!

Thanks,
Thomas