[PATCH] busybox-1.21.1/defconfig: disable rfkill

[PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

This is necessary to get the build going, for instance with older Code Sourcery
compilers.

It is also disabled in upstream due to this very reason. The details can be
found on the following links:

http://comments.gmane.org/gmane.linux.busybox/30999
http://git.busybox.net/busybox/commit/?h=1_21_stable&id=1cd769a154b04f4b058beed482a5dd7192437cdc

[YOCTO #4932]

Signed-off-by: Laszlo Papp <lpapp@kde.org>
---
 meta/recipes-core/busybox/busybox-1.21.1/defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/busybox/busybox-1.21.1/defconfig b/meta/recipes-core/busybox/busybox-1.21.1/defconfig
index bdfdadf..e77a817 100644
--- a/meta/recipes-core/busybox/busybox-1.21.1/defconfig
+++ b/meta/recipes-core/busybox/busybox-1.21.1/defconfig
@@ -705,7 +705,7 @@ CONFIG_MICROCOM=y
 # CONFIG_MT is not set
 # CONFIG_RAIDAUTORUN is not set
 # CONFIG_READAHEAD is not set
-CONFIG_RFKILL=y
+# CONFIG_RFKILL is not set
 # CONFIG_RUNLEVEL is not set
 # CONFIG_RX is not set
 # CONFIG_SETSID is not set
-- 
1.8.3.4

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Fathi Boudra]

On 13 August 2013 12:52, Laszlo Papp <lpapp@kde.org> wrote:
> As we have already discussed that, it is not any clear at all without
> example. Yes, the end user does not really care about the internal
> implementation of the feature ....
>
> Please provide useful examples and tutorials how to use a feature especially
> when a user (and apparently others posting here) is such clueless.

We're using the feature in our layer:
https://git.linaro.org/gitweb?p=openembedded/meta-linaro.git;a=tree;f=meta-linaro/recipes-core/busybox

> Oh, by the way, and I have mentioned this in the bug report as well. We need
> proper documentation, examples, and tutorials; i.e. I am not ahead of the
> day when I first read this post. ;-)
>
>
> On Tue, Aug 13, 2013 at 10:48 AM, Burton, Ross <ross.burton@intel.com>
> wrote:
>>
>> On 13 August 2013 08:32, Laszlo Papp <lpapp@kde.org> wrote:
>> > So, everyone suggested PACKAGECONFIG in here on the mailing list except
>> > Khem
>> > whose reply I did not get.
>> >
>> > Yet, 4964 got closed by the "team". Could anyone please give a sane
>> > description why and what would block the end users other than fork?
>>
>> Quoting from comment 1 on 4964:
>>
>> """
>> Busybox is a rather complicated beast. PACKAGECONFIG is unfortunately
>> not sufficient to manage it's config system. It is very similar to the
>> Linux kernel config and we recently added configuration fragment
>> support to busybox from the kernel recipes:
>>
>> commit 56dc1720caa48344238d352c7b6e9b0f0d41aa54
>> Author: Chen Qi <Qi.Chen@windriver.com>
>> Date:   Tue Feb 5 14:36:40 2013 +0800
>>
>>     busybox: add config fragments
>>
>> This allows you to use the default config and include only the delta
>> in your layer's bbappend in the form of a config fragment added to the
>> SRC_URI.
>> """
>>
>> If this isn't sufficient or is buggy, then fixing this is preferred
>> (it works for the kernel, so should work for busybox).
>>
>> Ross
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
Fathi Boudra
Builds and Baselines Manager | Release Manager
Linaro.org | Open source software for ARM SoCs

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]

On Tue, Aug 13, 2013 at 11:35 AM, Jack Mitchell <ml@communistcode.co.uk>wrote:

> On 13/08/13 11:19, Laszlo Papp wrote:
> > I personally dislike top posting for a single entity in an email and I
> > think that is "nigh unbearable". ;-)
>
> If you also have a dislike for top-posting, then why top-post?!
>

That is a clear typo, as in: I personally dislike bottom posting for a
single entity.


> > More to the point, if there is no documentation, why is the bugreport
> > closed rather than forming it into a documentation bugreport?
>
> I am sure a bug-report for adding busybox config fragment documentation
> would be accepted.
>
>
> https://bugzilla.yoctoproject.org/buglist.cgi?product=General%20Docs&component=docs-general&resolution=---


No, I did mention documentation as well if there is a feature doing this,
but undocumented. That was apparently disregarded by the "team".


> > Also, I am still not sure we are on the same paper. You mean the python
> > script snippet will become optional? How will that mapping be done for
> > every possible options without adding explicit things to a feature set
> > like PACKAGECONFIG?
>
> I only answered the direct question in the email which is somewhere in
> the mess below, I couldn't bare to wade through the previous dredge.
> Hence, I have no idea with regards to any manual intervention with a
> python script. Going by the bug report, and the steps that I have seen,
> it should be automatic and as simple as dropping in a config fragment
> into the busybox recipe folder.
>

I have really no idea what you mean. You mean *every* defconfig entry is
mapped to a cfg, or what? This is still quite unclear to me how it is
supposed to work. Perhaps I should just wait for the "team" to realize this
in the bugreport, write documentation, and once that exists, I can
understand it. It is pretty hard to understand anything out of these
chunks, at least for me.

[-- Attachment #2: Type: text/html, Size: 2917 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Jack Mitchell]

On 13/08/13 11:19, Laszlo Papp wrote:
> I personally dislike top posting for a single entity in an email and I
> think that is "nigh unbearable". ;-)

If you also have a dislike for top-posting, then why top-post?!

> 
> More to the point, if there is no documentation, why is the bugreport
> closed rather than forming it into a documentation bugreport?

I am sure a bug-report for adding busybox config fragment documentation
would be accepted.

https://bugzilla.yoctoproject.org/buglist.cgi?product=General%20Docs&component=docs-general&resolution=---

> 
> Also, I am still not sure we are on the same paper. You mean the python
> script snippet will become optional? How will that mapping be done for
> every possible options without adding explicit things to a feature set
> like PACKAGECONFIG?

I only answered the direct question in the email which is somewhere in
the mess below, I couldn't bare to wade through the previous dredge.
Hence, I have no idea with regards to any manual intervention with a
python script. Going by the bug report, and the steps that I have seen,
it should be automatic and as simple as dropping in a config fragment
into the busybox recipe folder.

Cheers,

