[PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage

[PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage

[Dmitry Eremin-Solenikov]

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
 meta/classes/kernel.bbclass |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index bc1baa0..c577011 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -451,7 +451,7 @@ python populate_packages_prepend () {
 	metapkg = "kernel-modules"
 	bb.data.setVar('ALLOW_EMPTY_' + metapkg, "1", d)
 	bb.data.setVar('FILES_' + metapkg, "", d)
-	blacklist = [ 'kernel-dev', 'kernel-image', 'kernel-base', 'kernel-vmlinux', 'perf', 'kernel-misc' ]
+	blacklist = [ 'kernel-dev', 'kernel-image', 'kernel-base', 'kernel-vmlinux', 'perf', 'perf-dbg', 'kernel-misc' ]
 	for l in module_deps.values():
 		for i in l:
 			pkg = module_pattern % legitimize_package_name(re.match(module_regex, os.path.basename(i)).group(1))
-- 
1.7.2.5

[PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Dmitry Eremin-Solenikov]

MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
meta-oe kernel.bbclass. Several machines depend on this functionality.

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
 meta/classes/kernel.bbclass |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index c577011..b44e3b5 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -20,6 +20,11 @@ python __anonymous () {
     image = bb.data.getVar('INITRAMFS_IMAGE', d, True)
     if image:
         bb.data.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs', d)
+
+    machine_kernel_pr = bb.data.getVar('MACHINE_KERNEL_PR', d, True)
+
+    if machine_kernel_pr:
+        bb.data.setVar('PR', machine_kernel_pr, d)
 }
 
 inherit kernel-arch deploy
-- 
1.7.2.5

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Otavio Salvador]

On Sat, Sep 17, 2011 at 19:18, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
> meta-oe kernel.bbclass. Several machines depend on this functionality.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>

Acked-by: Otavio Salvador <otavio@ossystems.com.br>

+1

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Bruce Ashfield]

On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
> meta-oe kernel.bbclass. Several machines depend on this functionality.

I don' t have a big problem with this, since the change is obviously
harmless if it
doesn't need to be used. But similar to my comment on patch 3/5, is there any
history/technical reasons we can capture here ?

I did a quick search to dig up a bit on this myself, but a summary
would definitely
help, since I see that this has a long and sometimes twisting history. Is it as
simple as ?

 "A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
 rebuilds for kernel and external modules"

Cheers,

Bruce


>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
>  meta/classes/kernel.bbclass |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index c577011..b44e3b5 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -20,6 +20,11 @@ python __anonymous () {
>     image = bb.data.getVar('INITRAMFS_IMAGE', d, True)
>     if image:
>         bb.data.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs', d)
> +
> +    machine_kernel_pr = bb.data.getVar('MACHINE_KERNEL_PR', d, True)
> +
> +    if machine_kernel_pr:
> +        bb.data.setVar('PR', machine_kernel_pr, d)
>  }
>
>  inherit kernel-arch deploy
> --
> 1.7.2.5
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Koen Kooi]

Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <bruce.ashfield@gmail.com> het volgende geschreven:

> On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com> wrote:
>> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
>> meta-oe kernel.bbclass. Several machines depend on this functionality.
> 
> I don' t have a big problem with this, since the change is obviously
> harmless if it
> doesn't need to be used. But similar to my comment on patch 3/5, is there any
> history/technical reasons we can capture here ?
> 
> I did a quick search to dig up a bit on this myself, but a summary
> would definitely
> help, since I see that this has a long and sometimes twisting history. Is it as
> simple as ?
> 
> "A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
> rebuilds for kernel and external modules"

It is that simple :) 



> 
> Cheers,
> 
> Bruce
> 
> 
>> 
>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>> ---
>>  meta/classes/kernel.bbclass |    5 +++++
>>  1 files changed, 5 insertions(+), 0 deletions(-)
>> 
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index c577011..b44e3b5 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -20,6 +20,11 @@ python __anonymous () {
>>     image = bb.data.getVar('INITRAMFS_IMAGE', d, True)
>>     if image:
>>         bb.data.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs', d)
>> +
>> +    machine_kernel_pr = bb.data.getVar('MACHINE_KERNEL_PR', d, True)
>> +
>> +    if machine_kernel_pr:
>> +        bb.data.setVar('PR', machine_kernel_pr, d)
>>  }
>> 
>>  inherit kernel-arch deploy
>> --
>> 1.7.2.5
>> 
>> 
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>> 
> 
> 
> 
> -- 
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Richard Purdie]

On Tue, 2011-09-27 at 18:40 -0500, Koen Kooi wrote:
> 
> Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <bruce.ashfield@gmail.com> het volgende geschreven:
> 
> > On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
> > <dbaryshkov@gmail.com> wrote:
> >> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
> >> meta-oe kernel.bbclass. Several machines depend on this functionality.
> > 
> > I don' t have a big problem with this, since the change is obviously
> > harmless if it
> > doesn't need to be used. But similar to my comment on patch 3/5, is there any
> > history/technical reasons we can capture here ?
> > 
> > I did a quick search to dig up a bit on this myself, but a summary
> > would definitely
> > help, since I see that this has a long and sometimes twisting history. Is it as
> > simple as ?
> > 
> > "A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
> > rebuilds for kernel and external modules"
> 
> It is that simple :) 

I have reservations about this patch given we soon plan to stop needing
to bump PR values. This patch is actually a perfect example of how brain
dead the current manual PR bumping is and why we need something better.
I don't want half the code in the repo to be a mass of PR values which
need to be incremented manually under weird and wonderful circumstances
which is where the direction things are currently going...

I'd like to hold off on this one.

Cheers,

Richard

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Koen Kooi]

Op 28 sep. 2011 om 09:54 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:

> On Tue, 2011-09-27 at 18:40 -0500, Koen Kooi wrote:
>> 
>> Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <bruce.ashfield@gmail.com> het volgende geschreven:
>> 
>>> On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
>>> <dbaryshkov@gmail.com> wrote:
>>>> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
>>>> meta-oe kernel.bbclass. Several machines depend on this functionality.
>>> 
>>> I don' t have a big problem with this, since the change is obviously
>>> harmless if it
>>> doesn't need to be used. But similar to my comment on patch 3/5, is there any
>>> history/technical reasons we can capture here ?
>>> 
>>> I did a quick search to dig up a bit on this myself, but a summary
>>> would definitely
>>> help, since I see that this has a long and sometimes twisting history. Is it as
>>> simple as ?
>>> 
>>> "A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
>>> rebuilds for kernel and external modules"
>> 
>> It is that simple :) 
> 
> I have reservations about this patch given we soon plan to stop needing
> to bump PR values. This patch is actually a perfect example of how brain
> dead the current manual PR bumping is and why we need something better.
> I don't want half the code in the repo to be a mass of PR values which
> need to be incremented manually under weird and wonderful circumstances
> which is where the direction things are currently going...
> 
> I'd like to hold off on this one.

This patch improves the current situation and I don't foresee the autoPR code working soon


> 
> Cheers,
> 
> Richard
> 
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Dmitry Eremin-Solenikov]

