Patchwork busybox-1.21.1/defconfig: disable rfkill

login
register
mail settings
Submitter Laszlo Papp
Date July 29, 2013, 7:16 a.m.
Message ID <1375082184-14871-1-git-send-email-lpapp@kde.org>
Download mbox | patch
Permalink /patch/54665/
State New
Headers show

Comments

Laszlo Papp - July 29, 2013, 7:16 a.m.
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(-)
Paul Barker - July 29, 2013, 7:20 a.m.
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?
Laszlo Papp - July 29, 2013, 7:22 a.m.
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
>
Phil Blundell - July 29, 2013, 10 a.m.
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.
Laszlo Papp - July 29, 2013, 10:01 a.m.
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.
>
>
>
Phil Blundell - July 29, 2013, 10:20 a.m.
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.
Laszlo Papp - July 29, 2013, 10:22 a.m.
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.
>
>
>
>
Laszlo Papp - July 29, 2013, 10:30 a.m.
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.
>>
>>
>>
>>
>
Phil Blundell - July 29, 2013, 10:35 a.m.
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.
Laszlo Papp - July 29, 2013, 10:37 a.m.
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.
>
>
>
>
Phil Blundell - July 29, 2013, 10:38 a.m.
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.
Laszlo Papp - July 29, 2013, 10:42 a.m.
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.
>
>
>
>
>
Ross Burton - July 29, 2013, 10:42 a.m.
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
Laszlo Papp - July 29, 2013, 10:44 a.m.
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
>
Paul Barker - July 29, 2013, 10:46 a.m.
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).
Ross Burton - July 29, 2013, 10:46 a.m.
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
Laszlo Papp - July 29, 2013, 10:48 a.m.
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
>
Laszlo Papp - July 29, 2013, 10:50 a.m.
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
>
Laszlo Papp - July 29, 2013, 11:05 a.m.
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
>>
>
>
Marcin Juszkiewicz - July 29, 2013, 11:09 a.m.
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.
Laszlo Papp - July 29, 2013, 11:14 a.m.
"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
>
Laszlo Papp - July 29, 2013, 12:18 p.m.
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.
>
>
>
>
Laszlo Papp - July 29, 2013, 12:20 p.m.
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.
>>
>>
>>
>>
>
Laszlo Papp - July 29, 2013, 1:34 p.m.
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
>
>
>
Bernhard Reutner-Fischer - July 29, 2013, 1:34 p.m.
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
Bernhard Reutner-Fischer - July 29, 2013, 3:42 p.m.
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
Laszlo Papp - July 30, 2013, 3:55 p.m.
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
>
>
>
Phil Blundell - July 30, 2013, 4:10 p.m.
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.
Ross Burton - July 30, 2013, 4:21 p.m.
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
Laszlo Papp - July 31, 2013, 11:13 a.m.
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
>
Khem Raj - July 31, 2013, 10:36 p.m.
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
Laszlo Papp - Aug. 13, 2013, 7:32 a.m.
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
>>
>>
>
Laszlo Papp - Aug. 13, 2013, 7:33 a.m.
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 ...
Ross Burton - Aug. 13, 2013, 9:48 a.m.
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
Laszlo Papp - Aug. 13, 2013, 9:52 a.m.
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
>
Ross Burton - Aug. 13, 2013, 9:58 a.m.
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
Laszlo Papp - Aug. 13, 2013, 10 a.m.
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
>
ml@communistcode.co.uk - Aug. 13, 2013, 10:14 a.m.
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,
Phil Blundell - Aug. 13, 2013, 10:17 a.m.
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
Laszlo Papp - Aug. 13, 2013, 10:19 a.m.
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
>
ml@communistcode.co.uk - Aug. 13, 2013, 10:35 a.m.
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
> 
>
Laszlo Papp - Aug. 13, 2013, 10:39 a.m.
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.
Fathi Boudra - Aug. 14, 2013, 8:35 a.m.
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
>

Patch

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)}