> 
> 
> On Tue, Aug 13, 2013 at 11:14 AM, Jack Mitchell <ml@communistcode.co.uk
> <mailto:ml@communistcode.co.uk>> wrote:
> 
>     On 13/08/13 10:52, Laszlo Papp wrote:
>     > As we have already discussed that, it is not any clear at all without
>     > example. Yes, the end user does not really care about the internal
>     > implementation of the feature ....
>     >
>     > Please provide useful examples and tutorials how to use a feature
>     > especially when a user (and apparently others posting here) is such
>     > clueless.
>     >
>     > Oh, by the way, and I have mentioned this in the bug report as
>     well. We
>     > need proper documentation, examples, and tutorials; i.e. I am not
>     ahead
>     > of the day when I first read this post. ;-)
>     >
>     >
>     > On Tue, Aug 13, 2013 at 10:48 AM, Burton, Ross
>     <ross.burton@intel.com <mailto:ross.burton@intel.com>
>     > <mailto:ross.burton@intel.com <mailto:ross.burton@intel.com>>> wrote:
>     >
>     >     On 13 August 2013 08:32, Laszlo Papp <lpapp@kde.org
>     <mailto:lpapp@kde.org>
>     >     <mailto:lpapp@kde.org <mailto:lpapp@kde.org>>> wrote:
>     >     > So, everyone suggested PACKAGECONFIG in here on the mailing list
>     >     except Khem
>     >     > whose reply I did not get.
>     >     >
>     >     > Yet, 4964 got closed by the "team". Could anyone please give
>     a sane
>     >     > description why and what would block the end users other
>     than fork?
>     >
>     >     Quoting from comment 1 on 4964:
>     >
>     >     """
>     >     Busybox is a rather complicated beast. PACKAGECONFIG is
>     unfortunately
>     >     not sufficient to manage it's config system. It is very
>     similar to the
>     >     Linux kernel config and we recently added configuration fragment
>     >     support to busybox from the kernel recipes:
>     >
>     >     commit 56dc1720caa48344238d352c7b6e9b0f0d41aa54
>     >     Author: Chen Qi <Qi.Chen@windriver.com
>     <mailto:Qi.Chen@windriver.com> <mailto:Qi.Chen@windriver.com
>     <mailto:Qi.Chen@windriver.com>>>
>     >     Date:   Tue Feb 5 14:36:40 2013 +0800
>     >
>     >         busybox: add config fragments
>     >
>     >     This allows you to use the default config and include only the
>     delta
>     >     in your layer's bbappend in the form of a config fragment
>     added to the
>     >     SRC_URI.
>     >     """
>     >
>     >     If this isn't sufficient or is buggy, then fixing this is
>     preferred
>     >     (it works for the kernel, so should work for busybox).
>     >
>     >     Ross
>     >
>     >
>     >
>     >
> 
>     1) The top posting in this thread is nigh unbearable, please bottom post
>     in order to keep the flow of conversation.
> 
>     2) The busybox config fragments was added in this cycle, which is
>     probably the reason for no official documentation yet.
> 
>     3) There is an example in the bug report where it was added
>     (https://bugzilla.yoctoproject.org/show_bug.cgi?id=3379) which you can
>     look at if you wish to be an early adopter and test this _new_ feature.
> 
>     4) For simplicity I have copied the explanation in below:
> 
>     > Steps:
>     > 1. Add a new cal.cfg file to meta/recipes-core/busybox/busybox-1.20.2/
>     > $ cat cal.cfg
>     > CONFIG_CAL=y
>     >
>     > 2. Run "bitbake busybox"
>     > Check the
>     build/tmp/work/armv5te-poky-linux-gnueabi/busybox/1.20.2-r5/busybox-1.20.2/.config
>     file.
>     > The CONFIG_CAL should be set to y.
>     >
>     > 3. Run "bitbake core-image-minimal"
>     > Boot up the image, the cal command should be exist.
>     > root@qemuarm:~# which cal
>     > /usr/bin/cal
>     > root@qemuarm:~# ls -l /usr/bin/cal
>     > lrwxrwxrwx    1 root     root            12 Mar  1 06:17
>     /usr/bin/cal -> /bin/busybox
>     > root@qemuarm:~#
> 
>     So, all you need to do is add CONFIG_RFKILL=n or whatever the config
>     name is and that should remove rfkill from the busybox command set.
> 
>     Regards,
> 
>     --
>       Jack Mitchell (jack@embed.me.uk <mailto:jack@embed.me.uk>)
>       Embedded Systems Engineer
>       Cambrideshire, UK
>       http://www.embed.me.uk
>     --
>     _______________________________________________
>     Openembedded-core mailing list
>     Openembedded-core@lists.openembedded.org
>     <mailto:Openembedded-core@lists.openembedded.org>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> 


-- 
  Jack Mitchell (jack@embed.me.uk)
  Embedded Systems Engineer
  Cambrideshire, UK
  http://www.embed.me.uk
--

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 4337 bytes --]

I personally dislike top posting for a single entity in an email and I
think that is "nigh unbearable". ;-)

More to the point, if there is no documentation, why is the bugreport
closed rather than forming it into a documentation bugreport?

Also, I am still not sure we are on the same paper. You mean the python
script snippet will become optional? How will that mapping be done for
every possible options without adding explicit things to a feature set like
PACKAGECONFIG?


On Tue, Aug 13, 2013 at 11:14 AM, Jack Mitchell <ml@communistcode.co.uk>wrote:

> On 13/08/13 10:52, Laszlo Papp wrote:
> > As we have already discussed that, it is not any clear at all without
> > example. Yes, the end user does not really care about the internal
> > implementation of the feature ....
> >
> > Please provide useful examples and tutorials how to use a feature
> > especially when a user (and apparently others posting here) is such
> > clueless.
> >
> > Oh, by the way, and I have mentioned this in the bug report as well. We
> > need proper documentation, examples, and tutorials; i.e. I am not ahead
> > of the day when I first read this post. ;-)
> >
> >
> > On Tue, Aug 13, 2013 at 10:48 AM, Burton, Ross <ross.burton@intel.com
> > <mailto:ross.burton@intel.com>> wrote:
> >
> >     On 13 August 2013 08:32, Laszlo Papp <lpapp@kde.org
> >     <mailto:lpapp@kde.org>> wrote:
> >     > So, everyone suggested PACKAGECONFIG in here on the mailing list
> >     except Khem
> >     > whose reply I did not get.
> >     >
> >     > Yet, 4964 got closed by the "team". Could anyone please give a sane
> >     > description why and what would block the end users other than fork?
> >
> >     Quoting from comment 1 on 4964:
> >
> >     """
> >     Busybox is a rather complicated beast. PACKAGECONFIG is unfortunately
> >     not sufficient to manage it's config system. It is very similar to
> the
> >     Linux kernel config and we recently added configuration fragment
> >     support to busybox from the kernel recipes:
> >
> >     commit 56dc1720caa48344238d352c7b6e9b0f0d41aa54
> >     Author: Chen Qi <Qi.Chen@windriver.com <mailto:Qi.Chen@windriver.com
> >>
> >     Date:   Tue Feb 5 14:36:40 2013 +0800
> >
> >         busybox: add config fragments
> >
> >     This allows you to use the default config and include only the delta
> >     in your layer's bbappend in the form of a config fragment added to
> the
> >     SRC_URI.
> >     """
> >
> >     If this isn't sufficient or is buggy, then fixing this is preferred
> >     (it works for the kernel, so should work for busybox).
> >
> >     Ross
> >
> >
> >
> >
>
> 1) The top posting in this thread is nigh unbearable, please bottom post
> in order to keep the flow of conversation.
>
> 2) The busybox config fragments was added in this cycle, which is
> probably the reason for no official documentation yet.
>
> 3) There is an example in the bug report where it was added
> (https://bugzilla.yoctoproject.org/show_bug.cgi?id=3379) which you can
> look at if you wish to be an early adopter and test this _new_ feature.
>
> 4) For simplicity I have copied the explanation in below:
>
> > Steps:
> > 1. Add a new cal.cfg file to meta/recipes-core/busybox/busybox-1.20.2/
> > $ cat cal.cfg
> > CONFIG_CAL=y
> >
> > 2. Run "bitbake busybox"
> > Check the
> build/tmp/work/armv5te-poky-linux-gnueabi/busybox/1.20.2-r5/busybox-1.20.2/.config
> file.
> > The CONFIG_CAL should be set to y.
> >
> > 3. Run "bitbake core-image-minimal"
> > Boot up the image, the cal command should be exist.
> > root@qemuarm:~# which cal
> > /usr/bin/cal
> > root@qemuarm:~# ls -l /usr/bin/cal
> > lrwxrwxrwx    1 root     root            12 Mar  1 06:17 /usr/bin/cal ->
> /bin/busybox
> > root@qemuarm:~#
>
> So, all you need to do is add CONFIG_RFKILL=n or whatever the config
> name is and that should remove rfkill from the busybox command set.
>
> Regards,
>
> --
>   Jack Mitchell (jack@embed.me.uk)
>   Embedded Systems Engineer
>   Cambrideshire, UK
>   http://www.embed.me.uk
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 5968 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Phil Blundell]

There's no magic involved in the python function: all it does is
generate a config fragment which is then passed to merge_config.sh along
with everything else.  If you supply your own fragment as Ross suggested
then it should override the values from the Python-generated one and
everything ought to work as you would expect.

p.

