On 13 August 2013 12: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 especi
On Tue, Aug 13, 2013 at 11:35 AM, Jack Mitchell 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
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
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 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
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
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 wrote:
> On 13 August 2013 10:52, Laszlo Papp wrote:
> > As we have already discussed
On 13 August 2013 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 especi
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/met
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)
On 13 August 2013 08:32, Laszlo Papp 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?
Quo
On Tue, Aug 13, 2013 at 8:32 AM, Laszlo Papp 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 f
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 wrote:
> W
On Jul 29, 2013, at 12:16 AM, Laszlo Papp 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
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.
htt
On 30 July 2013 17:10, Phil Blundell 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
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.
_
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 wrote:
>
>> No, it should b
On 29 July 2013 15:34:29 Laszlo Papp 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 b
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 14:20:05 Laszlo Papp 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
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 wrote:
> Only _one_, not two.
>
>
> On Mon, Jul 29, 2013 at 11:35 AM, Phil Blundell wrote:
>
>> On Mon, 2013-
Only _one_, not two.
On Mon, Jul 29, 2013 at 11:35 AM, Phil Blundell 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 thi
"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* que
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 (!) applica
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4942
On Mon, Jul 29, 2013 at 11:48 AM, Laszlo Papp 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 Barke
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
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 wrote:
> On 29 July 2013 11:42, Laszlo Papp wrote:
> > Not to mention, you would cause a "runtime" issue which is p
On 29 July 2013 11:42, Laszlo Papp 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 application
On 29 July 2013 11:42, Laszlo Papp 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 defa
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, R
On 29 July 2013 11:20, Phil Blundell 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
>
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 applicati
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 l
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: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
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, wri
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 wrote:
> On Mon, 2013-07-29 at 11:01 +0100, Laszlo Papp wrote:
> > No, that was intentional. That is why t
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 d
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 wrote:
> On Mon, 2013-07-29 at 08:16 +0100, Laszlo Papp wrote:
> > This is necessary to get the build going, for instance
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.
_
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 wrote:
> On 29 July 2013 08:16, Laszlo Papp wrote:
> > - busybox_cfg('wifi', distro_features, 'CONFIG_RFKILL', cnf, rem)
> > - busybox_cfg('bluetooth',
On 29 July 2013 08:16, Laszlo Papp 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 o
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_st
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_st
45 matches
Mail list logo