On 9/28/11, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
>
> Op 28 sep. 2011 om 09:54 heeft Richard Purdie
> <richard.purdie@linuxfoundation.org> het volgende geschreven:
>
>> On Tue, 2011-09-27 at 18:40 -0500, Koen Kooi wrote:
>>>
>>> Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <bruce.ashfield@gmail.com>
>>> het volgende geschreven:
>>>
>>>> On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
>>>> <dbaryshkov@gmail.com> wrote:
>>>>> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present
>>>>> in
>>>>> meta-oe kernel.bbclass. Several machines depend on this functionality.
>>>>
>>>> I don' t have a big problem with this, since the change is obviously
>>>> harmless if it
>>>> doesn't need to be used. But similar to my comment on patch 3/5, is
>>>> there any
>>>> history/technical reasons we can capture here ?
>>>>
>>>> I did a quick search to dig up a bit on this myself, but a summary
>>>> would definitely
>>>> help, since I see that this has a long and sometimes twisting history.
>>>> Is it as
>>>> simple as ?
>>>>
>>>> "A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
>>>> rebuilds for kernel and external modules"
>>>
>>> It is that simple :)
>>
>> I have reservations about this patch given we soon plan to stop needing
>> to bump PR values. This patch is actually a perfect example of how brain
>> dead the current manual PR bumping is and why we need something better.
>> I don't want half the code in the repo to be a mass of PR values which
>> need to be incremented manually under weird and wonderful circumstances
>> which is where the direction things are currently going...
>>
>> I'd like to hold off on this one.
>
> This patch improves the current situation and I don't foresee the autoPR
> code working soon

As another point for this patch: I'd like to ask Koen to drop
kernel.bbclass from
meta-oe. After do_uboot_mkimage this is the only significant difference. And
unfortunately this feature is already used on several machines. Quick
grep return the following results. Koen, could you comment on this?

$ grep MACHINE_KERNEL_PR */{,*/}c* -r
meta-openpandora/conf/machine/include/omap3.inc:MACHINE_KERNEL_PR = "r101"
meta-openpandora/conf/machine/omap3-pandora.conf:MACHINE_KERNEL_PR = "r3"
meta-texasinstruments/conf/machine/include/davinci.inc:MACHINE_KERNEL_PR = "r51"
meta-texasinstruments/conf/machine/include/omap3.inc:MACHINE_KERNEL_PR = "r105"
meta-texasinstruments/conf/machine/include/ti814x.inc:MACHINE_KERNEL_PR = "r1"
meta-texasinstruments/conf/machine/include/ti816x.inc:MACHINE_KERNEL_PR = "r2"
meta-smartphone/meta-nokia/conf/machine/nokia900.conf:MACHINE_KERNEL_PR = "r68"
meta-smartphone/meta-palm/conf/machine/include/palmpre.inc:MACHINE_KERNEL_PR
= "r0"
meta-texasinstruments/recipes-ti/c6accel/ti-c6accel.inc:PR =
"${MACHINE_KERNEL_PR}"
meta-texasinstruments/recipes-ti/codec-engine/ti-codec-engine.inc:PR =
"${MACHINE_KERNEL_PR}"
meta-texasinstruments/recipes-ti/codec-engine/ti-codecs-omap3530_4.00.00.00.bb:PR="${MACHINE_KERNEL_PR}"
openembedded-core/meta/classes/kernel.bbclass:    machine_kernel_pr =
bb.data.getVar('MACHINE_KERNEL_PR', d, True)



-- 
With best wishes
Dmitry

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Richard Purdie]

On Wed, 2011-09-28 at 13:42 -0500, Koen Kooi wrote:
> 
> Op 28 sep. 2011 om 09:54 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
> 
> > On Tue, 2011-09-27 at 18:40 -0500, Koen Kooi wrote:
> >> 
> >> Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <bruce.ashfield@gmail.com> het volgende geschreven:
> >> 
> >>> On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
> >>> <dbaryshkov@gmail.com> wrote:
> >>>> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
> >>>> meta-oe kernel.bbclass. Several machines depend on this functionality.
> >>> 
> >>> I don' t have a big problem with this, since the change is obviously
> >>> harmless if it
> >>> doesn't need to be used. But similar to my comment on patch 3/5, is there any
> >>> history/technical reasons we can capture here ?
> >>> 
> >>> I did a quick search to dig up a bit on this myself, but a summary
> >>> would definitely
> >>> help, since I see that this has a long and sometimes twisting history. Is it as
> >>> simple as ?
> >>> 
> >>> "A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
> >>> rebuilds for kernel and external modules"
> >> 
> >> It is that simple :) 
> > 
> > I have reservations about this patch given we soon plan to stop needing
> > to bump PR values. This patch is actually a perfect example of how brain
> > dead the current manual PR bumping is and why we need something better.
> > I don't want half the code in the repo to be a mass of PR values which
> > need to be incremented manually under weird and wonderful circumstances
> > which is where the direction things are currently going...
> > 
> > I'd like to hold off on this one.
> 
> This patch improves the current situation and I don't foresee the
> autoPR code working soon

Which is why we need to switch to that model and shake out the issues
sooner than later. Enough is enough with the PR madness and we need to
get to grips and fix it.

Cheers,

Richard

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Otavio Salvador]

On Wed, Sep 28, 2011 at 16:50, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>> This patch improves the current situation and I don't foresee the
>> autoPR code working soon
>
> Which is why we need to switch to that model and shake out the issues
> sooner than later. Enough is enough with the PR madness and we need to
> get to grips and fix it.

I fully agree this is the way to go but this doesn't mean we ought to
hold this patch until all this happens. This patch allows the removal
of the kernel.bbclass from meta-oe so reducing the delta between
oe-core and meta-oe.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Koen Kooi]

Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:

> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>>> This patch improves the current situation and I don't foresee the
>>> autoPR code working soon
>> 
>> Which is why we need to switch to that model and shake out the issues
>> sooner than later. Enough is enough with the PR madness and we need to
>> get to grips and fix it.
> 
> I fully agree this is the way to go but this doesn't mean we ought to
> hold this patch until all this happens. This patch allows the removal
> of the kernel.bbclass from meta-oe so reducing the delta between
> oe-core and meta-oe.

So a month later and no sign of the mythical working auto-PR-incrementer or work on it. So can this patch go in? It would mean we can drop kernel.bbclass from meta-oe.

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Richard Purdie]

On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
> 
> > On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> >>> This patch improves the current situation and I don't foresee the
> >>> autoPR code working soon
> >> 
> >> Which is why we need to switch to that model and shake out the issues
> >> sooner than later. Enough is enough with the PR madness and we need to
> >> get to grips and fix it.
> > 
> > I fully agree this is the way to go but this doesn't mean we ought to
> > hold this patch until all this happens. This patch allows the removal
> > of the kernel.bbclass from meta-oe so reducing the delta between
> > oe-core and meta-oe.
> 
> So a month later and no sign of the mythical working
> auto-PR-incrementer or work on it.

A month where we were stabilising for a release. Its on the 1.2 feature
list and as it happens I've been hearing questions about what is needed
here.

>  So can this patch go in? It would mean we can drop kernel.bbclass
> from meta-oe.

I *HATE* this PR bumping stuff. I've just been told we likely need to
bump the PR for anything using libGL which once again shows that build
system basically failing to automate building things.

So I'm drawing a line here and no, we can't take this. If its fine to
expect people to bump PR values manually for lib* changes, its fine for
kernels too. I'd suggest you do drop this from meta-oe and we start
building up pressure for the problem to get fixed properly rather than
letting people wallpaper over the cracks.

Cheers,

Richard

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Koen Kooi]

Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:

> On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
>> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
>> 
>>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
>>> <richard.purdie@linuxfoundation.org> wrote:
>>>>> This patch improves the current situation and I don't foresee the
>>>>> autoPR code working soon
>>>> 
>>>> Which is why we need to switch to that model and shake out the issues
>>>> sooner than later. Enough is enough with the PR madness and we need to
>>>> get to grips and fix it.
>>> 
>>> I fully agree this is the way to go but this doesn't mean we ought to
>>> hold this patch until all this happens. This patch allows the removal
>>> of the kernel.bbclass from meta-oe so reducing the delta between
>>> oe-core and meta-oe.
>> 
>> So a month later and no sign of the mythical working
>> auto-PR-incrementer or work on it.
> 
> A month where we were stabilising for a release. Its on the 1.2 feature
> list and as it happens I've been hearing questions about what is needed
> here.
> 
>> So can this patch go in? It would mean we can drop kernel.bbclass
>> from meta-oe.
> 
> I *HATE* this PR bumping stuff. I've just been told we likely need to
> bump the PR for anything using libGL which once again shows that build
> system basically failing to automate building things.
> 
> So I'm drawing a line here and no, we can't take this. If its fine to
> expect people to bump PR values manually for lib* changes, its fine for
> kernels too. I'd suggest you do drop this from meta-oe and we start
> building up pressure for the problem to get fixed properly rather than
> letting people wallpaper over the cracks.