On Tue, 2013-08-13 at 11:00 +0100, Laszlo Papp wrote:
> Why are you referring to defconfig when I mentioned several times, the
> problem is the inc file and a python function; i.e. not the kernel,
> nor the busybox config?
> 
> 
> On Tue, Aug 13, 2013 at 10:58 AM, Burton, Ross <ross.burton@intel.com>
> wrote:
>         On 13 August 2013 10:52, Laszlo Papp <lpapp@kde.org> wrote:
>         > As we have already discussed that, it is not any clear at
>         all without
>         > example. Yes, the end user does not really care about the
>         internal
>         > implementation of the feature ....
>         >
>         > Please provide useful examples and tutorials how to use a
>         feature especially
>         > when a user (and apparently others posting here) is such
>         clueless.
>         
>         
>         Personally I've never touched busybox configuration so this is
>         untested.  However it claims to support configuration
>         fragments as
>         used by the kernel (as both busybox and the kernel use the
>         same
>         configuration system), so this section in the kernel
>         documentation
>         should be useful:
>         
>         http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#changing-the-configuration
>         
>         tl;dr: put a file such as myconfig.cfg in SRC_URI which
>         contains the
>         configuration variables you want set.
>         
>         Ross
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Jack Mitchell]

On 13/08/13 10:52, Laszlo Papp wrote:
> As we have already discussed that, it is not any clear at all without
> example. Yes, the end user does not really care about the internal
> implementation of the feature ....
> 
> Please provide useful examples and tutorials how to use a feature
> especially when a user (and apparently others posting here) is such
> clueless.
> 
> Oh, by the way, and I have mentioned this in the bug report as well. We
> need proper documentation, examples, and tutorials; i.e. I am not ahead
> of the day when I first read this post. ;-)
> 
> 
> On Tue, Aug 13, 2013 at 10:48 AM, Burton, Ross <ross.burton@intel.com
> <mailto:ross.burton@intel.com>> wrote:
> 
>     On 13 August 2013 08:32, Laszlo Papp <lpapp@kde.org
>     <mailto:lpapp@kde.org>> wrote:
>     > So, everyone suggested PACKAGECONFIG in here on the mailing list
>     except Khem
>     > whose reply I did not get.
>     >
>     > Yet, 4964 got closed by the "team". Could anyone please give a sane
>     > description why and what would block the end users other than fork?
> 
>     Quoting from comment 1 on 4964:
> 
>     """
>     Busybox is a rather complicated beast. PACKAGECONFIG is unfortunately
>     not sufficient to manage it's config system. It is very similar to the
>     Linux kernel config and we recently added configuration fragment
>     support to busybox from the kernel recipes:
> 
>     commit 56dc1720caa48344238d352c7b6e9b0f0d41aa54
>     Author: Chen Qi <Qi.Chen@windriver.com <mailto:Qi.Chen@windriver.com>>
>     Date:   Tue Feb 5 14:36:40 2013 +0800
> 
>         busybox: add config fragments
> 
>     This allows you to use the default config and include only the delta
>     in your layer's bbappend in the form of a config fragment added to the
>     SRC_URI.
>     """
> 
>     If this isn't sufficient or is buggy, then fixing this is preferred
>     (it works for the kernel, so should work for busybox).
> 
>     Ross
> 
> 
> 
> 

1) The top posting in this thread is nigh unbearable, please bottom post
in order to keep the flow of conversation.

2) The busybox config fragments was added in this cycle, which is
probably the reason for no official documentation yet.

3) There is an example in the bug report where it was added
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=3379) which you can
look at if you wish to be an early adopter and test this _new_ feature.

4) For simplicity I have copied the explanation in below:

> Steps:
> 1. Add a new cal.cfg file to meta/recipes-core/busybox/busybox-1.20.2/
> $ cat cal.cfg 
> CONFIG_CAL=y
> 
> 2. Run "bitbake busybox"
> Check the build/tmp/work/armv5te-poky-linux-gnueabi/busybox/1.20.2-r5/busybox-1.20.2/.config file.
> The CONFIG_CAL should be set to y.
> 
> 3. Run "bitbake core-image-minimal"
> Boot up the image, the cal command should be exist.
> root@qemuarm:~# which cal
> /usr/bin/cal
> root@qemuarm:~# ls -l /usr/bin/cal 
> lrwxrwxrwx    1 root     root            12 Mar  1 06:17 /usr/bin/cal -> /bin/busybox
> root@qemuarm:~#

So, all you need to do is add CONFIG_RFKILL=n or whatever the config
name is and that should remove rfkill from the busybox command set.

Regards,

-- 
  Jack Mitchell (jack@embed.me.uk)
  Embedded Systems Engineer
  Cambrideshire, UK
  http://www.embed.me.uk
--

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

Why are you referring to defconfig when I mentioned several times, the
problem is the inc file and a python function; i.e. not the kernel, nor the
busybox config?


On Tue, Aug 13, 2013 at 10:58 AM, Burton, Ross <ross.burton@intel.com>wrote:

> On 13 August 2013 10:52, Laszlo Papp <lpapp@kde.org> wrote:
> > As we have already discussed that, it is not any clear at all without
> > example. Yes, the end user does not really care about the internal
> > implementation of the feature ....
> >
> > Please provide useful examples and tutorials how to use a feature
> especially
> > when a user (and apparently others posting here) is such clueless.
>
> Personally I've never touched busybox configuration so this is
> untested.  However it claims to support configuration fragments as
> used by the kernel (as both busybox and the kernel use the same
> configuration system), so this section in the kernel documentation
> should be useful:
>
>
> http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#changing-the-configuration
>
> tl;dr: put a file such as myconfig.cfg in SRC_URI which contains the
> configuration variables you want set.
>
> Ross
>

[-- Attachment #2: Type: text/html, Size: 1794 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Burton, Ross]

On 13 August 2013 10:52, Laszlo Papp <lpapp@kde.org> wrote:
> As we have already discussed that, it is not any clear at all without
> example. Yes, the end user does not really care about the internal
> implementation of the feature ....
>
> Please provide useful examples and tutorials how to use a feature especially
> when a user (and apparently others posting here) is such clueless.

Personally I've never touched busybox configuration so this is
untested.  However it claims to support configuration fragments as
used by the kernel (as both busybox and the kernel use the same
configuration system), so this section in the kernel documentation
should be useful:

http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#changing-the-configuration

tl;dr: put a file such as myconfig.cfg in SRC_URI which contains the
configuration variables you want set.

Ross

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 2776 bytes --]

So, please show me how it works for this use case. Note this is note
defconfig, and has not much relevance to the kernel which is apparently
mentioned for some reason.

diff --git a/meta/recipes-core/busybox/busybox.inc
b/meta/recipes-core/busybox/busybox.inc
index acd2bfb..0e84f4c 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -66,8 +66,6 @@ def features_to_busybox_settings(d):
        busybox_cfg('nls',  distro_features, 'CONFIG_LOCALE_SUPPORT', cnf,
rem)
        busybox_cfg('ipv4', distro_features,
'CONFIG_FEATURE_IFUPDOWN_IPV4', cnf, rem)
        busybox_cfg('ipv6', distro_features,
'CONFIG_FEATURE_IFUPDOWN_IPV6', cnf, rem)
-       busybox_cfg('wifi', distro_features, 'CONFIG_RFKILL', cnf, rem)
-       busybox_cfg('bluetooth', distro_features, 'CONFIG_RFKILL', cnf, rem)
        return "\n".join(cnf), "\n".join(rem)



On Tue, Aug 13, 2013 at 10:52 AM, Laszlo Papp <lpapp@kde.org> wrote:

> As we have already discussed that, it is not any clear at all without
> example. Yes, the end user does not really care about the internal
> implementation of the feature ....
>
> Please provide useful examples and tutorials how to use a feature
> especially when a user (and apparently others posting here) is such
> clueless.
>
> Oh, by the way, and I have mentioned this in the bug report as well. We
> need proper documentation, examples, and tutorials; i.e. I am not ahead of
> the day when I first read this post. ;-)
>
>
> On Tue, Aug 13, 2013 at 10:48 AM, Burton, Ross <ross.burton@intel.com>wrote:
>
>> On 13 August 2013 08:32, Laszlo Papp <lpapp@kde.org> wrote:
>> > So, everyone suggested PACKAGECONFIG in here on the mailing list except
>> Khem
>> > whose reply I did not get.
>> >
>> > Yet, 4964 got closed by the "team". Could anyone please give a sane
>> > description why and what would block the end users other than fork?
>>
>> Quoting from comment 1 on 4964:
>>
>> """
>> Busybox is a rather complicated beast. PACKAGECONFIG is unfortunately
>> not sufficient to manage it's config system. It is very similar to the
>> Linux kernel config and we recently added configuration fragment
>> support to busybox from the kernel recipes:
>>
>> commit 56dc1720caa48344238d352c7b6e9b0f0d41aa54
>> Author: Chen Qi <Qi.Chen@windriver.com>
>> Date:   Tue Feb 5 14:36:40 2013 +0800
>>
>>     busybox: add config fragments
>>
>> This allows you to use the default config and include only the delta
>> in your layer's bbappend in the form of a config fragment added to the
>> SRC_URI.
>> """
>>
>> If this isn't sufficient or is buggy, then fixing this is preferred
>> (it works for the kernel, so should work for busybox).
>>
>> Ross
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3935 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]

