Patchwork [v2] busybox: Upgrade to upstream 1.20.2

Removed CONFIG_LSOF for backwards compatibility.

Signed-off-by: Radu Moisan <radu.moisan@intel.com>
---
 .../B921600.patch                                  |    0
 .../busybox-appletlib-dependency.patch             |    0
 .../busybox-mkfs-minix-tests_bigendian.patch       |    0
 .../busybox-udhcpc-no_deconfig.patch               |   37 +++++++++-----------
 .../{busybox-1.19.4 => busybox-1.20.2}/defconfig   |    0
 .../fix-for-spurious-testsuite-failure.patch       |    0
 .../get_header_tar.patch                           |    0
 .../run-parts.in.usr-bin.patch                     |    0
 .../sys_resource.patch                             |    0
 .../watch.in.usr-bin.patch                         |    0
 .../wget_dl_dir_fix.patch                          |    0
 meta/recipes-core/busybox/busybox.inc              |    2 ++
 .../{busybox_1.19.4.bb => busybox_1.20.2.bb}       |    6 ++--
 13 files changed, 22 insertions(+), 23 deletions(-)
 rename meta/recipes-core/busybox/{busybox-1.19.4 => busybox-1.20.2}/B921600.patch (100%)
 rename meta/recipes-core/busybox/{busybox-1.19.4 => busybox-1.20.2}/busybox-appletlib-dependency.patch (100%)
 rename meta/recipes-core/busybox/{busybox-1.19.4 => busybox-1.20.2}/busybox-mkfs-minix-tests_bigendian.patch (100%)
 rename meta/recipes-core/busybox/{busybox-1.19.4 => busybox-1.20.2}/busybox-udhcpc-no_deconfig.patch (78%)
 rename meta/recipes-core/busybox/{busybox-1.19.4 => busybox-1.20.2}/defconfig (100%)
 rename meta/recipes-core/busybox/{busybox-1.19.4 => busybox-1.20.2}/fix-for-spurious-testsuite-failure.patch (100%)
 rename meta/recipes-core/busybox/{busybox-1.19.4 => busybox-1.20.2}/get_header_tar.patch (100%)
 rename meta/recipes-core/busybox/{busybox-1.19.4 => busybox-1.20.2}/run-parts.in.usr-bin.patch (100%)
 rename meta/recipes-core/busybox/{busybox-1.19.4 => busybox-1.20.2}/sys_resource.patch (100%)
 rename meta/recipes-core/busybox/{busybox-1.19.4 => busybox-1.20.2}/watch.in.usr-bin.patch (100%)
 rename meta/recipes-core/busybox/{busybox-1.19.4 => busybox-1.20.2}/wget_dl_dir_fix.patch (100%)
 rename meta/recipes-core/busybox/{busybox_1.19.4.bb => busybox_1.20.2.bb} (87%)