I have products to ship, so treating meta-oe as a plaything and break this for the sake of breaking it is unacceptable. I'll let oe-core have the monopoly on high-qualitily, but broken metadata.

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Otavio Salvador]

On Thu, Oct 20, 2011 at 09:29, Koen Kooi <koen@dominion.thruhere.net> wrote:
...
>> So I'm drawing a line here and no, we can't take this. If its fine to
>> expect people to bump PR values manually for lib* changes, its fine for
>> kernels too. I'd suggest you do drop this from meta-oe and we start
>> building up pressure for the problem to get fixed properly rather than
>> letting people wallpaper over the cracks.
>
> I have products to ship, so treating meta-oe as a plaything and break this for the sake of breaking it is unacceptable. I'll let oe-core have the monopoly on high-qualitily, but broken metadata.

Richard,

It makes no sense to don't accept this as it reduces delta between
oe-core and meta-oe and makes easier for other people to move from
oe-classic to oe-core. Once the auto-PR arrives this can be deprecated
but delaying it with no ETA is no sense.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Frans Meulenbroeks]

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

2011/10/20 Koen Kooi <koen@dominion.thruhere.net>

>
> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
>
> > On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> >> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
> >>
> >>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> >>> <richard.purdie@linuxfoundation.org> wrote:
> >>>>> This patch improves the current situation and I don't foresee the
> >>>>> autoPR code working soon
> >>>>
> >>>> Which is why we need to switch to that model and shake out the issues
> >>>> sooner than later. Enough is enough with the PR madness and we need to
> >>>> get to grips and fix it.
> >>>
> >>> I fully agree this is the way to go but this doesn't mean we ought to
> >>> hold this patch until all this happens. This patch allows the removal
> >>> of the kernel.bbclass from meta-oe so reducing the delta between
> >>> oe-core and meta-oe.
> >>
> >> So a month later and no sign of the mythical working
> >> auto-PR-incrementer or work on it.
> >
> > A month where we were stabilising for a release. Its on the 1.2 feature
> > list and as it happens I've been hearing questions about what is needed
> > here.
> >
> >> So can this patch go in? It would mean we can drop kernel.bbclass
> >> from meta-oe.
> >
> > I *HATE* this PR bumping stuff. I've just been told we likely need to
> > bump the PR for anything using libGL which once again shows that build
> > system basically failing to automate building things.
> >
> > So I'm drawing a line here and no, we can't take this. If its fine to
> > expect people to bump PR values manually for lib* changes, its fine for
> > kernels too. I'd suggest you do drop this from meta-oe and we start
> > building up pressure for the problem to get fixed properly rather than
> > letting people wallpaper over the cracks.
>
> I have products to ship, so treating meta-oe as a plaything and break this
> for the sake of breaking it is unacceptable. I'll let oe-core have the
> monopoly on high-qualitily, but broken metadata.
> .
>

Didn't we have a TSC to escalate discussions and disagreements between
developers to???

Best regards, Frans

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

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Richard Purdie]

On Thu, 2011-10-20 at 13:29 +0200, Koen Kooi wrote:
> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
> 
> > On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> >> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
> >> 
> >>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> >>> <richard.purdie@linuxfoundation.org> wrote:
> >>>>> This patch improves the current situation and I don't foresee the
> >>>>> autoPR code working soon
> >>>> 
> >>>> Which is why we need to switch to that model and shake out the issues
> >>>> sooner than later. Enough is enough with the PR madness and we need to
> >>>> get to grips and fix it.
> >>> 
> >>> I fully agree this is the way to go but this doesn't mean we ought to
> >>> hold this patch until all this happens. This patch allows the removal
> >>> of the kernel.bbclass from meta-oe so reducing the delta between
> >>> oe-core and meta-oe.
> >> 
> >> So a month later and no sign of the mythical working
> >> auto-PR-incrementer or work on it.
> > 
> > A month where we were stabilising for a release. Its on the 1.2 feature
> > list and as it happens I've been hearing questions about what is needed
> > here.
> > 
> >> So can this patch go in? It would mean we can drop kernel.bbclass
> >> from meta-oe.
> > 
> > I *HATE* this PR bumping stuff. I've just been told we likely need to
> > bump the PR for anything using libGL which once again shows that build
> > system basically failing to automate building things.
> > 
> > So I'm drawing a line here and no, we can't take this. If its fine to
> > expect people to bump PR values manually for lib* changes, its fine for
> > kernels too. I'd suggest you do drop this from meta-oe and we start
> > building up pressure for the problem to get fixed properly rather than
> > letting people wallpaper over the cracks.
> 
> I have products to ship, so treating meta-oe as a plaything and break
> this for the sake of breaking it is unacceptable. I'll let oe-core
> have the monopoly on high-qualitily, but broken metadata.

Its not as if there isn't another way to handle this, it is a little
harder work I agree. This isn't breaking for the sake of breaking
either, its applying a bit of pressure to ensure we fix an underlying
problem we've had for a long time. I don't think fixing it will be easy,
I do think we need to though.

Also, the idea never was to have everyone using bleeding edge for
shipping products. This is what stable releases are for?

Cheers,

Richard

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Koen Kooi]

Op 20 okt. 2011, om 14:38 heeft Richard Purdie het volgende geschreven:

> On Thu, 2011-10-20 at 13:29 +0200, Koen Kooi wrote:
>> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
>>>> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
>>>> 
>>>>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
>>>>> <richard.purdie@linuxfoundation.org> wrote:
>>>>>>> This patch improves the current situation and I don't foresee the
>>>>>>> autoPR code working soon
>>>>>> 
>>>>>> Which is why we need to switch to that model and shake out the issues
>>>>>> sooner than later. Enough is enough with the PR madness and we need to
>>>>>> get to grips and fix it.
>>>>> 
>>>>> I fully agree this is the way to go but this doesn't mean we ought to
>>>>> hold this patch until all this happens. This patch allows the removal
>>>>> of the kernel.bbclass from meta-oe so reducing the delta between
>>>>> oe-core and meta-oe.
>>>> 
>>>> So a month later and no sign of the mythical working
>>>> auto-PR-incrementer or work on it.
>>> 
>>> A month where we were stabilising for a release. Its on the 1.2 feature
>>> list and as it happens I've been hearing questions about what is needed
>>> here.
>>> 
>>>> So can this patch go in? It would mean we can drop kernel.bbclass
>>>> from meta-oe.
>>> 
>>> I *HATE* this PR bumping stuff. I've just been told we likely need to
>>> bump the PR for anything using libGL which once again shows that build
>>> system basically failing to automate building things.
>>> 
>>> So I'm drawing a line here and no, we can't take this. If its fine to
>>> expect people to bump PR values manually for lib* changes, its fine for
>>> kernels too. I'd suggest you do drop this from meta-oe and we start
>>> building up pressure for the problem to get fixed properly rather than
>>> letting people wallpaper over the cracks.
>> 
>> I have products to ship, so treating meta-oe as a plaything and break
>> this for the sake of breaking it is unacceptable. I'll let oe-core
>> have the monopoly on high-qualitily, but broken metadata.
> 
> Its not as if there isn't another way to handle this, it is a little
> harder work I agree. This isn't breaking for the sake of breaking
> either, its applying a bit of pressure to ensure we fix an underlying
> problem we've had for a long time. I don't think fixing it will be easy,
> I do think we need to though.
> 
> Also, the idea never was to have everyone using bleeding edge for
> shipping products. This is what stable releases are for?