As we have already discussed that, it is not any clear at all without
example. Yes, the end user does not really care about the internal
implementation of the feature ....

Please provide useful examples and tutorials how to use a feature
especially when a user (and apparently others posting here) is such
clueless.

Oh, by the way, and I have mentioned this in the bug report as well. We
need proper documentation, examples, and tutorials; i.e. I am not ahead of
the day when I first read this post. ;-)


On Tue, Aug 13, 2013 at 10:48 AM, Burton, Ross <ross.burton@intel.com>wrote:

> On 13 August 2013 08:32, Laszlo Papp <lpapp@kde.org> wrote:
> > So, everyone suggested PACKAGECONFIG in here on the mailing list except
> Khem
> > whose reply I did not get.
> >
> > Yet, 4964 got closed by the "team". Could anyone please give a sane
> > description why and what would block the end users other than fork?
>
> Quoting from comment 1 on 4964:
>
> """
> Busybox is a rather complicated beast. PACKAGECONFIG is unfortunately
> not sufficient to manage it's config system. It is very similar to the
> Linux kernel config and we recently added configuration fragment
> support to busybox from the kernel recipes:
>
> commit 56dc1720caa48344238d352c7b6e9b0f0d41aa54
> Author: Chen Qi <Qi.Chen@windriver.com>
> Date:   Tue Feb 5 14:36:40 2013 +0800
>
>     busybox: add config fragments
>
> This allows you to use the default config and include only the delta
> in your layer's bbappend in the form of a config fragment added to the
> SRC_URI.
> """
>
> If this isn't sufficient or is buggy, then fixing this is preferred
> (it works for the kernel, so should work for busybox).
>
> Ross
>

