On 13 August 2013 12:52, Laszlo Papp lp...@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
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 lp...@kde.org
On Tue, Aug 13, 2013 at 8:32 AM, Laszlo Papp lp...@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
On 13 August 2013 08:32, Laszlo Papp lp...@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
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)
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
---
On 13 August 2013 10:52, Laszlo Papp lp...@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
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.bur...@intel.comwrote:
On 13 August 2013 10:52, Laszlo Papp lp...@kde.org
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
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
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
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
On Tue, Aug 13, 2013 at 11:35 AM, Jack Mitchell m...@communistcode.co.ukwrote:
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?!
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.
On Jul 29, 2013, at 12:16 AM, Laszlo Papp lp...@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:
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@gmail.com wrote:
On 29 July 2013 15:34:29 Laszlo Papp lp...@kde.org wrote:
No, it
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.
On 30 July 2013 17:10, Phil Blundell p...@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
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
On 29 July 2013 08:16, Laszlo Papp lp...@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'
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 p...@paulbarker.me.uk wrote:
On 29 July 2013 08:16, Laszlo Papp lp...@kde.org wrote:
- busybox_cfg('wifi', distro_features, 'CONFIG_RFKILL', cnf, rem)
-
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.
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 p...@pbcl.net wrote:
On Mon, 2013-07-29 at 08:16 +0100, Laszlo Papp wrote:
This is necessary to get the build going,
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
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 p...@pbcl.net wrote:
On Mon, 2013-07-29 at 11:01 +0100, Laszlo Papp wrote:
No, that was intentional.
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,
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.
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
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.
___
Openembedded-core mailing
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
On 29 July 2013 11:20, Phil Blundell p...@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
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,
On 29 July 2013 11:42, Laszlo Papp lp...@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
On 29 July 2013 11:42, Laszlo Papp lp...@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
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 p...@paulbarker.me.uk wrote:
On 29 July 2013 11:42, Laszlo Papp lp...@kde.org wrote:
Not to mention, you would
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
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4942
On Mon, Jul 29, 2013 at 11:48 AM, Laszlo Papp lp...@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,
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 (!)
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
Only _one_, not two.
On Mon, Jul 29, 2013 at 11:35 AM, Phil Blundell p...@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.
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 lp...@kde.org wrote:
Only _one_, not two.
On Mon, Jul 29, 2013 at 11:35 AM, Phil Blundell p...@pbcl.net
On 29 July 2013 14:20:05 Laszlo Papp lp...@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,
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
On 29 July 2013 15:34:29 Laszlo Papp lp...@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
44 matches
Mail list logo