On Mon, 2012-08-20 at 10:46 +0300, Radu Moisan wrote:
> @@ -97,6 +97,8 @@ do_prepare_config () {
>  		< ${WORKDIR}/defconfig > ${S}/.config
>  	sed -i -e '/CONFIG_STATIC/d' .config
>  	echo "# CONFIG_STATIC is not set" >> .config
> +	sed -i -e '/CONFIG_LSOF/d' .config
> +	echo "# CONFIG_LSOF is not set" >> .config
>  	for i in 'CROSS' 'DISTRO FEATURES'; do echo "### $i"; done >> \
>  		${S}/.config
>  	sed -i -e '${configmangle}' ${S}/.config

Why is this desirable?

p.

On Monday 20 August 2012 09:18:17 Phil Blundell wrote:
> On Mon, 2012-08-20 at 10:46 +0300, Radu Moisan wrote:
> > @@ -97,6 +97,8 @@ do_prepare_config () {
> > 
> >  		< ${WORKDIR}/defconfig > ${S}/.config
> >  	
> >  	sed -i -e '/CONFIG_STATIC/d' .config
> >  	echo "# CONFIG_STATIC is not set" >> .config
> > 
> > +	sed -i -e '/CONFIG_LSOF/d' .config
> > +	echo "# CONFIG_LSOF is not set" >> .config
> > 
> >  	for i in 'CROSS' 'DISTRO FEATURES'; do echo "### $i"; done >> \
> >  	
> >  		${S}/.config
> >  	
> >  	sed -i -e '${configmangle}' ${S}/.config
> 
> Why is this desirable?

Well, the more appropriate question would be: could we not just update the 
defconfig and then make that change to it directly?

(In case it isn't clear - lsof is being disabled because it was not enabled in 
the previous 1.19.4 version.)

Cheers,
Paul

On Mon, 2012-08-20 at 09:25 +0100, Paul Eggleton wrote:
> On Monday 20 August 2012 09:18:17 Phil Blundell wrote:
> > On Mon, 2012-08-20 at 10:46 +0300, Radu Moisan wrote:
> > > @@ -97,6 +97,8 @@ do_prepare_config () {
> > > 
> > >  		< ${WORKDIR}/defconfig > ${S}/.config
> > >  	
> > >  	sed -i -e '/CONFIG_STATIC/d' .config
> > >  	echo "# CONFIG_STATIC is not set" >> .config
> > > 
> > > +	sed -i -e '/CONFIG_LSOF/d' .config
> > > +	echo "# CONFIG_LSOF is not set" >> .config
> > > 
> > >  	for i in 'CROSS' 'DISTRO FEATURES'; do echo "### $i"; done >> \
> > >  	
> > >  		${S}/.config
> > >  	
> > >  	sed -i -e '${configmangle}' ${S}/.config
> > 
> > Why is this desirable?
> 
> Well, the more appropriate question would be: could we not just update the 
> defconfig and then make that change to it directly?
> 
> (In case it isn't clear - lsof is being disabled because it was not enabled in 
> the previous 1.19.4 version.)

Ah, I see.  In that case, yes, just updating the defconfig is the right
thing to do.  The patch above will, if I am understanding it correctly,
make it impossible (or at least quite hard) for any other layer to turn
CONFIG_LSOF back on.

p.

On Monday 20 August 2012 09:28:41 Phil Blundell wrote:
> On Mon, 2012-08-20 at 09:25 +0100, Paul Eggleton wrote:
> > On Monday 20 August 2012 09:18:17 Phil Blundell wrote:
> > > On Mon, 2012-08-20 at 10:46 +0300, Radu Moisan wrote:
> > > > @@ -97,6 +97,8 @@ do_prepare_config () {
> > > > 
> > > >  		< ${WORKDIR}/defconfig > ${S}/.config
> > > >  	
> > > >  	sed -i -e '/CONFIG_STATIC/d' .config
> > > >  	echo "# CONFIG_STATIC is not set" >> .config
> > > > 
> > > > +	sed -i -e '/CONFIG_LSOF/d' .config
> > > > +	echo "# CONFIG_LSOF is not set" >> .config
> > > > 
> > > >  	for i in 'CROSS' 'DISTRO FEATURES'; do echo "### $i"; done >> \
> > > >  	
> > > >  		${S}/.config
> > > >  	
> > > >  	sed -i -e '${configmangle}' ${S}/.config
> > > 
> > > Why is this desirable?
> > 
> > Well, the more appropriate question would be: could we not just update the
> > defconfig and then make that change to it directly?
> > 
> > (In case it isn't clear - lsof is being disabled because it was not
> > enabled in the previous 1.19.4 version.)
> 
> Ah, I see.  In that case, yes, just updating the defconfig is the right
> thing to do.  The patch above will, if I am understanding it correctly,
> make it impossible (or at least quite hard) for any other layer to turn
> CONFIG_LSOF back on.

Good point, that would be undesirable.

Cheers,
Paul

On 08/20/2012 11:31 AM, Paul Eggleton wrote:
> On Monday 20 August 2012 09:28:41 Phil Blundell wrote:
>> On Mon, 2012-08-20 at 09:25 +0100, Paul Eggleton wrote:
>>> On Monday 20 August 2012 09:18:17 Phil Blundell wrote:
>>>> On Mon, 2012-08-20 at 10:46 +0300, Radu Moisan wrote:
>>>>> @@ -97,6 +97,8 @@ do_prepare_config () {
>>>>>
>>>>>   		< ${WORKDIR}/defconfig > ${S}/.config
>>>>>   	
>>>>>   	sed -i -e '/CONFIG_STATIC/d' .config
>>>>>   	echo "# CONFIG_STATIC is not set" >> .config
>>>>>
>>>>> +	sed -i -e '/CONFIG_LSOF/d' .config
>>>>> +	echo "# CONFIG_LSOF is not set" >> .config
>>>>>
>>>>>   	for i in 'CROSS' 'DISTRO FEATURES'; do echo "### $i"; done >> \
>>>>>   	
>>>>>   		${S}/.config
>>>>>   	
>>>>>   	sed -i -e '${configmangle}' ${S}/.config
>>>> Why is this desirable?
>>> Well, the more appropriate question would be: could we not just update the
>>> defconfig and then make that change to it directly?
>>>
>>> (In case it isn't clear - lsof is being disabled because it was not
>>> enabled in the previous 1.19.4 version.)
>> Ah, I see.  In that case, yes, just updating the defconfig is the right
>> thing to do.  The patch above will, if I am understanding it correctly,
>> make it impossible (or at least quite hard) for any other layer to turn
>> CONFIG_LSOF back on.
> Good point, that would be undesirable.
Any suggestions on how to do that?

thanks,
radu

On Monday 20 August 2012 12:28:24 Radu Moisan wrote:
> On 08/20/2012 11:31 AM, Paul Eggleton wrote:
> > On Monday 20 August 2012 09:28:41 Phil Blundell wrote:
> >> On Mon, 2012-08-20 at 09:25 +0100, Paul Eggleton wrote:
> >>> On Monday 20 August 2012 09:18:17 Phil Blundell wrote:
> >>>> On Mon, 2012-08-20 at 10:46 +0300, Radu Moisan wrote:
> >>>>> @@ -97,6 +97,8 @@ do_prepare_config () {
> >>>>> 
> >>>>>   		< ${WORKDIR}/defconfig > ${S}/.config
> >>>>>   	
> >>>>>   	sed -i -e '/CONFIG_STATIC/d' .config
> >>>>>   	echo "# CONFIG_STATIC is not set" >> .config
> >>>>> 
> >>>>> +	sed -i -e '/CONFIG_LSOF/d' .config
> >>>>> +	echo "# CONFIG_LSOF is not set" >> .config
> >>>>> 
> >>>>>   	for i in 'CROSS' 'DISTRO FEATURES'; do echo "### $i"; done >> \
> >>>>>   	
> >>>>>   		${S}/.config
> >>>>>   	
> >>>>>   	sed -i -e '${configmangle}' ${S}/.config
> >>>> 
> >>>> Why is this desirable?
> >>> 
> >>> Well, the more appropriate question would be: could we not just update
> >>> the
> >>> defconfig and then make that change to it directly?
> >>> 
> >>> (In case it isn't clear - lsof is being disabled because it was not
> >>> enabled in the previous 1.19.4 version.)
> >> 
> >> Ah, I see.  In that case, yes, just updating the defconfig is the right
> >> thing to do.  The patch above will, if I am understanding it correctly,
> >> make it impossible (or at least quite hard) for any other layer to turn
> >> CONFIG_LSOF back on.
> > 
> > Good point, that would be undesirable.
> 
> Any suggestions on how to do that?

Build the new version of busybox once (actually, just running -c configure 
ought to be enough), copy the generated .config over the top of defconfig in the 
metadata, then edit it as desired.

Cheers,
Paul

On Mon, 2012-08-20 at 12:28 +0300, Radu Moisan wrote:
> Any suggestions on how to do that?

"vi defconfig", then add 

# CONFIG_LSOF is not set

at some appropriate place.

Alternatively, bitbake -c menuconfig busybox, make sure lsof is
disabled, then copy the resulting .config file back into defconfig.

p.

* Phil Blundell <philb@gnu.org> [120820 11:33]:

> On Mon, 2012-08-20 at 12:28 +0300, Radu Moisan wrote:
> > Any suggestions on how to do that?

> "vi defconfig", then add 

> # CONFIG_LSOF is not set

> at some appropriate place.

> Alternatively, bitbake -c menuconfig busybox, make sure lsof is
> disabled, then copy the resulting .config file back into defconfig.

And as a last step (regardless of which way you're modifying the
defconfig) use git diff to check that you're changing things correclty,
i.e. not enabling more functionality than before (unless there's a good
reason for this).

Apart from that, I prefer that we copy the defconfig from a build, as
busybox sometimes likes to re-order the configuration options between
releases. I just happen to prefer to easily be able to compare my built
config with the supplied defconfig, with the minimum of changes.

Cheers,
Anders