[-- Attachment #2: Type: text/html, Size: 2370 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Burton, Ross]

On 13 August 2013 08:32, Laszlo Papp <lpapp@kde.org> wrote:
> So, everyone suggested PACKAGECONFIG in here on the mailing list except Khem
> whose reply I did not get.
>
> Yet, 4964 got closed by the "team". Could anyone please give a sane
> description why and what would block the end users other than fork?

Quoting from comment 1 on 4964:

"""
Busybox is a rather complicated beast. PACKAGECONFIG is unfortunately
not sufficient to manage it's config system. It is very similar to the
Linux kernel config and we recently added configuration fragment
support to busybox from the kernel recipes:

commit 56dc1720caa48344238d352c7b6e9b0f0d41aa54
Author: Chen Qi <Qi.Chen@windriver.com>
Date:   Tue Feb 5 14:36:40 2013 +0800

    busybox: add config fragments

This allows you to use the default config and include only the delta
in your layer's bbappend in the form of a config fragment added to the
SRC_URI.
"""

If this isn't sufficient or is buggy, then fixing this is preferred
(it works for the kernel, so should work for busybox).

Ross

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

On Tue, Aug 13, 2013 at 8:32 AM, Laszlo Papp <lpapp@kde.org> wrote:

> So, everyone suggested PACKAGECONFIG in here on the mailing list except
> Khem whose reply I did not get.
>
> Yet, 4964 got closed by the "team". Could anyone please give a sane
> description why and what would block the end users other than fork?
>

... what would _un_block the end users ...

[-- Attachment #2: Type: text/html, Size: 733 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 3236 bytes --]

So, everyone suggested PACKAGECONFIG in here on the mailing list except
Khem whose reply I did not get.

Yet, 4964 got closed by the "team". Could anyone please give a sane
description why and what would block the end users other than fork?


On Tue, Aug 6, 2013 at 8:36 AM, Laszlo Papp <lpapp@kde.org> wrote:

> What do you mean?
>
>
> On Wed, Jul 31, 2013 at 11:36 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
>>
>> On Jul 29, 2013, at 12:16 AM, Laszlo Papp <lpapp@kde.org> wrote:
>>
>> > This is necessary to get the build going, for instance with older Code
>> Sourcery
>> > compilers.
>> >
>> > It is also disabled in upstream due to this very reason. The details
>> can be
>> > found on the following links:
>> >
>> > http://comments.gmane.org/gmane.linux.busybox/30999
>> >
>> http://git.busybox.net/busybox/commit/?h=1_21_stable&id=1cd769a154b04f4b058beed482a5dd7192437cdc
>> >
>> > [YOCTO #4932]
>>
>> while we use relatively newer toolchain and kernel headers as default.
>> this patch is not as appealing
>> to me. However since busy box now uses same config fragment management
>> infra like linux-yocto you could
>> convert this into a config fragment and then not use it by default. This
>> patch as such will be a regression
>> for normal users.
>>
>> >
>> > Signed-off-by: Laszlo Papp <lpapp@kde.org>
>> > ---
>> > meta/recipes-core/busybox/busybox-1.21.1/defconfig | 2 +-
>> > meta/recipes-core/busybox/busybox.inc              | 2 --
>> > 2 files changed, 1 insertion(+), 3 deletions(-)
>> >
>> > diff --git a/meta/recipes-core/busybox/busybox-1.21.1/defconfig
>> b/meta/recipes-core/busybox/busybox-1.21.1/defconfig
>> > index bdfdadf..e77a817 100644
>> > --- a/meta/recipes-core/busybox/busybox-1.21.1/defconfig
>> > +++ b/meta/recipes-core/busybox/busybox-1.21.1/defconfig
>> > @@ -705,7 +705,7 @@ CONFIG_MICROCOM=y
>> > # CONFIG_MT is not set
>> > # CONFIG_RAIDAUTORUN is not set
>> > # CONFIG_READAHEAD is not set
>> > -CONFIG_RFKILL=y
>> > +# CONFIG_RFKILL is not set
>> > # CONFIG_RUNLEVEL is not set
>> > # CONFIG_RX is not set
>> > # CONFIG_SETSID is not set
>> > diff --git a/meta/recipes-core/busybox/busybox.inc
>> b/meta/recipes-core/busybox/busybox.inc
>> > index acd2bfb..0e84f4c 100644
>> > --- a/meta/recipes-core/busybox/busybox.inc
>> > +++ b/meta/recipes-core/busybox/busybox.inc
>> > @@ -66,8 +66,6 @@ def features_to_busybox_settings(d):
>> >       busybox_cfg('nls',  distro_features, 'CONFIG_LOCALE_SUPPORT',
>> cnf, rem)
>> >       busybox_cfg('ipv4', distro_features,
>> 'CONFIG_FEATURE_IFUPDOWN_IPV4', cnf, rem)
>> >       busybox_cfg('ipv6', distro_features,
>> 'CONFIG_FEATURE_IFUPDOWN_IPV6', cnf, rem)
>> > -     busybox_cfg('wifi', distro_features, 'CONFIG_RFKILL', cnf, rem)
>> > -     busybox_cfg('bluetooth', distro_features, 'CONFIG_RFKILL', cnf,
>> rem)
>> >       return "\n".join(cnf), "\n".join(rem)
>> >
>> > # X, Y = ${@features_to_uclibc_settings(d)}
>> > --
>> > 1.8.3.4
>> >
>> > _______________________________________________
>> > Openembedded-core mailing list
>> > Openembedded-core@lists.openembedded.org
>> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4715 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Khem Raj]

On Jul 29, 2013, at 12:16 AM, Laszlo Papp <lpapp@kde.org> wrote:

> This is necessary to get the build going, for instance with older Code Sourcery
> compilers.
> 
> It is also disabled in upstream due to this very reason. The details can be
> found on the following links:
> 
> http://comments.gmane.org/gmane.linux.busybox/30999
> http://git.busybox.net/busybox/commit/?h=1_21_stable&id=1cd769a154b04f4b058beed482a5dd7192437cdc
> 
> [YOCTO #4932]

while we use relatively newer toolchain and kernel headers as default. this patch is not as appealing
to me. However since busy box now uses same config fragment management infra like linux-yocto you could
convert this into a config fragment and then not use it by default. This patch as such will be a regression
for normal users.

> 
> Signed-off-by: Laszlo Papp <lpapp@kde.org>
> ---
> meta/recipes-core/busybox/busybox-1.21.1/defconfig | 2 +-
> meta/recipes-core/busybox/busybox.inc              | 2 --
> 2 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-core/busybox/busybox-1.21.1/defconfig b/meta/recipes-core/busybox/busybox-1.21.1/defconfig
> index bdfdadf..e77a817 100644
> --- a/meta/recipes-core/busybox/busybox-1.21.1/defconfig
> +++ b/meta/recipes-core/busybox/busybox-1.21.1/defconfig
> @@ -705,7 +705,7 @@ CONFIG_MICROCOM=y
> # CONFIG_MT is not set
> # CONFIG_RAIDAUTORUN is not set
> # CONFIG_READAHEAD is not set
> -CONFIG_RFKILL=y
> +# CONFIG_RFKILL is not set
> # CONFIG_RUNLEVEL is not set
> # CONFIG_RX is not set
> # CONFIG_SETSID is not set
> diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
> index acd2bfb..0e84f4c 100644
> --- a/meta/recipes-core/busybox/busybox.inc
> +++ b/meta/recipes-core/busybox/busybox.inc
> @@ -66,8 +66,6 @@ def features_to_busybox_settings(d):
> 	busybox_cfg('nls',  distro_features, 'CONFIG_LOCALE_SUPPORT', cnf, rem)
> 	busybox_cfg('ipv4', distro_features, 'CONFIG_FEATURE_IFUPDOWN_IPV4', cnf, rem)
> 	busybox_cfg('ipv6', distro_features, 'CONFIG_FEATURE_IFUPDOWN_IPV6', cnf, rem)
> -	busybox_cfg('wifi', distro_features, 'CONFIG_RFKILL', cnf, rem)
> -	busybox_cfg('bluetooth', distro_features, 'CONFIG_RFKILL', cnf, rem)
> 	return "\n".join(cnf), "\n".join(rem)
> 
> # X, Y = ${@features_to_uclibc_settings(d)}
> -- 
> 1.8.3.4
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]

As you may have already realized, it is not a simple change to make
PACKAGECONFIG for this case to work. Here is the feature request, but it is
just a future stuff. I do not know any simple solution at hand how to
unbreak my still broken busybox in dylan and master ahead without a LOT of
work.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=4964


On Tue, Jul 30, 2013 at 5:21 PM, Burton, Ross <ross.burton@intel.com> wrote:

> On 30 July 2013 17:10, Phil Blundell <pb@pbcl.net> wrote:
> > On Tue, 2013-07-30 at 16:55 +0100, Laszlo Papp wrote:
> >
> >> At any rate, can someone provide a helper change from the past for
> >> PACKAGEGROUP like changes?
> >
> > Do you mean PACKAGECONFIG?  If so, just run "git log" in your oe-core
> > tree and search for PACKAGECONFIG.
>
> From experience I know that learning by example isn't always obvious
> for PACKAGECONFIG, but the manual does explain it quite well:
>
>
> http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-PACKAGECONFIG
>
> Ross
>

[-- Attachment #2: Type: text/html, Size: 1772 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Burton, Ross]

On 30 July 2013 17:10, Phil Blundell <pb@pbcl.net> wrote:
> On Tue, 2013-07-30 at 16:55 +0100, Laszlo Papp wrote:
>
>> At any rate, can someone provide a helper change from the past for
>> PACKAGEGROUP like changes?
>
> Do you mean PACKAGECONFIG?  If so, just run "git log" in your oe-core
> tree and search for PACKAGECONFIG.

From experience I know that learning by example isn't always obvious
for PACKAGECONFIG, but the manual does explain it quite well:

http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-PACKAGECONFIG

Ross

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Phil Blundell]

On Tue, 2013-07-30 at 16:55 +0100, Laszlo Papp wrote:

> At any rate, can someone provide a helper change from the past for
> PACKAGEGROUP like changes?

Do you mean PACKAGECONFIG?  If so, just run "git log" in your oe-core
tree and search for PACKAGECONFIG.

p.

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 2478 bytes --]

One person not using the latest toolchains?

At any rate, can someone provide a helper change from the past for
PACKAGEGROUP like changes?


On Mon, Jul 29, 2013 at 4:42 PM, Bernhard Reutner-Fischer <
rep.dot.nop@gmail.com> wrote:

> On 29 July 2013 15:34:29 Laszlo Papp <lpapp@kde.org> wrote:
>
>> No, it should be disabled by default based on the fact most people do not
>> need this "rfkill" what even upstream has been disabling, and it would be
>> only enabled for those two utils out of the several thousand out there,
>> anyhow.
>>
>
> It was disabled just because of one guy known to notoriously use outdated
> toolchains on recent packages. But OK, I'm out of this whole discussion.
>
> Cheers,
>
>
>> I am just repeating myself as the same is questioned again, again, and
>> again.
>>
>> ... or you really think that "rfkill" is needed for the majority use cases
>> out there?
>>
>>
>> On Mon, Jul 29, 2013 at 2:34 PM, Bernhard Reutner-Fischer <
>> rep.dot.nop@gmail.com> wrote:
>>
>> > On 29 July 2013 14:20:05 Laszlo Papp <lpapp@kde.org> wrote:
>> >
>> >> Oh, it is actually also in danny. I was looking into the "files"
>> >> directory,
>> >> but it is in the other.
>> >>
>> >> It is definitely not in denzil though.
>> >>
>> >
>> > Perhaps disable it only in the layer that pulls in these pre-2.6.31
>> kernel
>> > headers?
>> >
>> > Thanks,
>> >
>> >
>> >>
>> >> On Mon, Jul 29, 2013 at 1:18 PM, Laszlo Papp <lpapp@kde.org> wrote:
>> >>
>> >> > Only _one_, not two.
>> >> >
>> >> >
>> >> > On Mon, Jul 29, 2013 at 11:35 AM, Phil Blundell <pb@pbcl.net> wrote:
>> >> >
>> >> >> On Mon, 2013-07-29 at 11:22 +0100, Laszlo Papp wrote:
>> >> >> > I disagree. This change should not have gone in the first place
>> >> >> > causing the regression for the users. Please be consistent with
>> the
>> >> >> > history.
>> >> >>
>> >> >> If this was a recent change then I would have some (limited) amount
>> of
>> >> >> sympathy for your position.  But the commit you are complaining
>> about
>> >> >> has been in the tree for over a year, and it was presumably
>> included in
>> >> >> at least one if not two of the most recent stable releases.
>> >> >>
>> >> >> p.
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >>
>> >
>> >
>> > Sent with AquaMail for Android
>> > http://www.aqua-mail.com
>> >
>> >
>> >
>>
>
>
> Sent with AquaMail for Android
> http://www.aqua-mail.com
>
>
>

[-- Attachment #2: Type: text/html, Size: 4146 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Bernhard Reutner-Fischer]

On 29 July 2013 15:34:29 Laszlo Papp <lpapp@kde.org> wrote:
> No, it should be disabled by default based on the fact most people do not
> need this "rfkill" what even upstream has been disabling, and it would be
> only enabled for those two utils out of the several thousand out there,
> anyhow.

It was disabled just because of one guy known to notoriously use outdated 
toolchains on recent packages. But OK, I'm out of this whole discussion.

Cheers,
>
> I am just repeating myself as the same is questioned again, again, and
> again.
>
> ... or you really think that "rfkill" is needed for the majority use cases
> out there?
>
>
> On Mon, Jul 29, 2013 at 2:34 PM, Bernhard Reutner-Fischer <
> rep.dot.nop@gmail.com> wrote:
>
> > On 29 July 2013 14:20:05 Laszlo Papp <lpapp@kde.org> wrote:
> >
> >> Oh, it is actually also in danny. I was looking into the "files"
> >> directory,
> >> but it is in the other.
> >>
> >> It is definitely not in denzil though.
> >>
> >
> > Perhaps disable it only in the layer that pulls in these pre-2.6.31 kernel
> > headers?
> >
> > Thanks,
> >
> >
> >>
> >> On Mon, Jul 29, 2013 at 1:18 PM, Laszlo Papp <lpapp@kde.org> wrote:
> >>
> >> > Only _one_, not two.
> >> >
> >> >
> >> > On Mon, Jul 29, 2013 at 11:35 AM, Phil Blundell <pb@pbcl.net> wrote:
> >> >
> >> >> On Mon, 2013-07-29 at 11:22 +0100, Laszlo Papp wrote:
> >> >> > I disagree. This change should not have gone in the first place
> >> >> > causing the regression for the users. Please be consistent with the
> >> >> > history.
> >> >>
> >> >> If this was a recent change then I would have some (limited) amount of
> >> >> sympathy for your position.  But the commit you are complaining about
> >> >> has been in the tree for over a year, and it was presumably included in
> >> >> at least one if not two of the most recent stable releases.
> >> >>
> >> >> p.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >>
> >
> >
> > Sent with AquaMail for Android
> > http://www.aqua-mail.com
> >
> >
> >


Sent with AquaMail for Android
http://www.aqua-mail.com

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Bernhard Reutner-Fischer]

On 29 July 2013 14:20:05 Laszlo Papp <lpapp@kde.org> wrote:
> Oh, it is actually also in danny. I was looking into the "files" directory,
> but it is in the other.
>
> It is definitely not in denzil though.

Perhaps disable it only in the layer that pulls in these pre-2.6.31 kernel 
headers?

Thanks,
>
>
> On Mon, Jul 29, 2013 at 1:18 PM, Laszlo Papp <lpapp@kde.org> wrote:
>
> > Only _one_, not two.
> >
> >
> > On Mon, Jul 29, 2013 at 11:35 AM, Phil Blundell <pb@pbcl.net> wrote:
> >
> >> On Mon, 2013-07-29 at 11:22 +0100, Laszlo Papp wrote:
> >> > I disagree. This change should not have gone in the first place
> >> > causing the regression for the users. Please be consistent with the
> >> > history.
> >>
> >> If this was a recent change then I would have some (limited) amount of
> >> sympathy for your position.  But the commit you are complaining about
> >> has been in the tree for over a year, and it was presumably included in
> >> at least one if not two of the most recent stable releases.
> >>
> >> p.
> >>
> >>
> >>
> >>
> >


Sent with AquaMail for Android
http://www.aqua-mail.com

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1713 bytes --]