That's what stable releases are for, but I don't see a release for OE-core, do you? I see a poky release, but not an OE-core release.

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Otavio Salvador]

On Thu, Oct 20, 2011 at 10:54, Koen Kooi <koen@dominion.thruhere.net> wrote:
...
>> Also, the idea never was to have everyone using bleeding edge for
>> shipping products. This is what stable releases are for?
>
> That's what stable releases are for, but I don't see a release for OE-core, do you? I see a poky release, but not an OE-core release.

People, let's calm down.

I think since Richard disagree about pushing this patch and more then
one person disagree with Richard, TSC is the way to go.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Koen Kooi]

Op 20 okt. 2011, om 15:02 heeft Otavio Salvador het volgende geschreven:

> On Thu, Oct 20, 2011 at 10:54, Koen Kooi <koen@dominion.thruhere.net> wrote:
> ...
>>> Also, the idea never was to have everyone using bleeding edge for
>>> shipping products. This is what stable releases are for?
>> 
>> That's what stable releases are for, but I don't see a release for OE-core, do you? I see a poky release, but not an OE-core release.
> 
> People, let's calm down.
> 
> I think since Richard disagree about pushing this patch and more then
> one person disagree with Richard, TSC is the way to go.

Executive summary of the TSC meeting:

1) This patch gets applied, but no more PR helpers will be allowed, INC_PR and MACHINE_KERNEL_PR are the only ones tolerated for the time being.
2) kernel.bbclass gets dropped from meta-oe
3) basic-hash will get turned on in master-next
4) super-duper PR automation work will land in master-next and get merged into master when it's deemed "good enough"

The intermediate merge step into master-next is only done if enough people test master-next. If people don't want to test it, the merge and associated breakage will go straight into master.

regards,

Koen

Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

[Richard Purdie]

On Thu, 2011-10-20 at 14:54 +0200, Koen Kooi wrote:
> Op 20 okt. 2011, om 14:38 heeft Richard Purdie het volgende geschreven:
> 
> > On Thu, 2011-10-20 at 13:29 +0200, Koen Kooi wrote:
> >> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
> >> 
> >>> On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> >>>> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
> >>>> 
> >>>>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> >>>>> <richard.purdie@linuxfoundation.org> wrote:
> >>>>>>> This patch improves the current situation and I don't foresee the
> >>>>>>> autoPR code working soon
> >>>>>> 
> >>>>>> Which is why we need to switch to that model and shake out the issues
> >>>>>> sooner than later. Enough is enough with the PR madness and we need to
> >>>>>> get to grips and fix it.
> >>>>> 
> >>>>> I fully agree this is the way to go but this doesn't mean we ought to
> >>>>> hold this patch until all this happens. This patch allows the removal
> >>>>> of the kernel.bbclass from meta-oe so reducing the delta between
> >>>>> oe-core and meta-oe.
> >>>> 
> >>>> So a month later and no sign of the mythical working
> >>>> auto-PR-incrementer or work on it.
> >>> 
> >>> A month where we were stabilising for a release. Its on the 1.2 feature
> >>> list and as it happens I've been hearing questions about what is needed
> >>> here.
> >>> 
> >>>> So can this patch go in? It would mean we can drop kernel.bbclass
> >>>> from meta-oe.
> >>> 
> >>> I *HATE* this PR bumping stuff. I've just been told we likely need to
> >>> bump the PR for anything using libGL which once again shows that build
> >>> system basically failing to automate building things.
> >>> 
> >>> So I'm drawing a line here and no, we can't take this. If its fine to
> >>> expect people to bump PR values manually for lib* changes, its fine for
> >>> kernels too. I'd suggest you do drop this from meta-oe and we start
> >>> building up pressure for the problem to get fixed properly rather than
> >>> letting people wallpaper over the cracks.
> >> 
> >> I have products to ship, so treating meta-oe as a plaything and break
> >> this for the sake of breaking it is unacceptable. I'll let oe-core
> >> have the monopoly on high-qualitily, but broken metadata.
> > 
> > Its not as if there isn't another way to handle this, it is a little
> > harder work I agree. This isn't breaking for the sake of breaking
> > either, its applying a bit of pressure to ensure we fix an underlying
> > problem we've had for a long time. I don't think fixing it will be easy,
> > I do think we need to though.
> > 
> > Also, the idea never was to have everyone using bleeding edge for
> > shipping products. This is what stable releases are for?
> 
> That's what stable releases are for, but I don't see a release for
> OE-core, do you? I see a poky release, but not an OE-core release.

As you are no doubt aware, that got discussed at the last TSC meeting.
Khem did volunteer to help with that, there is a branch there ready to
be tagged too and I was planning to raise progress with this at
tonight's TSC meeting.

Cheers,

Richard

[PATCH 3/5] kernel.bbclass: move uImage handling to separate task

[Dmitry Eremin-Solenikov]

