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
--- meta/classes/kernel.bbclass | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
meta/classes/kernel.bbclass +1 -1
@@ -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))
Signature · 1 line
1.7.2.5
PATCH 2/5 kernel.bbclass: respect MACHINE_KERNEL_PR
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.
--- meta/classes/kernel.bbclass | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
meta/classes/kernel.bbclass +5 -0
@@ -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
Signature · 1 line
1.7.2.5
Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
Quoted 4 lines · Dmitry Eremin-Solenikov
MACHINE_KERNEL_PRwas 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 <[email protected]>
+1
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] 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
In reply to Dmitry Eremin-SolenikovQuoted 2 lines · Dmitry Eremin-Solenikov
MACHINE_KERNEL_PRwas 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
Quoted 31 lines
Signed-off-by Dmitry Eremin-Solenikov <[email protected]>---
meta/classes/kernel.bbclass | 5 +++++1 files changed, 5 insertions(+), 0 deletions(-)meta/classes/kernel.bbclass +0
-0@@ -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)meta/classes/kernel.bbclass +5
-0+ + 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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 2 lines
"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
Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <[email protected]> het volgende geschreven:
Quoted 10 lines
Quoted 2 lines · Dmitry Eremin-Solenikov
MACHINE_KERNEL_PRwas 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 ?
Quoted 7 lines
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_PRto force rebuilds for kernel and external modules"
It is that simple :)
Quoted 48 lines
Cheers,
Bruce
Quoted 31 lines
Signed-off-by Dmitry Eremin-Solenikov <[email protected]>--- meta/classes/kernel.bbclass | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)meta/classes/kernel.bbclass +5
-1@@ -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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-coreSignature · 7 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
Quoted 18 lines · Koen Kooi
Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <[email protected]> het volgende geschreven:
Quoted 15 lines
Quoted 2 lines · Dmitry Eremin-Solenikov
MACHINE_KERNEL_PRwas 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 ?
Quoted 4 lines
Quoted 2 lines
"A machine.conf or local.conf can increase
MACHINE_KERNEL_PRto 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
Op 28 sep. 2011 om 09:54 heeft Richard Purdie <[email protected]> het volgende geschreven:
Quoted 24 lines · Koen Kooi
Quoted 18 lines
Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <[email protected]> het volgende geschreven:
Quoted 15 lines
Quoted 2 lines · Dmitry Eremin-Solenikov
MACHINE_KERNEL_PRwas 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 ?Quoted 4 lines
Quoted 2 lines
"A machine.conf or local.conf can increase
MACHINE_KERNEL_PRto force rebuilds for kernel and external modules"It is that simple :)
Quoted 8 lines
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
Quoted 12 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
Quoted 40 lines · Koen Kooi
Op 28 sep. 2011 om 09:54 heeft Richard Purdie <[email protected]> het volgende geschreven:
Quoted 35 lines · Koen Kooi
Quoted 22 lines
Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <[email protected]> het volgende geschreven:
Quoted 18 lines
Quoted 3 lines · Dmitry Eremin-Solenikov
MACHINE_KERNEL_PRwas 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 ?Quoted 4 lines
Quoted 2 lines
"A machine.conf or local.conf can increase
MACHINE_KERNEL_PRto 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...
Quoted 4 lines
Quoted 1 line
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)Signature · 2 lines
With best wishes Dmitry
Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
In reply to Koen KooiQuoted 34 lines · Koen Kooi
Op 28 sep. 2011 om 09:54 heeft Richard Purdie <[email protected]> het volgende geschreven:
Quoted 31 lines · Koen Kooi
Quoted 18 lines
Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <[email protected]> het volgende geschreven:
Quoted 15 lines
Quoted 2 lines · Dmitry Eremin-Solenikov
MACHINE_KERNEL_PRwas 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 ?Quoted 4 lines
Quoted 2 lines
"A machine.conf or local.conf can increase
MACHINE_KERNEL_PRto 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...
Quoted 4 lines
Quoted 1 line
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
Quoted 6 lines · Richard Purdie
Quoted 2 lines
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.
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] 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
Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
Quoted 5 lines
Quoted 3 lines · Richard Purdie
Quoted 2 lines
This patch improves the current situation and I don't foresee the autoPR code working soon
Quoted 8 lines
Quoted 3 lines
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
Quoted 11 lines · Koen Kooi
Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
Quoted 9 lines
Quoted 6 lines · Richard Purdie
Quoted 2 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 2 lines
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
Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
Quoted 31 lines · Koen Kooi
Quoted 11 lines
Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
Quoted 9 lines
Quoted 6 lines · Richard Purdie
Quoted 2 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
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
On Thu, Oct 20, 2011 at 09:29, Koen Kooi <[email protected]> wrote:
...
Quoted 7 lines
Quoted 5 lines
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.
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] 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
In reply to Koen Kooi2011/10/20 Koen Kooi <[email protected]>
Quoted 40 lines
Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
Quoted 31 lines · Koen Kooi
Quoted 11 lines
Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
Quoted 9 lines
Quoted 6 lines · Richard Purdie
Quoted 2 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 5 lines
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
Re: [PATCH 2/5] kernel.bbclass: respect MACHINE_KERNEL_PR
In reply to Koen KooiQuoted 39 lines · Koen Kooi
Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
Quoted 31 lines · Koen Kooi
Quoted 11 lines
Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
Quoted 9 lines
Quoted 6 lines · Richard Purdie
Quoted 2 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
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
Op 20 okt. 2011, om 14:38 heeft Richard Purdie het volgende geschreven:
Quoted 44 lines · Koen Kooi
Quoted 39 lines
Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
Quoted 31 lines · Koen Kooi
Quoted 11 lines
Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
Quoted 9 lines
Quoted 6 lines · Richard Purdie
Quoted 2 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 8 lines
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
On Thu, Oct 20, 2011 at 10:54, Koen Kooi <[email protected]> wrote:
...
Quoted 4 lines
Quoted 2 lines
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.
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] 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
Op 20 okt. 2011, om 15:02 heeft Otavio Salvador het volgende geschreven:
Quoted 11 lines · Koen Kooi
...
Quoted 4 lines
Quoted 2 lines
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
In reply to Koen KooiQuoted 52 lines · Koen Kooi
Op 20 okt. 2011, om 14:38 heeft Richard Purdie het volgende geschreven:
Quoted 50 lines · Koen Kooi
Quoted 39 lines
Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
Quoted 31 lines · Koen Kooi
Quoted 11 lines
Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
Quoted 9 lines
Quoted 6 lines · Richard Purdie
Quoted 2 lines
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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 2 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
Quoted 2 lines
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
In reply to Dmitry Eremin-SolenikovAs 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.
--- meta/classes/kernel.bbclass | 40 ++++++++++++++++++++++++---------------- 1 files changed, 24 insertions(+), 16 deletions(-)
meta/classes/kernel.bbclass +24 -16
@@ -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
Signature · 1 line
1.7.2.5
Re: [PATCH 3/5] kernel.bbclass: move uImage handling to separate task
This was nack'ed but I don't remember why; Richard?
Quoted 76 lines · 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 <[email protected]>---
meta/classes/kernel.bbclass | 40 ++++++++++++++++++++++++----------------1 files changed, 24 insertions(+), 16 deletions(-)meta/classes/kernel.bbclass +0
-0@@ -486,6 +486,30 @@ do_sizecheck() {addtask sizecheck before
do_installafterdo_compilemeta/classes/kernel.bbclass +24
-0+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"
meta/classes/kernel.bbclass +0
-0@@ -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 -earch/${ARCH}/boot/uImage; then
- cparch/${ARCH}/boot/uImage${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- elif test -earch/${ARCH}/boot/compressed/vmlinux; then
- ${OBJCOPY} -O binary -R .note -R .comment -Sarch/${ARCH}/boot/compressed/vmlinuxlinux.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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] 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
Quoted 1 line · Otavio Salvador
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.
Quoted 82 lines
Quoted 76 lines · 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<[email protected]>--- meta/classes/kernel.bbclass | 40 ++++++++++++++++++++++++---------------- 1 files changed, 24 insertions(+), 16 deletions(-)meta/classes/kernel.bbclass +24
-17@@ -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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 3/5] kernel.bbclass: move uImage handling to separate task
In reply to Dmitry Eremin-SolenikovQuoted 3 lines · 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.
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
Quoted 73 lines
Signed-off-by Dmitry Eremin-Solenikov <[email protected]>---
meta/classes/kernel.bbclass | 40 ++++++++++++++++++++++++----------------1 files changed, 24 insertions(+), 16 deletions(-)meta/classes/kernel.bbclass +0
-0@@ -486,6 +486,30 @@ do_sizecheck() {addtask sizecheck before
do_installafterdo_compilemeta/classes/kernel.bbclass +24
-0+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"
meta/classes/kernel.bbclass +0
-0@@ -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 -earch/${ARCH}/boot/uImage; then
- cparch/${ARCH}/boot/uImage${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
- elif test -earch/${ARCH}/boot/compressed/vmlinux; then
- ${OBJCOPY} -O binary -R .note -R .comment -Sarch/${ARCH}/boot/compressed/vmlinuxlinux.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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
PATCH 4/5 kernel.bbclass: handle .cis firmware
In reply to Dmitry Eremin-Solenikov.cis firmware files are used by kernel to patch incorrect CIS fir PCMCIA cards. Create respective packages.
--- meta/classes/kernel.bbclass | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
meta/classes/kernel.bbclass +1 -0
@@ -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
Signature · 1 line
1.7.2.5
Re: [PATCH 4/5] kernel.bbclass: handle .cis firmware
Quoted 2 lines · Dmitry Eremin-Solenikov
.cis firmware files are used by kernel to patch incorrect CIS fir PCMCIA cards. Create respective packages.
Looks fine to me.
Quoted 27 lines
Signed-off-by Dmitry Eremin-Solenikov <[email protected]>---
meta/classes/kernel.bbclass | 1 +1 files changed, 1 insertions(+), 0 deletions(-)meta/classes/kernel.bbclass +1
-0@@ -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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Richard Purdie
AppliedRe: [PATCH 4/5] kernel.bbclass: handle .cis firmware
In reply to Dmitry Eremin-SolenikovQuoted 13 lines · 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 <[email protected]>--- meta/classes/kernel.bbclass | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)meta/classes/kernel.bbclass +0
-0
meta/classes/kernel.bbclass python populate_packages_prepend () { · line 456
Quoted 7 lines
meta/classes/kernel.bbclass +1
-0@@ -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
In reply to Dmitry Eremin-SolenikovDrop two unsed files (modules.order and modules.builtin) in do_install to stop the "unshipped files" warning.
--- meta/classes/kernel.bbclass | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
meta/classes/kernel.bbclass +2 -0
@@ -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
Signature · 1 line
1.7.2.5
Re: [PATCH 5/5] kernel.bbclass: remove unshipped files in do_install
Quoted 2 lines · Dmitry Eremin-Solenikov
Drop two unsed files (modules.order and modules.builtin) in
do_installto stop the "unshipped files" warning.
One less warning is a good thing!
Looks good to me, I can add my vote to this one.
Quoted 28 lines
Signed-off-by Dmitry Eremin-Solenikov <[email protected]>---
meta/classes/kernel.bbclass | 2 ++1 files changed, 2 insertions(+), 0 deletions(-)meta/classes/kernel.bbclass +0
-0@@ -108,6 +108,8 @@ kernel_do_install() {unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); thenoe_runmakeDEPMOD=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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Richard Purdie
AppliedRe: [PATCH 5/5] kernel.bbclass: remove unshipped files in do_install
In reply to Dmitry Eremin-SolenikovQuoted 13 lines · Dmitry Eremin-Solenikov
Drop two unsed files (modules.order and modules.builtin) in
do_installto stop the "unshipped files" warning.Signed-off-by Dmitry Eremin-Solenikov <[email protected]>--- meta/classes/kernel.bbclass | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)meta/classes/kernel.bbclass +0
-0
meta/classes/kernel.bbclass kernel_do_install() { · line 115
Quoted 8 lines
meta/classes/kernel.bbclass +2
-0@@ -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
I have sent this in July and it was nacked. See at
https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489
Quoted 28 lines · Dmitry Eremin-Solenikov
Signed-off-by Koen Kooi <[email protected]>Signed-off-by Dmitry Eremin-Solenikov <[email protected]>---
meta/classes/kernel.bbclass | 2 +-1 files changed, 1 insertions(+), 1 deletions(-)meta/classes/kernel.bbclass +0
-0@@ -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 inmodule_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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
Quoted 2 lines · Otavio Salvador
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.
Quoted 34 lines
Quoted 28 lines · Dmitry Eremin-Solenikov
Signed-off-by Koen Kooi<[email protected]>Signed-off-by Dmitry Eremin-Solenikov<[email protected]>--- meta/classes/kernel.bbclass | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)meta/classes/kernel.bbclass +1
-2@@ -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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Op 22 sep. 2011, om 14:25 heeft Dmitry Eremin-Solenikov het volgende geschreven:
Quoted 8 lines · Otavio Salvador
Quoted 2 lines
I have sent this in July and it was nacked. See at
https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489Answering 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
Quoted 7 lines · Koen Kooi
Op 22 sep. 2011, om 14:25 heeft Dmitry Eremin-Solenikov het volgende geschreven:
Quoted 4 lines · Otavio Salvador
Quoted 2 lines
I have sent this in July and it was nacked. See at
https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489
Quoted 6 lines
Quoted 4 lines
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"
Signature · 2 lines
With best wishes Dmitry
Op 22 sep. 2011, om 15:00 heeft Dmitry Eremin-Solenikov het volgende geschreven:
Quoted 8 lines · Koen Kooi
Quoted 7 lines
Op 22 sep. 2011, om 14:25 heeft Dmitry Eremin-Solenikov het volgende geschreven:
Quoted 4 lines · Otavio Salvador
Quoted 2 lines
I have sent this in July and it was nacked. See at
https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
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.
Quoted 14 lines · Koen Kooi
Op 22 sep. 2011, om 15:00 heeft Dmitry Eremin-Solenikov het volgende geschreven:
Quoted 11 lines · Koen Kooi
Quoted 10 lines
Op 22 sep. 2011, om 14:25 heeft Dmitry Eremin-Solenikov het volgende geschreven:
Quoted 7 lines · Otavio Salvador
Quoted 2 lines
I have sent this in July and it was nacked. See at
https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489Answering the original question by Saul:
A possible better question is why perf-dbg is getting generated and what's in it?
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
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
Quoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Op 22 sep. 2011, om 15:28 heeft Bruce Ashfield het volgende geschreven:
Quoted 19 lines · Koen Kooi
Quoted 18 lines
Op 22 sep. 2011, om 15:00 heeft Dmitry Eremin-Solenikov het volgende geschreven:
Quoted 15 lines · Koen Kooi
Quoted 13 lines
Op 22 sep. 2011, om 14:25 heeft Dmitry Eremin-Solenikov het volgende geschreven:
Quoted 8 lines · Otavio Salvador
Quoted 2 lines
I have sent this in July and it was nacked. See at
https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489Answering 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
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 26 lines · Koen Kooi
Op 22 sep. 2011, om 15:28 heeft Bruce Ashfield het volgende geschreven:
Quoted 23 lines · Koen Kooi
Quoted 21 lines
Op 22 sep. 2011, om 15:00 heeft Dmitry Eremin-Solenikov het volgende geschreven:
Quoted 8 lines · Koen Kooi
Quoted 7 lines
Op 22 sep. 2011, om 14:25 heeft Dmitry Eremin-Solenikov het volgende geschreven:
Quoted 4 lines · Otavio Salvador
Quoted 2 lines
I have sent this in July and it was nacked. See at
https://github.com/OSSystems/oe-core/commit/5c53cbf951a11ed92fb2ad0837991db256c11489Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 4 lines
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
Quoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Sorry to bother all of you, what about this patchset?
Signature · 2 lines
With best wishes Dmitry
Quoted 1 line · Dmitry Eremin-Solenikov
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
Richard Purdie
AppliedQuoted 11 lines · Dmitry Eremin-Solenikov
Signed-off-by Koen Kooi <[email protected]>Signed-off-by Dmitry Eremin-Solenikov <[email protected]>--- meta/classes/kernel.bbclass | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)meta/classes/kernel.bbclass +0
-0
meta/classes/kernel.bbclass python populate_packages_prepend () { · line 457
Quoted 8 lines
meta/classes/kernel.bbclass +1
-1@@ -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