No, it should be disabled by default based on the fact most people do not
need this "rfkill" what even upstream has been disabling, and it would be
only enabled for those two utils out of the several thousand out there,
anyhow.

I am just repeating myself as the same is questioned again, again, and
again.

... or you really think that "rfkill" is needed for the majority use cases
out there?


On Mon, Jul 29, 2013 at 2:34 PM, Bernhard Reutner-Fischer <
rep.dot.nop@gmail.com> wrote:

> On 29 July 2013 14:20:05 Laszlo Papp <lpapp@kde.org> wrote:
>
>> Oh, it is actually also in danny. I was looking into the "files"
>> directory,
>> but it is in the other.
>>
>> It is definitely not in denzil though.
>>
>
> Perhaps disable it only in the layer that pulls in these pre-2.6.31 kernel
> headers?
>
> Thanks,
>
>
>>
>> On Mon, Jul 29, 2013 at 1:18 PM, Laszlo Papp <lpapp@kde.org> wrote:
>>
>> > Only _one_, not two.
>> >
>> >
>> > On Mon, Jul 29, 2013 at 11:35 AM, Phil Blundell <pb@pbcl.net> wrote:
>> >
>> >> On Mon, 2013-07-29 at 11:22 +0100, Laszlo Papp wrote:
>> >> > I disagree. This change should not have gone in the first place
>> >> > causing the regression for the users. Please be consistent with the
>> >> > history.
>> >>
>> >> If this was a recent change then I would have some (limited) amount of
>> >> sympathy for your position.  But the commit you are complaining about
>> >> has been in the tree for over a year, and it was presumably included in
>> >> at least one if not two of the most recent stable releases.
>> >>
>> >> p.
>> >>
>> >>
>> >>
>> >>
>> >
>>
>
>
> Sent with AquaMail for Android
> http://www.aqua-mail.com
>
>
>

[-- Attachment #2: Type: text/html, Size: 2743 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

Oh, it is actually also in danny. I was looking into the "files" directory,
but it is in the other.

It is definitely not in denzil though.


On Mon, Jul 29, 2013 at 1:18 PM, Laszlo Papp <lpapp@kde.org> wrote:

> Only _one_, not two.
>
>
> On Mon, Jul 29, 2013 at 11:35 AM, Phil Blundell <pb@pbcl.net> wrote:
>
>> On Mon, 2013-07-29 at 11:22 +0100, Laszlo Papp wrote:
>> > I disagree. This change should not have gone in the first place
>> > causing the regression for the users. Please be consistent with the
>> > history.
>>
>> If this was a recent change then I would have some (limited) amount of
>> sympathy for your position.  But the commit you are complaining about
>> has been in the tree for over a year, and it was presumably included in
>> at least one if not two of the most recent stable releases.
>>
>> p.
>>
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 1588 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 620 bytes --]

Only _one_, not two.


On Mon, Jul 29, 2013 at 11:35 AM, Phil Blundell <pb@pbcl.net> wrote:

> On Mon, 2013-07-29 at 11:22 +0100, Laszlo Papp wrote:
> > I disagree. This change should not have gone in the first place
> > causing the regression for the users. Please be consistent with the
> > history.
>
> If this was a recent change then I would have some (limited) amount of
> sympathy for your position.  But the commit you are complaining about
> has been in the tree for over a year, and it was presumably included in
> at least one if not two of the most recent stable releases.
>
> p.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1024 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

"closed minded" is relative, and I have my personal opinion who could be
classified like that. So let us not do ping-pong "stop being closed minded"
games. :)

 As written several times already, it is just as simple action for the rare
"rfkill" people to do enable this as for me? So, the *real* question is
which people to help in the initial step: my answer is the bigger user
base. Why don't you just provide a change on top of mine as already
suggested if it is "that important" for you guys? As I mentioned, I am not
paid for this, so I have only a very limited time for Yocto compared to
several people in here.

Accordingly, I am not sure I follow your reasoning.


On Mon, Jul 29, 2013 at 12:09 PM, Marcin Juszkiewicz <
marcin@juszkiewicz.com.pl> wrote:

> W dniu 29.07.2013 12:44, Laszlo Papp pisze:
> > OK, I give up the contribution. I really cannot collaborate with
> > people who think it is acceptable to break *many* users' life for the
> > whole project without being able to use anything in favor of a very
> > limited (!) people with only two (!) applications.
>
> Stop being closed minded. OpenEmbedded provides many options for doing
> alterations and you got some suggestions in this thread how to make you
> happy without breaking setup for other people.
>
> If your toolchain is more then 4 years old then maybe stick with older
> versions of OE as well?
>
> Or just update linux-libc-headers part of toolchain and be happy with
> it? But it would require you to rebuild everything to check does it
> builds...
>
> Or do one simple change in your own layer to disable this config option?
> This would take you just 5 minutes and provide compatibility with
> probably even 2.4 kernels.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 2582 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Marcin Juszkiewicz]

W dniu 29.07.2013 12:44, Laszlo Papp pisze:
> OK, I give up the contribution. I really cannot collaborate with
> people who think it is acceptable to break *many* users' life for the
> whole project without being able to use anything in favor of a very
> limited (!) people with only two (!) applications.

Stop being closed minded. OpenEmbedded provides many options for doing
alterations and you got some suggestions in this thread how to make you
happy without breaking setup for other people.

If your toolchain is more then 4 years old then maybe stick with older
versions of OE as well?

Or just update linux-libc-headers part of toolchain and be happy with
it? But it would require you to rebuild everything to check does it
builds...

Or do one simple change in your own layer to disable this config option?
This would take you just 5 minutes and provide compatibility with
probably even 2.4 kernels.

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

https://bugzilla.yoctoproject.org/show_bug.cgi?id=4942