As per org.oe.dev and meta-oe's kernel.bbclass move uImage creation to
separate task from do_deploy. The only major feature of oe-core's
version (not to recreate uImage if it exists) is retained in this patch.

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
 meta/classes/kernel.bbclass |   40 ++++++++++++++++++++++++----------------
 1 files changed, 24 insertions(+), 16 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index b44e3b5..6ff4018 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -486,6 +486,30 @@ do_sizecheck() {
 
 addtask sizecheck before do_install after do_compile
 
+do_uboot_mkimage() {
+    if test "x${KERNEL_IMAGETYPE}" = "xuImage" -a \
+            ! -e arch/${ARCH}/boot/uImage ; then
+        ENTRYPOINT=${UBOOT_ENTRYPOINT}
+        if test -n "${UBOOT_ENTRYSYMBOL}"; then
+            ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
+                   awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
+        fi
+        if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
+            ${OBJCOPY} -O binary -R .note -R .comment -S arch/${ARCH}/boot/compressed/vmlinux linux.bin
+            uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C none -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
+            rm -f linux.bin
+        else
+            ${OBJCOPY} -O binary -R .note -R .comment -S vmlinux linux.bin
+            rm -f linux.bin.gz
+            gzip -9 linux.bin
+            uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C gzip -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin.gz arch/${ARCH}/boot/uImage
+            rm -f linux.bin.gz
+        fi
+    fi
+}
+
+addtask uboot_mkimage before do_install after do_compile
+
 KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
 # Don't include the DATETIME variable in the sstate package signatures
 KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
@@ -497,22 +521,6 @@ kernel_do_deploy() {
 		tar -cvzf ${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
 	fi
 
-	if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then 
-		if test -e arch/${ARCH}/boot/uImage ; then
-			cp arch/${ARCH}/boot/uImage ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
-		elif test -e arch/${ARCH}/boot/compressed/vmlinux ; then
-			${OBJCOPY} -O binary -R .note -R .comment -S arch/${ARCH}/boot/compressed/vmlinux linux.bin
-			uboot-mkimage -A ${ARCH} -O linux -T kernel -C none -a ${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
-			rm -f linux.bin
-		else
-			${OBJCOPY} -O binary -R .note -R .comment -S vmlinux linux.bin
-			rm -f linux.bin.gz
-			gzip -9 linux.bin
-			uboot-mkimage -A ${ARCH} -O linux -T kernel -C gzip -a ${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin.gz ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
-			rm -f linux.bin.gz
-		fi
-	fi
-
 	cd ${DEPLOYDIR}
 	rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin
 	ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGE_SYMLINK_NAME}.bin
-- 
1.7.2.5

Re: [PATCH 3/5] kernel.bbclass: move uImage handling to separate task

[Otavio Salvador]

This was nack'ed but I don't remember why; Richard?

On Sat, Sep 17, 2011 at 19:18, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> As per org.oe.dev and meta-oe's kernel.bbclass move uImage creation to
> separate task from do_deploy. The only major feature of oe-core's
> version (not to recreate uImage if it exists) is retained in this patch.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
>  meta/classes/kernel.bbclass |   40 ++++++++++++++++++++++++----------------
>  1 files changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index b44e3b5..6ff4018 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -486,6 +486,30 @@ do_sizecheck() {
>
>  addtask sizecheck before do_install after do_compile
>
> +do_uboot_mkimage() {
> +    if test "x${KERNEL_IMAGETYPE}" = "xuImage" -a \
> +            ! -e arch/${ARCH}/boot/uImage ; then
> +        ENTRYPOINT=${UBOOT_ENTRYPOINT}
> +        if test -n "${UBOOT_ENTRYSYMBOL}"; then
> +            ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
> +                   awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
> +        fi
> +        if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
> +            ${OBJCOPY} -O binary -R .note -R .comment -S arch/${ARCH}/boot/compressed/vmlinux linux.bin
> +            uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C none -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
> +            rm -f linux.bin
> +        else
> +            ${OBJCOPY} -O binary -R .note -R .comment -S vmlinux linux.bin
> +            rm -f linux.bin.gz
> +            gzip -9 linux.bin
> +            uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C gzip -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin.gz arch/${ARCH}/boot/uImage
> +            rm -f linux.bin.gz
> +        fi
> +    fi
> +}
> +
> +addtask uboot_mkimage before do_install after do_compile
> +
>  KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
>  # Don't include the DATETIME variable in the sstate package signatures
>  KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
> @@ -497,22 +521,6 @@ kernel_do_deploy() {
>                tar -cvzf ${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
>        fi
>
> -       if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
> -               if test -e arch/${ARCH}/boot/uImage ; then
> -                       cp arch/${ARCH}/boot/uImage ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
> -               elif test -e arch/${ARCH}/boot/compressed/vmlinux ; then
> -                       ${OBJCOPY} -O binary -R .note -R .comment -S arch/${ARCH}/boot/compressed/vmlinux linux.bin
> -                       uboot-mkimage -A ${ARCH} -O linux -T kernel -C none -a ${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
> -                       rm -f linux.bin
> -               else
> -                       ${OBJCOPY} -O binary -R .note -R .comment -S vmlinux linux.bin
> -                       rm -f linux.bin.gz
> -                       gzip -9 linux.bin
> -                       uboot-mkimage -A ${ARCH} -O linux -T kernel -C gzip -a ${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin.gz ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
> -                       rm -f linux.bin.gz
> -               fi
> -       fi
> -
>        cd ${DEPLOYDIR}
>        rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin
>        ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGE_SYMLINK_NAME}.bin
> --
> 1.7.2.5
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [PATCH 3/5] kernel.bbclass: move uImage handling to separate task

[Dmitry Eremin-Solenikov]

On 09/18/2011 02:25 AM, Otavio Salvador wrote:
> This was nack'ed but I don't remember why; Richard?

This was nack'ed because that version of the patch didn't check
for existence of uImage built by kernel tree (not present in 
oe-dev/meta-oe, added in oe-core as somebody had problems with 
regenerated uImage). My version of the patch has such check, so it can 
go in probably.

>
> On Sat, Sep 17, 2011 at 19:18, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com>  wrote:
>> As per org.oe.dev and meta-oe's kernel.bbclass move uImage creation to
>> separate task from do_deploy. The only major feature of oe-core's
>> version (not to recreate uImage if it exists) is retained in this patch.
>>
>> Signed-off-by: Dmitry Eremin-Solenikov<dbaryshkov@gmail.com>
>> ---
>>   meta/classes/kernel.bbclass |   40 ++++++++++++++++++++++++----------------
>>   1 files changed, 24 insertions(+), 16 deletions(-)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index b44e3b5..6ff4018 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -486,6 +486,30 @@ do_sizecheck() {
>>
>>   addtask sizecheck before do_install after do_compile
>>
>> +do_uboot_mkimage() {
>> +    if test "x${KERNEL_IMAGETYPE}" = "xuImage" -a \
>> +            ! -e arch/${ARCH}/boot/uImage ; then
>> +        ENTRYPOINT=${UBOOT_ENTRYPOINT}
>> +        if test -n "${UBOOT_ENTRYSYMBOL}"; then
>> +            ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
>> +                   awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
>> +        fi
>> +        if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
>> +            ${OBJCOPY} -O binary -R .note -R .comment -S arch/${ARCH}/boot/compressed/vmlinux linux.bin
>> +            uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C none -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
>> +            rm -f linux.bin
>> +        else
>> +            ${OBJCOPY} -O binary -R .note -R .comment -S vmlinux linux.bin
>> +            rm -f linux.bin.gz
>> +            gzip -9 linux.bin
>> +            uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C gzip -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin.gz arch/${ARCH}/boot/uImage
>> +            rm -f linux.bin.gz
>> +        fi
>> +    fi
>> +}
>> +
>> +addtask uboot_mkimage before do_install after do_compile
>> +
>>   KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
>>   # Don't include the DATETIME variable in the sstate package signatures
>>   KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
>> @@ -497,22 +521,6 @@ kernel_do_deploy() {
>>                 tar -cvzf ${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
>>         fi
>>
>> -       if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
>> -               if test -e arch/${ARCH}/boot/uImage ; then
>> -                       cp arch/${ARCH}/boot/uImage ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
>> -               elif test -e arch/${ARCH}/boot/compressed/vmlinux ; then
>> -                       ${OBJCOPY} -O binary -R .note -R .comment -S arch/${ARCH}/boot/compressed/vmlinux linux.bin
>> -                       uboot-mkimage -A ${ARCH} -O linux -T kernel -C none -a ${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
>> -                       rm -f linux.bin
>> -               else
>> -                       ${OBJCOPY} -O binary -R .note -R .comment -S vmlinux linux.bin
>> -                       rm -f linux.bin.gz
>> -                       gzip -9 linux.bin
>> -                       uboot-mkimage -A ${ARCH} -O linux -T kernel -C gzip -a ${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin.gz ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
>> -                       rm -f linux.bin.gz
>> -               fi
>> -       fi
>> -
>>         cd ${DEPLOYDIR}
>>         rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin
>>         ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGE_SYMLINK_NAME}.bin
>> --
>> 1.7.2.5
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
>
>

Re: [PATCH 3/5] kernel.bbclass: move uImage handling to separate task

[Bruce Ashfield]

On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> As per org.oe.dev and meta-oe's kernel.bbclass move uImage creation to
> separate task from do_deploy. The only major feature of oe-core's
> version (not to recreate uImage if it exists) is retained in this patch.

I'm getting around to commenting on this patch series, sorry for the
slow replies.
Things have been a bit busy.

This seems reasonable to me, but I was wondering if we could document in the
commit header why this is a good thing ? Not everyone is familiar with oe-dev
or the history behind these changes. Having to cross reference to another
repository for the high level reasoning behind a change is not really
ideal, and
tossing something into the commit that explains things a bit is minimal up
front effort.

What I mean is "sync'ing oe-core to oe-dev" isn't the reason I'd like
to see. Are
the advantages that breaking this out into a separate task that it allows finer
grained scheduling by bitbake ? flexibility to be done at different times, etc ?

But the change does seem reasonable to me, I'm just looking to capture some
of the technical advantages in the commit messages.

Cheers,

Bruce

>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
>  meta/classes/kernel.bbclass |   40 ++++++++++++++++++++++++----------------
>  1 files changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index b44e3b5..6ff4018 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -486,6 +486,30 @@ do_sizecheck() {
>
>  addtask sizecheck before do_install after do_compile
>
> +do_uboot_mkimage() {
> +    if test "x${KERNEL_IMAGETYPE}" = "xuImage" -a \
> +            ! -e arch/${ARCH}/boot/uImage ; then
> +        ENTRYPOINT=${UBOOT_ENTRYPOINT}
> +        if test -n "${UBOOT_ENTRYSYMBOL}"; then
> +            ENTRYPOINT=`${HOST_PREFIX}nm ${S}/vmlinux | \
> +                   awk '$3=="${UBOOT_ENTRYSYMBOL}" {print $1}'`
> +        fi
> +        if test -e arch/${ARCH}/boot/compressed/vmlinux ; then
> +            ${OBJCOPY} -O binary -R .note -R .comment -S arch/${ARCH}/boot/compressed/vmlinux linux.bin
> +            uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C none -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin arch/${ARCH}/boot/uImage
> +            rm -f linux.bin
> +        else
> +            ${OBJCOPY} -O binary -R .note -R .comment -S vmlinux linux.bin
> +            rm -f linux.bin.gz
> +            gzip -9 linux.bin
> +            uboot-mkimage -A ${UBOOT_ARCH} -O linux -T kernel -C gzip -a ${UBOOT_LOADADDRESS} -e $ENTRYPOINT -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin.gz arch/${ARCH}/boot/uImage
> +            rm -f linux.bin.gz
> +        fi
> +    fi
> +}
> +
> +addtask uboot_mkimage before do_install after do_compile
> +
>  KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
>  # Don't include the DATETIME variable in the sstate package signatures
>  KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
> @@ -497,22 +521,6 @@ kernel_do_deploy() {
>                tar -cvzf ${DEPLOYDIR}/modules-${KERNEL_VERSION}-${PR}-${MACHINE}.tgz -C ${D} lib
>        fi
>
> -       if test "x${KERNEL_IMAGETYPE}" = "xuImage" ; then
> -               if test -e arch/${ARCH}/boot/uImage ; then
> -                       cp arch/${ARCH}/boot/uImage ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
> -               elif test -e arch/${ARCH}/boot/compressed/vmlinux ; then
> -                       ${OBJCOPY} -O binary -R .note -R .comment -S arch/${ARCH}/boot/compressed/vmlinux linux.bin
> -                       uboot-mkimage -A ${ARCH} -O linux -T kernel -C none -a ${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
> -                       rm -f linux.bin
> -               else
> -                       ${OBJCOPY} -O binary -R .note -R .comment -S vmlinux linux.bin
> -                       rm -f linux.bin.gz
> -                       gzip -9 linux.bin
> -                       uboot-mkimage -A ${ARCH} -O linux -T kernel -C gzip -a ${UBOOT_ENTRYPOINT} -e ${UBOOT_ENTRYPOINT} -n "${DISTRO_NAME}/${PV}/${MACHINE}" -d linux.bin.gz ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
> -                       rm -f linux.bin.gz
> -               fi
> -       fi
> -
>        cd ${DEPLOYDIR}
>        rm -f ${KERNEL_IMAGE_SYMLINK_NAME}.bin
>        ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGE_SYMLINK_NAME}.bin
> --
> 1.7.2.5
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

[PATCH 4/5] kernel.bbclass: handle .cis firmware

[Dmitry Eremin-Solenikov]

.cis firmware files are used by kernel to patch incorrect CIS fir PCMCIA
cards. Create respective packages.

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
 meta/classes/kernel.bbclass |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 6ff4018..59d3b89 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -450,6 +450,7 @@ python populate_packages_prepend () {
 	postrm = bb.data.getVar('pkg_postrm_modules', d, 1)
 	do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.bin$', output_pattern='kernel-firmware-%s', description='Firmware for %s', recursive=True, extra_depends='')
 	do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.fw$', output_pattern='kernel-firmware-%s', description='Firmware for %s', recursive=True, extra_depends='')
+	do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.cis$', output_pattern='kernel-firmware-%s', description='Firmware for %s', recursive=True, extra_depends='')
 	do_split_packages(d, root='/lib/modules', file_regex=module_regex, output_pattern=module_pattern, description='%s kernel module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, extra_depends='update-modules kernel-%s' % bb.data.getVar("KERNEL_VERSION", d, 1))
 
 	import re
-- 
1.7.2.5

Re: [PATCH 4/5] kernel.bbclass: handle .cis firmware

[Bruce Ashfield]

On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> .cis firmware files are used by kernel to patch incorrect CIS fir PCMCIA
> cards. Create respective packages.

Looks fine to me.

Acked-by: Bruce Ashfield <bruce.ashfield@windriver.com>

>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
>  meta/classes/kernel.bbclass |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 6ff4018..59d3b89 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -450,6 +450,7 @@ python populate_packages_prepend () {
>        postrm = bb.data.getVar('pkg_postrm_modules', d, 1)
>        do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.bin$', output_pattern='kernel-firmware-%s', description='Firmware for %s', recursive=True, extra_depends='')
>        do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.fw$', output_pattern='kernel-firmware-%s', description='Firmware for %s', recursive=True, extra_depends='')
> +       do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.cis$', output_pattern='kernel-firmware-%s', description='Firmware for %s', recursive=True, extra_depends='')
>        do_split_packages(d, root='/lib/modules', file_regex=module_regex, output_pattern=module_pattern, description='%s kernel module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, extra_depends='update-modules kernel-%s' % bb.data.getVar("KERNEL_VERSION", d, 1))
>
>        import re
> --
> 1.7.2.5
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 4/5] kernel.bbclass: handle .cis firmware

[Richard Purdie]

On Sun, 2011-09-18 at 02:18 +0400, Dmitry Eremin-Solenikov wrote:
> .cis firmware files are used by kernel to patch incorrect CIS fir PCMCIA
> cards. Create respective packages.
> 
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
>  meta/classes/kernel.bbclass |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 6ff4018..59d3b89 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -450,6 +450,7 @@ python populate_packages_prepend () {
>  	postrm = bb.data.getVar('pkg_postrm_modules', d, 1)
>  	do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.bin$', output_pattern='kernel-firmware-%s', description='Firmware for %s', recursive=True, extra_depends='')
>  	do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.fw$', output_pattern='kernel-firmware-%s', description='Firmware for %s', recursive=True, extra_depends='')
> +	do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.cis$', output_pattern='kernel-firmware-%s', description='Firmware for %s', recursive=True, extra_depends='')
>  	do_split_packages(d, root='/lib/modules', file_regex=module_regex, output_pattern=module_pattern, description='%s kernel module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, extra_depends='update-modules kernel-%s' % bb.data.getVar("KERNEL_VERSION", d, 1))
>  
>  	import re

Merged to master, thanks.

Richard

[PATCH 5/5] kernel.bbclass: remove unshipped files in do_install

[Dmitry Eremin-Solenikov]

Drop two unsed files (modules.order and modules.builtin) in do_install
to stop the "unshipped files" warning.

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
 meta/classes/kernel.bbclass |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 59d3b89..6b2e603 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -108,6 +108,8 @@ kernel_do_install() {
 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
 	if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
 		oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" modules_install
+		rm -f "${D}/lib/modules/${KERNEL_VERSION}/modules.order"
+		rm -f "${D}/lib/modules/${KERNEL_VERSION}/modules.builtin"
 	else
 		bbnote "no modules to install"
 	fi
-- 
1.7.2.5

Re: [PATCH 5/5] kernel.bbclass: remove unshipped files in do_install

[Bruce Ashfield]

On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> Drop two unsed files (modules.order and modules.builtin) in do_install
> to stop the "unshipped files" warning.

One less warning is a good thing!

Looks good to me,  I can add my vote to this one.

Acked-by: Bruce Ashfield <bruce.ashfield@windriver.com>

>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
>  meta/classes/kernel.bbclass |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 59d3b89..6b2e603 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -108,6 +108,8 @@ kernel_do_install() {
>        unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
>        if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
>                oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" modules_install
> +               rm -f "${D}/lib/modules/${KERNEL_VERSION}/modules.order"
> +               rm -f "${D}/lib/modules/${KERNEL_VERSION}/modules.builtin"
>        else
>                bbnote "no modules to install"
>        fi
> --
> 1.7.2.5
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 5/5] kernel.bbclass: remove unshipped files in do_install

[Richard Purdie]

On Sun, 2011-09-18 at 02:18 +0400, Dmitry Eremin-Solenikov wrote:
> Drop two unsed files (modules.order and modules.builtin) in do_install
> to stop the "unshipped files" warning.
> 
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
>  meta/classes/kernel.bbclass |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 59d3b89..6b2e603 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -108,6 +108,8 @@ kernel_do_install() {
>  	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
>  	if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
>  		oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" modules_install
> +		rm -f "${D}/lib/modules/${KERNEL_VERSION}/modules.order"
> +		rm -f "${D}/lib/modules/${KERNEL_VERSION}/modules.builtin"
>  	else
>  		bbnote "no modules to install"
>  	fi

Merged to master, thanks.

Richard

Re: [PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage

[Otavio Salvador]

I have sent this in July and it was nacked. See at
https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489

On Sat, Sep 17, 2011 at 19:18, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
>  meta/classes/kernel.bbclass |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index bc1baa0..c577011 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -451,7 +451,7 @@ python populate_packages_prepend () {
>        metapkg = "kernel-modules"
>        bb.data.setVar('ALLOW_EMPTY_' + metapkg, "1", d)
>        bb.data.setVar('FILES_' + metapkg, "", d)
> -       blacklist = [ 'kernel-dev', 'kernel-image', 'kernel-base', 'kernel-vmlinux', 'perf', 'kernel-misc' ]
> +       blacklist = [ 'kernel-dev', 'kernel-image', 'kernel-base', 'kernel-vmlinux', 'perf', 'perf-dbg', 'kernel-misc' ]
>        for l in module_deps.values():
>                for i in l:
>                        pkg = module_pattern % legitimize_package_name(re.match(module_regex, os.path.basename(i)).group(1))
> --
> 1.7.2.5
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

Re: [PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage

[Dmitry Eremin-Solenikov]

On 09/18/2011 02:23 AM, Otavio Salvador wrote:
> I have sent this in July and it was nacked. See at
> https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489

Answering the original question by Saul:
A possible better question is why perf-dbg is getting generated and 
what's in it?

perf and perf-dbg are generated to contain perf tool if it's not 
directly enabled (AFAIK), but you can compile it by running make in 
tools/perf. It has some additional depends (like binutils-dev, 
elfutils-dev, news-dev, etc., so it's not enabled by default. Probably 
we should enable it though.

>
> On Sat, Sep 17, 2011 at 19:18, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com>  wrote:
>> Signed-off-by: Koen Kooi<koen@dominion.thruhere.net>
>> Signed-off-by: Dmitry Eremin-Solenikov<dbaryshkov@gmail.com>
>> ---
>>   meta/classes/kernel.bbclass |    2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index bc1baa0..c577011 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -451,7 +451,7 @@ python populate_packages_prepend () {
>>         metapkg = "kernel-modules"
>>         bb.data.setVar('ALLOW_EMPTY_' + metapkg, "1", d)
>>         bb.data.setVar('FILES_' + metapkg, "", d)
>> -       blacklist = [ 'kernel-dev', 'kernel-image', 'kernel-base', 'kernel-vmlinux', 'perf', 'kernel-misc' ]
>> +       blacklist = [ 'kernel-dev', 'kernel-image', 'kernel-base', 'kernel-vmlinux', 'perf', 'perf-dbg', 'kernel-misc' ]
>>         for l in module_deps.values():
>>                 for i in l:
>>                         pkg = module_pattern % legitimize_package_name(re.match(module_regex, os.path.basename(i)).group(1))
>> --
>> 1.7.2.5
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>
>
>

Re: [PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage

[Koen Kooi]

Op 22 sep. 2011, om 14:25 heeft Dmitry Eremin-Solenikov het volgende geschreven:

> On 09/18/2011 02:23 AM, Otavio Salvador wrote:
>> I have sent this in July and it was nacked. See at
>> https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489
> 
> Answering the original question by Saul:
> A possible better question is why perf-dbg is getting generated and what's in it?
> 
> perf and perf-dbg are generated to contain perf tool if it's not directly enabled (AFAIK), but you can compile it by running make in tools/perf. It has some additional depends (like binutils-dev, elfutils-dev, news-dev, etc., so it's not enabled by default. Probably we should enable it though.

the oe core kernel.bbclass builds perf by default

Re: [PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage

[Dmitry Eremin-Solenikov]

On 09/22/2011 04:35 PM, Koen Kooi wrote:
>
> Op 22 sep. 2011, om 14:25 heeft Dmitry Eremin-Solenikov het volgende geschreven:
>
>> On 09/18/2011 02:23 AM, Otavio Salvador wrote:
>>> I have sent this in July and it was nacked. See at
>>> https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489
>>
>> Answering the original question by Saul:
>> A possible better question is why perf-dbg is getting generated and what's in it?
>>
>> perf and perf-dbg are generated to contain perf tool if it's not directly enabled (AFAIK), but you can compile it by running make in tools/perf. It has some additional depends (like binutils-dev, elfutils-dev, news-dev, etc., so it's not enabled by default. Probably we should enable it though.
>
> the oe core kernel.bbclass builds perf by default

according to kernel.bbclass: "perf must be enabled in individual kernel 
recipes"

-- 
With best wishes
Dmitry

Re: [PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage

[Koen Kooi]

Op 22 sep. 2011, om 15:00 heeft Dmitry Eremin-Solenikov het volgende geschreven:

> On 09/22/2011 04:35 PM, Koen Kooi wrote:
>> 
>> Op 22 sep. 2011, om 14:25 heeft Dmitry Eremin-Solenikov het volgende geschreven:
>> 
>>> On 09/18/2011 02:23 AM, Otavio Salvador wrote:
>>>> I have sent this in July and it was nacked. See at
>>>> https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489
>>> 
>>> Answering the original question by Saul:
>>> A possible better question is why perf-dbg is getting generated and what's in it?
>>> 
>>> perf and perf-dbg are generated to contain perf tool if it's not directly enabled (AFAIK), but you can compile it by running make in tools/perf. It has some additional depends (like binutils-dev, elfutils-dev, news-dev, etc., so it's not enabled by default. Probably we should enable it though.
>> 
>> the oe core kernel.bbclass builds perf by default
> 
> according to kernel.bbclass: "perf must be enabled in individual kernel recipes"

And pretty much everything uses recipes-kernel/linux/linux-tools.inc, which enables it. I had to add do_compile_perf() { : } to my old kernel recipes that have a broken perf, so it's opt-out, not opt-in.

Re: [PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage

[Bruce Ashfield]

On Thu, Sep 22, 2011 at 9:17 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 22 sep. 2011, om 15:00 heeft Dmitry Eremin-Solenikov het volgende geschreven:
>
>> On 09/22/2011 04:35 PM, Koen Kooi wrote:
>>>
>>> Op 22 sep. 2011, om 14:25 heeft Dmitry Eremin-Solenikov het volgende geschreven:
>>>
>>>> On 09/18/2011 02:23 AM, Otavio Salvador wrote:
>>>>> I have sent this in July and it was nacked. See at
>>>>> https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489
>>>>
>>>> Answering the original question by Saul:
>>>> A possible better question is why perf-dbg is getting generated and what's in it?
>>>>
>>>> perf and perf-dbg are generated to contain perf tool if it's not directly enabled (AFAIK), but you can compile it by running make in tools/perf. It has some additional depends (like binutils-dev, elfutils-dev, news-dev, etc., so it's not enabled by default. Probably we should enable it though.
>>>
>>> the oe core kernel.bbclass builds perf by default
>>
>> according to kernel.bbclass: "perf must be enabled in individual kernel recipes"
>
> And pretty much everything uses recipes-kernel/linux/linux-tools.inc, which enables it. I had to add do_compile_perf() { : } to my old kernel recipes that have a broken perf, so it's opt-out, not opt-in.

We can always flip this around if required. When I initially did the kernel
tree based builds for perf it was right in a specific kernel recipe, and then
pulled it out into linux-tools.inc for easier reuse it was the intention that
just including/requiring that .inc file would trigger a build of perf.

I'm open to inhibiting this via the blacklist or via some other suitable
mechanism.

But did we get some include creep (or maybe I'm just missing it) ?
When I just checked my tree, I only see a handful of places that linux-tools.inc
will be pulled in and trigger a build.

Cheers,

Bruce

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage

[Koen Kooi]

Op 22 sep. 2011, om 15:28 heeft Bruce Ashfield het volgende geschreven:

> On Thu, Sep 22, 2011 at 9:17 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> 
>> Op 22 sep. 2011, om 15:00 heeft Dmitry Eremin-Solenikov het volgende geschreven:
>> 
>>> On 09/22/2011 04:35 PM, Koen Kooi wrote:
>>>> 
>>>> Op 22 sep. 2011, om 14:25 heeft Dmitry Eremin-Solenikov het volgende geschreven:
>>>> 
>>>>> On 09/18/2011 02:23 AM, Otavio Salvador wrote:
>>>>>> I have sent this in July and it was nacked. See at
>>>>>> https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489
>>>>> 
>>>>> Answering the original question by Saul:
>>>>> A possible better question is why perf-dbg is getting generated and what's in it?
>>>>> 
>>>>> perf and perf-dbg are generated to contain perf tool if it's not directly enabled (AFAIK), but you can compile it by running make in tools/perf. It has some additional depends (like binutils-dev, elfutils-dev, news-dev, etc., so it's not enabled by default. Probably we should enable it though.
>>>> 
>>>> the oe core kernel.bbclass builds perf by default
>>> 
>>> according to kernel.bbclass: "perf must be enabled in individual kernel recipes"
>> 
>> And pretty much everything uses recipes-kernel/linux/linux-tools.inc, which enables it. I had to add do_compile_perf() { : } to my old kernel recipes that have a broken perf, so it's opt-out, not opt-in.
> 
> We can always flip this around if required. When I initially did the kernel
> tree based builds for perf it was right in a specific kernel recipe, and then
> pulled it out into linux-tools.inc for easier reuse it was the intention that
> just including/requiring that .inc file would trigger a build of perf.


I'm not complaining about perf being built, I'm complaining that the patch is held up on a question why perf-dbg is getting built. If 'perf' is in the blacklist, 'perf-dbg' should be in as well. If 'perf-dbg' isn't allowed in, take out 'perf' as well, since they are a matched pair.

Re: [PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage

[Bruce Ashfield]

On Thu, Sep 22, 2011 at 9:56 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
> Op 22 sep. 2011, om 15:28 heeft Bruce Ashfield het volgende geschreven:
>
>> On Thu, Sep 22, 2011 at 9:17 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>>>
>>> Op 22 sep. 2011, om 15:00 heeft Dmitry Eremin-Solenikov het volgende geschreven:
>>>
>>>> On 09/22/2011 04:35 PM, Koen Kooi wrote:
>>>>>
>>>>> Op 22 sep. 2011, om 14:25 heeft Dmitry Eremin-Solenikov het volgende geschreven:
>>>>>
>>>>>> On 09/18/2011 02:23 AM, Otavio Salvador wrote:
>>>>>>> I have sent this in July and it was nacked. See at
>>>>>>> https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489
>>>>>>
>>>>>> Answering the original question by Saul:
>>>>>> A possible better question is why perf-dbg is getting generated and what's in it?
>>>>>>
>>>>>> perf and perf-dbg are generated to contain perf tool if it's not directly enabled (AFAIK), but you can compile it by running make in tools/perf. It has some additional depends (like binutils-dev, elfutils-dev, news-dev, etc., so it's not enabled by default. Probably we should enable it though.
>>>>>
>>>>> the oe core kernel.bbclass builds perf by default
>>>>
>>>> according to kernel.bbclass: "perf must be enabled in individual kernel recipes"
>>>
>>> And pretty much everything uses recipes-kernel/linux/linux-tools.inc, which enables it. I had to add do_compile_perf() { : } to my old kernel recipes that have a broken perf, so it's opt-out, not opt-in.
>>
>> We can always flip this around if required. When I initially did the kernel
>> tree based builds for perf it was right in a specific kernel recipe, and then
>> pulled it out into linux-tools.inc for easier reuse it was the intention that
>> just including/requiring that .inc file would trigger a build of perf.
>
>
> I'm not complaining about perf being built, I'm complaining that the patch is held up on a question why perf-dbg is getting built. If 'perf' is in the blacklist, 'perf-dbg' should be in as well. If 'perf-dbg' isn't allowed in, take out 'perf' as well, since they are a matched pair.

Aha. Yes, I see that now. I'm generally quite bad at packaging so I sometimes
need to be pointed right at something :)

As for getting it in or out of the tree, I'm only one voice, but I
don't see a downside
to this being on the blacklist as well.

Cheers,

Bruce

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: [PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage

[Dmitry Eremin-Solenikov]

Sorry to bother all of you, what about this patchset?

-- 
With best wishes
Dmitry

Re: [PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage

[Richard Purdie]

On Wed, 2011-09-28 at 12:47 +0400, Dmitry Eremin-Solenikov wrote:
> Sorry to bother all of you, what about this patchset?

I was waiting for Bruce to review them.

I've taken three of them, the forth needs a better patch description as
per Bruce's request.

The MACHINE_PR one I have reservations about and I'll reply to that
thread.

Cheers,

Richard

Re: [PATCH 1/5] kernel.bbclass: blacklist 'perf-dbg' as well for the modules metapackage

[Richard Purdie]

On Sun, 2011-09-18 at 02:18 +0400, Dmitry Eremin-Solenikov wrote:
> Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
>  meta/classes/kernel.bbclass |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index bc1baa0..c577011 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -451,7 +451,7 @@ python populate_packages_prepend () {
>  	metapkg = "kernel-modules"
>  	bb.data.setVar('ALLOW_EMPTY_' + metapkg, "1", d)
>  	bb.data.setVar('FILES_' + metapkg, "", d)
> -	blacklist = [ 'kernel-dev', 'kernel-image', 'kernel-base', 'kernel-vmlinux', 'perf', 'kernel-misc' ]
> +	blacklist = [ 'kernel-dev', 'kernel-image', 'kernel-base', 'kernel-vmlinux', 'perf', 'perf-dbg', 'kernel-misc' ]
>  	for l in module_deps.values():
>  		for i in l:
>  			pkg = module_pattern % legitimize_package_name(re.match(module_regex, os.path.basename(i)).group(1))

Merged to master, thanks.

Richard