On 12-09-11 09:33 AM, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 09:27:50AM -0400, Bruce Ashfield wrote:
On 12-09-11 08:37 AM, Martin Jansa wrote:
On Tue, Sep 11, 2012 at 08:31:42AM -0400, Bruce Ashfield wrote:
On 12-09-11 02:59 AM, Martin Jansa wrote:
On Mon, Sep 10, 2012 at 8:11 PM, Bruce Ashfield
<bruce.ashfi...@windriver.com> wrote:
Updating to 3.4.10 which has been soaking for a bit now, as well
as picking up the following meta commits from Tom Z:
a82db2f meta: have systemtap use kprobes and uprobes feature
d5d5b80 meta: add kprobes support to ktypes/standard
b32d373 meta: add kprobes feature
d40ed99 meta: have uprobe feature use uprobe.cfg
a69d1db meta: add uprobe.cfg
Signed-off-by: Bruce Ashfield<bruce.ashfi...@windriver.com>
---
meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb | 8 ++++----
meta/recipes-kernel/linux/linux-yocto_3.4.bb | 16 ++++++++--------
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
index b2620ea..3b36378 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb
@@ -3,14 +3,14 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH = "standard/preempt-rt/base"
KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
-LINUX_VERSION ?= "3.4.9"
+LINUX_VERSION ?= "3.4.10"
LINUX_KERNEL_TYPE = "preempt-rt"
KMETA = "meta"
-SRCREV_machine ?= "9032b1e9daf5b4396f939981c3be95f67802d18c"
-SRCREV_machine_qemuppc ?= "08ce190232f89303772b6591ca7daaf2820eb74e"
-SRCREV_meta ?= "463299bc2e533e1bd38b0053ae7b210980f269c3"
+SRCREV_machine ?= "a35693b1287c0e50cdca33a1b95af0ff48b43cd0"
+SRCREV_machine_qemuppc ?= "85a1190530cb5749f5f831670976b163438dc301"
+SRCREV_meta ?= "d9d5fc63d8b38705036e946ea77d971d95de11ad"
PR = "${INC_PR}.0"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
index 06bcb9a..7258cba 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.4.bb
@@ -3,17 +3,17 @@ require recipes-kernel/linux/linux-yocto.inc
KBRANCH_DEFAULT = "standard/base"
KBRANCH = "${KBRANCH_DEFAULT}"
-SRCREV_machine_qemuarm ?= "84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d"
-SRCREV_machine_qemumips ?= "ba0e336d4527080233c3c410989d4f351529ee4e"
-SRCREV_machine_qemuppc ?= "e82b8a111430e3820b11f507863c4b8e8734ed8e"
-SRCREV_machine_qemux86 ?= "0985844fa6235422c67ef269952fa4e765f252f9"
-SRCREV_machine_qemux86-64 ?= "0985844fa6235422c67ef269952fa4e765f252f9"
-SRCREV_machine ?= "0985844fa6235422c67ef269952fa4e765f252f9"
-SRCREV_meta ?= "463299bc2e533e1bd38b0053ae7b210980f269c3"
+SRCREV_machine_qemuarm ?= "b15e7b1e9b58b9863bd87778775f86cd8d8880ea"
+SRCREV_machine_qemumips ?= "8d5b98f263b5119af2dc30223f311be17173bab9"
+SRCREV_machine_qemuppc ?= "b9a720ca38d298ed457f37d099c85771f9164b19"
+SRCREV_machine_qemux86 ?= "46d8c757b3be1953f30d6745505d24436e2d6844"
+SRCREV_machine_qemux86-64 ?= "46d8c757b3be1953f30d6745505d24436e2d6844"
+SRCREV_machine ?= "46d8c757b3be1953f30d6745505d24436e2d6844"
+SRCREV_meta ?= "a82db2f0fc3ceebf3cb47e9dd05e4856ff9966ab"
Doesn't different SRCREV_machine for each MACHINE cause LOCALCOUNT in
SRCPV incrementing on each MACHINE switch?
They are stored under same key:
sqlite> select * from BB_URI_LOCALCOUNT where key like '%linux-yocto-3.4%';
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_rev|84d8ee32265eea5d60f57a2f70bd3b9a0fb9213d
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/base-linux-yocto_count|16
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto_count|9
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_rev|19f7e43b54aef08d58135ed2a897d77b624b320a
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/common-pc-64/base-linux-yocto_count|7
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_rev|9032b1e9daf5b4396f939981c3be95f67802d18c
git:git.yoctoproject.org.linux-yocto-3.4.gitstandard/preempt-rt/base-linux-yocto-rt_count|10
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_rev|463299bc2e533e1bd38b0053ae7b210980f269c3
git:git.yoctoproject.org.linux-yocto-3.4.gitmeta-linux-yocto-rt_count|8
So I guess if you build linux-yocto-3.4 for qemuarm, qemux86-64, then
switch back to qemuarm you'll see linux-yocto built again, same
source, but different SRCPV (LOCALCOUNT).
That does look to be the case, and it matches what I've observed
over time. I'm not sure of an alternative at the moment, since the
fetcher is such a cranky beast with respect to fetching changes to
the right machine branches.
Why not remove it from SRCREV_FORMAT, keep only meta SRCPV and just bump
PR when SRCREV of some machine kbranch is changed?
I like the sound of it, but as far as I know, wouldn't that fix the
package revision, but cause the fetcher problems ? I've added Richard
to the cc, since I'm not sure what the current status of the fetcher
is in this regard.
If I don't bump the SRCREV for the machines, and just bump the PR,
there's nothing in place to trigger the fetcher when only machine
changes have been made to one of the branches, and conversely there's
PR bump will trigger recipe rebuild and while rebuilding fetcher will
download revision set by SRCREV, why shoudln't it?
It definitely should .. but the fetcher has proven me wrong before.
Only disadvantage I see is that PR bump is "global" so all machines get
rebuilt when you bump it only because of one machine changing SRCREV,
but that's still better then rebuilding without any change in sources at
all.
.. and I staring at this a bit, I think I'm catching up (not enough
coffee this morning and too little sleep).
I think I mentally mangled this to include dropping the machine
SRCREV from the recipe, where you are talking about dropping the
from the PV and SRCREV_FORMAT.
If in fact the fetcher will update the machine SRCREV on a PR bump,
then this should work.
But one stupid question, if machine has been removed from the SRCREV
format, is the fetcher really going to trigger ? A quick look at the
fetcher code doesn't leave me convinced ...
Bruce
Cheers,
no explicit value set to inhibit a machine's SRCREV when you don't
want the end of the branch to be built (I always build the end, but
other layers inhibit SRCREV frequently to throttle their updates).
If there's a better way that keeps the rebuilds to a minimum, but
doesn't break the fetcher and those other use cases .. I'm more than
happy to switch to it :)
Bruce
Current SRCREV_FORMAT doesn't show which branch it was so it doesn't
make it much worse to find what sources were used to build.
Cheers,
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