On Mon, Jul 29, 2013 at 11:48 AM, Laszlo Papp <lpapp@kde.org> wrote:

> Have you ever heard about project budgets and that updating a toolchain
> requires a lot of testing, and hence time, money, man power?
>
>
> On Mon, Jul 29, 2013 at 11:46 AM, Paul Barker <paul@paulbarker.me.uk>wrote:
>
>> On 29 July 2013 11:42, Laszlo Papp <lpapp@kde.org> wrote:
>> > Not to mention, you would cause a "runtime" issue which is pretty
>> simple to
>> > fix for a very minor portion compared to a *large* user base using older
>> > toolchains. There is a huge difference between a few people cannot use
>> > rfkill for those applications (2, ridiculous), and that a slightly old
>> > toolchain cannot even build the *whole* project.
>> >
>>
>> Is there any reason that you need to use such an old toolchain? We
>> can't expect everything we have to compile with every toolchain
>> release since the start of the GNU project so we need to draw the line
>> somewhere. I think the feeling is that we'd draw the line somewhere
>> after the toolchain you're using (from 2009 IIRC).
>>
>> --
>> Paul Barker
>>
>> Email: paul@paulbarker.me.uk
>> http://www.paulbarker.me.uk
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2220 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

Why it does not make sense in my opinion is the fact that the many people
would already need to do this right now. Yet, you prefer a few people (if
any?) with only a very limited application set out of the 1000+, as it is
only two which is affected?

I do not understand how the gun can be compared to the cannon. It is
unfortunate you guys introduced regressions for those users, but I just do
not have time to make everyone happy. I am not paid for this as a few in
here. However, I still think making more users happy than less is a nice
thing.


On Mon, Jul 29, 2013 at 11:46 AM, Burton, Ross <ross.burton@intel.com>wrote:

> On 29 July 2013 11:42, Laszlo Papp <lpapp@kde.org> wrote:
> > you would cause a "runtime" issue which is pretty simple to fix
>
> Enabling rfkill would involve writing a bbappend and patching busybox,
> when a PACKAGECONFIG would make everyone happy and configurable from
> the distro.  Even if we disagree on what the default value should be,
> it should be a PACKAGECONFIG.
>
> Ross
>

[-- Attachment #2: Type: text/html, Size: 1507 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

Have you ever heard about project budgets and that updating a toolchain
requires a lot of testing, and hence time, money, man power?


On Mon, Jul 29, 2013 at 11:46 AM, Paul Barker <paul@paulbarker.me.uk> wrote:

> On 29 July 2013 11:42, Laszlo Papp <lpapp@kde.org> wrote:
> > Not to mention, you would cause a "runtime" issue which is pretty simple
> to
> > fix for a very minor portion compared to a *large* user base using older
> > toolchains. There is a huge difference between a few people cannot use
> > rfkill for those applications (2, ridiculous), and that a slightly old
> > toolchain cannot even build the *whole* project.
> >
>
> Is there any reason that you need to use such an old toolchain? We
> can't expect everything we have to compile with every toolchain
> release since the start of the GNU project so we need to draw the line
> somewhere. I think the feeling is that we'd draw the line somewhere
> after the toolchain you're using (from 2009 IIRC).
>
> --
> Paul Barker
>
> Email: paul@paulbarker.me.uk
> http://www.paulbarker.me.uk
>

[-- Attachment #2: Type: text/html, Size: 1689 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Burton, Ross]

On 29 July 2013 11:42, Laszlo Papp <lpapp@kde.org> wrote:
> you would cause a "runtime" issue which is pretty simple to fix

Enabling rfkill would involve writing a bbappend and patching busybox,
when a PACKAGECONFIG would make everyone happy and configurable from
the distro.  Even if we disagree on what the default value should be,
it should be a PACKAGECONFIG.

Ross

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Paul Barker]

On 29 July 2013 11:42, Laszlo Papp <lpapp@kde.org> wrote:
> Not to mention, you would cause a "runtime" issue which is pretty simple to
> fix for a very minor portion compared to a *large* user base using older
> toolchains. There is a huge difference between a few people cannot use
> rfkill for those applications (2, ridiculous), and that a slightly old
> toolchain cannot even build the *whole* project.
>

Is there any reason that you need to use such an old toolchain? We
can't expect everything we have to compile with every toolchain
release since the start of the GNU project so we need to draw the line
somewhere. I think the feeling is that we'd draw the line somewhere
after the toolchain you're using (from 2009 IIRC).

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]

OK, I give up the contribution. I really cannot collaborate with people who
think it is acceptable to break *many* users' life for the whole project
without being able to use anything in favor of a very limited (!) people
with only two (!) applications.


On Mon, Jul 29, 2013 at 11:42 AM, Burton, Ross <ross.burton@intel.com>wrote:

> On 29 July 2013 11:20, Phil Blundell <pb@pbcl.net> wrote:
> > But in this particular case, your new patch seems to have more serious
> > problems since it will cause rfkill to silently disappear for many
> > people who do currently have it.
> >
> > If your distro selects a toolchain which doesn't contain the necessary
> > bits to support rfkill then it seems as though the appropriate course of
> > action would be to either:
>
> I'm in agreement  with Phil. Whilst support for userspaces that from
> 2009 is patchy at best with modern software (you'll need an equally
> old udev, systemd won't happen, etc) this is a trivial change but
> let's be clear that it's an option to handle older external userspaces
> and not our so there should be a PACKAGECONFIG for rfkill that
> defaults to enabled.
>
> Ross
>

[-- Attachment #2: Type: text/html, Size: 1669 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Burton, Ross]

On 29 July 2013 11:20, Phil Blundell <pb@pbcl.net> wrote:
> But in this particular case, your new patch seems to have more serious
> problems since it will cause rfkill to silently disappear for many
> people who do currently have it.
>
> If your distro selects a toolchain which doesn't contain the necessary
> bits to support rfkill then it seems as though the appropriate course of
> action would be to either:

I'm in agreement  with Phil. Whilst support for userspaces that from
2009 is patchy at best with modern software (you'll need an equally
old udev, systemd won't happen, etc) this is a trivial change but
let's be clear that it's an option to handle older external userspaces
and not our so there should be a PACKAGECONFIG for rfkill that
defaults to enabled.

Ross

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

You *do* realize rfkill is a hardly common feature?

Not to mention, you would cause a "runtime" issue which is pretty simple to
fix for a very minor portion compared to a *large* user base using older
toolchains. There is a huge difference between a few people cannot use
rfkill for those applications (2, ridiculous), and that a slightly old
toolchain cannot even build the *whole* project.


On Mon, Jul 29, 2013 at 11:38 AM, Phil Blundell <pb@pbcl.net> wrote:

> On Mon, 2013-07-29 at 11:30 +0100, Laszlo Papp wrote:
> > Not to mention, there is a huge difference between build time
> > regression and run time,
>
> Quite so, run-time regressions are much harder to detect and debug.
>
> p.
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1154 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Phil Blundell]

On Mon, 2013-07-29 at 11:30 +0100, Laszlo Papp wrote:
> Not to mention, there is a huge difference between build time
> regression and run time,

Quite so, run-time regressions are much harder to detect and debug.  

p.

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 943 bytes --]

Exactly, so you broke the update for the last two new versions on the
*build* level.

Anyway, if you do not have any sympathy for older users, then I am very
disappointed.

After this change, the image will build just fine for the "new" people.
Also, if you do not write a change on top of mine, it is probably not so
important anyhow?


On Mon, Jul 29, 2013 at 11:35 AM, Phil Blundell <pb@pbcl.net> wrote:

> On Mon, 2013-07-29 at 11:22 +0100, Laszlo Papp wrote:
> > I disagree. This change should not have gone in the first place
> > causing the regression for the users. Please be consistent with the
> > history.
>
> If this was a recent change then I would have some (limited) amount of
> sympathy for your position.  But the commit you are complaining about
> has been in the tree for over a year, and it was presumably included in
> at least one if not two of the most recent stable releases.
>
> p.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1401 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Phil Blundell]

On Mon, 2013-07-29 at 11:22 +0100, Laszlo Papp wrote:
> I disagree. This change should not have gone in the first place
> causing the regression for the users. Please be consistent with the
> history.

If this was a recent change then I would have some (limited) amount of
sympathy for your position.  But the commit you are complaining about
has been in the tree for over a year, and it was presumably included in
at least one if not two of the most recent stable releases.

p.

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

Not to mention, there is a huge difference between build time regression
and run time, so I disagree.

a)-c) can just as well be done after this change with the same loss. Do not
blame me for introducing build (!) regressions, and then you have got a
situation like this. If you feel it serious, write a change on top of mine.


On Mon, Jul 29, 2013 at 11:22 AM, Laszlo Papp <lpapp@kde.org> wrote:

> I disagree. This change should not have gone in the first place causing
> the regression for the users. Please be consistent with the history.
>
>
> On Mon, Jul 29, 2013 at 11:20 AM, Phil Blundell <pb@pbcl.net> wrote:
>
>> On Mon, 2013-07-29 at 11:01 +0100, Laszlo Papp wrote:
>> > No, that was intentional. That is why the change has been updated.
>> >
>> >
>> > I can update the commit message if that is what you wish?
>>
>> As a general rule yes, please always make sure that the commit message
>> describes what the patch is actually doing.
>>
>> But in this particular case, your new patch seems to have more serious
>> problems since it will cause rfkill to silently disappear for many
>> people who do currently have it.
>>
>> If your distro selects a toolchain which doesn't contain the necessary
>> bits to support rfkill then it seems as though the appropriate course of
>> action would be to either:
>>
>> a) patch rfkill so that it does build with your headers; or
>>
>> b) introduce a PACKAGECONFIG option for busybox to turn off rfkill even
>> if it would naturally default to on, and set this in your distro
>> configuration; or
>>
>> c) just add your own .bbappend for busybox to do what you want.
>>
>> p.
>>
>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2422 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

I disagree. This change should not have gone in the first place causing the
regression for the users. Please be consistent with the history.


On Mon, Jul 29, 2013 at 11:20 AM, Phil Blundell <pb@pbcl.net> wrote:

> On Mon, 2013-07-29 at 11:01 +0100, Laszlo Papp wrote:
> > No, that was intentional. That is why the change has been updated.
> >
> >
> > I can update the commit message if that is what you wish?
>
> As a general rule yes, please always make sure that the commit message
> describes what the patch is actually doing.
>
> But in this particular case, your new patch seems to have more serious
> problems since it will cause rfkill to silently disappear for many
> people who do currently have it.
>
> If your distro selects a toolchain which doesn't contain the necessary
> bits to support rfkill then it seems as though the appropriate course of
> action would be to either:
>
> a) patch rfkill so that it does build with your headers; or
>
> b) introduce a PACKAGECONFIG option for busybox to turn off rfkill even
> if it would naturally default to on, and set this in your distro
> configuration; or
>
> c) just add your own .bbappend for busybox to do what you want.
>
> p.
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 1680 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Phil Blundell]

On Mon, 2013-07-29 at 11:01 +0100, Laszlo Papp wrote:
> No, that was intentional. That is why the change has been updated.
> 
> 
> I can update the commit message if that is what you wish?

As a general rule yes, please always make sure that the commit message
describes what the patch is actually doing.

But in this particular case, your new patch seems to have more serious
problems since it will cause rfkill to silently disappear for many
people who do currently have it.

If your distro selects a toolchain which doesn't contain the necessary
bits to support rfkill then it seems as though the appropriate course of
action would be to either:

a) patch rfkill so that it does build with your headers; or

b) introduce a PACKAGECONFIG option for busybox to turn off rfkill even
if it would naturally default to on, and set this in your distro
configuration; or

c) just add your own .bbappend for busybox to do what you want.

p.

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

No, that was intentional. That is why the change has been updated.

I can update the commit message if that is what you wish?


On Mon, Jul 29, 2013 at 11:00 AM, Phil Blundell <pb@pbcl.net> wrote:

> On Mon, 2013-07-29 at 08:16 +0100, Laszlo Papp wrote:
> > This is necessary to get the build going, for instance with older Code
> Sourcery
> > compilers.
>
> You seem to have inadvertently sent a patch to busybox.inc as well as
> the defconfig change that's described in the commit message.
>
> p.
>
>
>

[-- Attachment #2: Type: text/html, Size: 941 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Phil Blundell]

On Mon, 2013-07-29 at 08:16 +0100, Laszlo Papp wrote:
> This is necessary to get the build going, for instance with older Code Sourcery
> compilers.

You seem to have inadvertently sent a patch to busybox.inc as well as
the defconfig change that's described in the commit message.

p.

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

Let us fix the build issue first, and then you can improve the situation as
you wish.


On Mon, Jul 29, 2013 at 8:20 AM, Paul Barker <paul@paulbarker.me.uk> wrote:

> On 29 July 2013 08:16, Laszlo Papp <lpapp@kde.org> wrote:
> > -       busybox_cfg('wifi', distro_features, 'CONFIG_RFKILL', cnf, rem)
> > -       busybox_cfg('bluetooth', distro_features, 'CONFIG_RFKILL', cnf,
> rem)
>
> It would be good to have some way to re-enable this if it is needed.
> Maybe an 'rfkill' PACKAGECONFIG option?
>
> --
> Paul Barker
>
> Email: paul@paulbarker.me.uk
> http://www.paulbarker.me.uk
>

[-- Attachment #2: Type: text/html, Size: 1188 bytes --]

Re: [PATCH] busybox-1.21.1/defconfig: disable rfkill

[Paul Barker]

On 29 July 2013 08:16, Laszlo Papp <lpapp@kde.org> wrote:
> -       busybox_cfg('wifi', distro_features, 'CONFIG_RFKILL', cnf, rem)
> -       busybox_cfg('bluetooth', distro_features, 'CONFIG_RFKILL', cnf, rem)

It would be good to have some way to re-enable this if it is needed.
Maybe an 'rfkill' PACKAGECONFIG option?

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

[PATCH] busybox-1.21.1/defconfig: disable rfkill

[Laszlo Papp]

This is necessary to get the build going, for instance with older Code Sourcery
compilers.

It is also disabled in upstream due to this very reason. The details can be
found on the following links:

http://comments.gmane.org/gmane.linux.busybox/30999
http://git.busybox.net/busybox/commit/?h=1_21_stable&id=1cd769a154b04f4b058beed482a5dd7192437cdc

[YOCTO #4932]

Signed-off-by: Laszlo Papp <lpapp@kde.org>
---
 meta/recipes-core/busybox/busybox-1.21.1/defconfig | 2 +-
 meta/recipes-core/busybox/busybox.inc              | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-core/busybox/busybox-1.21.1/defconfig b/meta/recipes-core/busybox/busybox-1.21.1/defconfig
index bdfdadf..e77a817 100644
--- a/meta/recipes-core/busybox/busybox-1.21.1/defconfig
+++ b/meta/recipes-core/busybox/busybox-1.21.1/defconfig
@@ -705,7 +705,7 @@ CONFIG_MICROCOM=y
 # CONFIG_MT is not set
 # CONFIG_RAIDAUTORUN is not set
 # CONFIG_READAHEAD is not set
-CONFIG_RFKILL=y
+# CONFIG_RFKILL is not set
 # CONFIG_RUNLEVEL is not set
 # CONFIG_RX is not set
 # CONFIG_SETSID is not set
diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-core/busybox/busybox.inc
index acd2bfb..0e84f4c 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -66,8 +66,6 @@ def features_to_busybox_settings(d):
 	busybox_cfg('nls',  distro_features, 'CONFIG_LOCALE_SUPPORT', cnf, rem)
 	busybox_cfg('ipv4', distro_features, 'CONFIG_FEATURE_IFUPDOWN_IPV4', cnf, rem)
 	busybox_cfg('ipv6', distro_features, 'CONFIG_FEATURE_IFUPDOWN_IPV6', cnf, rem)
-	busybox_cfg('wifi', distro_features, 'CONFIG_RFKILL', cnf, rem)
-	busybox_cfg('bluetooth', distro_features, 'CONFIG_RFKILL', cnf, rem)
 	return "\n".join(cnf), "\n".join(rem)
 
 # X, Y = ${@features_to_uclibc_settings(d)}
-- 
1.8.3.4