kern-tools: fix meta-intel builds
cover kern-tools: fix meta-intel builds
Richard/Saul,
This fixes a problem reported by Tom and Darren when the latest tools updates were used against meta intel. Some optional code that supported merge meta and BSP branches wasn't handling the case where a BSP layer might not be tracking the HEAD of the meta branch, and hence blowing up its test to see if the meta branch needs to be thawed.
The fix was simple. Adjust the threshold for declaring the meta content global.
Cheers,
Bruce
The following changes since commit 8afd5747802c4eb0e8296e440bd7366393595f8e:
Bruce Ashfield (1):
kernel-yocto: export GUILT_BASE
are available in the git repository at:
git://git.pokylinux.org/poky-contrib zedd/kern-tools
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kern-tools
Bruce Ashfield (1):
kern-tools: checkpoint restoration for reset branches
.../kern-tools/kern-tools-native_git.bb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
PATCH 1/1 kern-tools: checkpoint restoration for reset branches
Updating the SRCREV to pickup the following fix:
createme: fix checkpoint restoration for reset branches
The meta branch can optionally be merged out to BSP branches. This removes the need to restore the checkpoint when working with the tree. The way it detects the merge is by checking to see how many branches contain the meta data. If there's more than one, the branch was was merged out.
Unless you are a BSP that isn't tracking the latest meta, and you get meta and meta-orig created. That's two branches and the code opts to not restore the checkpoint, which leads to configuration errors.
The fix is simple. We allow for 2 or less branches with meta, and will still restore the checkpoint. Three and up, we won't.
--- .../kern-tools/kern-tools-native_git.bb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1 -1
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8 DEPENDS = "git-native guilt-native" -SRCREV = "9bb704df0a86578b8ae1f4c85e45089bef28e026" +SRCREV = "de3649840e8e3ca25bc79d2444f04a1b158a1769" PR = "r12" PV = "0.1+git${SRCPV}"
Signature · 1 line
1.7.0.4
Re: [PATCH 1/1] kern-tools: checkpoint restoration for reset branches
Quoted 9 lines · Bruce Ashfield
Updating the SRCREV to pickup the following fix:
createme: fix checkpoint restoration for reset branches
The meta branch can optionally be merged out to BSP branches. This removes the need to restore the checkpoint when working with the tree. The way it detects the merge is by checking to see how many branches contain the meta data. If there's more than one, the branch was was merged out.
Quoted 7 lines
Unless you are a BSP that isn't tracking the latest meta, and you get meta and meta-orig created. That's two branches and the code opts to not restore the checkpoint, which leads to configuration errors.
The fix is simple. We allow for 2 or less branches with meta, and will still restore the checkpoint. Three and up, we won't.
Uhm... am I the only one for whom this language is really confusing? "merged out" ?
"restore the checkpoint" ?
Why does a BSP using a different meta SRCREV get two meta branches?
The fix of incrementing the allowed count of meta branches honestly feels like a bandaid. Why do we create two in the first place?
Regardless, this is a blocker for working with meta-intel, so we need this in. But it does seem to me that a more direct solution may be needed. Bruce, can you help fill me in re. the above?
--
Darren
Quoted 18 lines
Signed-off-by Bruce Ashfield <[email protected]>--- .../kern-tools/kern-tools-native_git.bb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1
-1@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8 DEPENDS = "git-native guilt-native" -SRCREV = "9bb704df0a86578b8ae1f4c85e45089bef28e026" +SRCREV = "de3649840e8e3ca25bc79d2444f04a1b158a1769" PR = "r12" PV = "0.1+git${SRCPV}"
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Re: [PATCH 1/1] kern-tools: checkpoint restoration for reset branches
Quoted 16 lines · Darren Hart
Quoted 13 lines · Bruce Ashfield
Updating the SRCREV to pickup the following fix:
createme: fix checkpoint restoration for reset branches
The meta branch can optionally be merged out to BSP branches. This removes the need to restore the checkpoint when working with the tree. The way it detects the merge is by checking to see how many branches contain the meta data. If there's more than one, the branch was was merged out.
Unless you are a BSP that isn't tracking the latest meta, and you get meta and meta-orig created. That's two branches and the code opts to not restore the checkpoint, which leads to configuration errors.
Quoted 7 lines
Quoted 3 lines
The fix is simple. We allow for 2 or less branches with meta, and will still restore the checkpoint. Three and up, we won't.
Uhm... am I the only one for whom this language is really confusing? "merged out" ?
"restore the checkpoint" ?
I could be more verbose, but it's like reading a kernel -mm commit. I don't grok everything they write, but they aren't writing it for me as a -mm newbie.
Quoted 4 lines
Why does a BSP using a different meta SRCREV get two meta branches?
The fix of incrementing the allowed count of meta branches honestly feels like a bandaid. Why do we create two in the first place?
do_validate_branches() has to check if the HEAD of meta matches the meta SRCREV that the BSP defines. If they don't match, it saves the old branch as $branch-orig. So you have two branches, with the base meta commit (which is what is tested). I don't want to destroy any branches, since there is value in keeping them around.
The tools are actually separate to the bitbake bindings, so they don't expect this to happen. I could destroy the old branch in do_validate_branches, but that's not a solution I particularly liked. It was easier to add some flexibility to
the tools.
Cheers,
Bruce
Quoted 36 lines
Regardless, this is a blocker for working with meta-intel, so we need this in. But it does seem to me that a more direct solution may be needed. Bruce, can you help fill me in re. the above?
--
DarrenQuoted 15 lines
Signed-off-by Bruce Ashfield <[email protected]>---
.../kern-tools/kern-tools-native_git.bb | 2 +-1 files changed, 1 insertions(+), 1 deletions(-)meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +0
-0@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8DEPENDS = "git-native guilt-native"
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1
-1-SRCREV = "9bb704df0a86578b8ae1f4c85e45089bef28e026" +SRCREV = "de3649840e8e3ca25bc79d2444f04a1b158a1769"Quoted 3 lines
PR = "r12"
PV = "0.1+git${SRCPV}"--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel_______________________________________________
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 1/1] kern-tools: checkpoint restoration for reset branches
Quoted 21 lines · Bruce Ashfield
Quoted 20 lines · Darren Hart
Quoted 16 lines · Bruce Ashfield
Updating the SRCREV to pickup the following fix:
createme: fix checkpoint restoration for reset branches
The meta branch can optionally be merged out to BSP branches. This removes the need to restore the checkpoint when working with the tree. The way it detects the merge is by checking to see how many branches contain the meta data. If there's more than one, the branch was was merged out.
Unless you are a BSP that isn't tracking the latest meta, and you get meta and meta-orig created. That's two branches and the code opts to not restore the checkpoint, which leads to configuration errors.
The fix is simple. We allow for 2 or less branches with meta, and will still restore the checkpoint. Three and up, we won't.
Quoted 7 lines
Quoted 3 lines
Uhm... am I the only one for whom this language is really confusing? "merged out" ?
"restore the checkpoint" ?I could be more verbose, but it's like reading a kernel -mm commit. I don't grok everything they write, but they aren't writing it for me as a -mm newbie.
So, who exactly is the target audience for the above text? I'm not sure that "really confusing" does it justice: from my point of view (though admittedly I am very far from being an eleet k3rn3l h4x0r) it just looks like gibberish. If it's going into oe-core then I would have hoped that the checkin comment would be intelligible to oe-core users at large, not just those who are schooled in the mysterious ways of some particular subgroup.
p.
Re: [PATCH 1/1] kern-tools: checkpoint restoration for reset branches
Quoted 30 lines · Phil Blundell
Quoted 21 lines · Bruce Ashfield
Quoted 20 lines · Darren Hart
Quoted 16 lines · Bruce Ashfield
Updating the SRCREV to pickup the following fix:
createme: fix checkpoint restoration for reset branches
The meta branch can optionally be merged out to BSP branches. This removes the need to restore the checkpoint when working with the tree. The way it detects the merge is by checking to see how many branches contain the meta data. If there's more than one, the branch was was merged out.
Unless you are a BSP that isn't tracking the latest meta, and you get meta and meta-orig created. That's two branches and the code opts to not restore the checkpoint, which leads to configuration errors.
The fix is simple. We allow for 2 or less branches with meta, and will still restore the checkpoint. Three and up, we won't.
Quoted 7 lines
Quoted 3 lines
Uhm... am I the only one for whom this language is really confusing? "merged out" ?
"restore the checkpoint" ?I could be more verbose, but it's like reading a kernel -mm commit. I don't grok everything they write, but they aren't writing it for me as a -mm newbie.
Quoted 7 lines
So, who exactly is the target audience for the above text? I'm not sure that "really confusing" does it justice: from my point of view (though admittedly I am very far from being an eleet k3rn3l h4x0r) it just looks like gibberish. If it's going into oe-core then I would have hoped that the checkin comment would be intelligible to oe-core users at large, not just those who are schooled in the mysterious ways of some particular subgroup.
It's a quote from the kern-tools commit log. I could just put: 'fixes stuff', but that's not good either. Writing a novel isn't good either.
I'm not sure why everyone is having such an issue with this, there's many other examples of commits like this, and everyone sits in a glass house in this regard.
I can re-work it of course, I wrote it very late at night to fix a fairly blocking
bug, so everyone cutting a little bit of slack would be appreciated.
Cheers,
Bruce
Quoted 9 lines
p.
_______________________________________________
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 1/1] kern-tools: checkpoint restoration for reset branches
Quoted 39 lines · Bruce Ashfield
Quoted 30 lines · Phil Blundell
Quoted 21 lines · Bruce Ashfield
Quoted 20 lines · Darren Hart
Quoted 16 lines · Bruce Ashfield
Updating the SRCREV to pickup the following fix:
createme: fix checkpoint restoration for reset branches
The meta branch can optionally be merged out to BSP branches. This removes the need to restore the checkpoint when working with the tree. The way it detects the merge is by checking to see how many branches contain the meta data. If there's more than one, the branch was was merged out.
Unless you are a BSP that isn't tracking the latest meta, and you get meta and meta-orig created. That's two branches and the code opts to not restore the checkpoint, which leads to configuration errors.
The fix is simple. We allow for 2 or less branches with meta, and will still restore the checkpoint. Three and up, we won't.
Quoted 7 lines
Quoted 3 lines
Uhm... am I the only one for whom this language is really confusing? "merged out" ?
"restore the checkpoint" ?I could be more verbose, but it's like reading a kernel -mm commit. I don't grok everything they write, but they aren't writing it for me as a -mm newbie.
Quoted 7 lines
So, who exactly is the target audience for the above text? I'm not sure that "really confusing" does it justice: from my point of view (though admittedly I am very far from being an eleet k3rn3l h4x0r) it just looks like gibberish. If it's going into oe-core then I would have hoped that the checkin comment would be intelligible to oe-core users at large, not just those who are schooled in the mysterious ways of some particular subgroup.
Quoted 8 lines
It's a quote from the kern-tools commit log. I could just put: 'fixes stuff', but that's not good either. Writing a novel isn't good either.
I'm not sure why everyone is having such an issue with this, there's many other examples of commits like this, and everyone sits in a glass house in this regard.
I can re-work it of course, I wrote it very late at night to fix a
I rewrote the SRCREV update commit into something more legible. It's on the same branch as the original pull request.
Cheers,
Bruce
Quoted 22 lines
fairly blocking
bug, so everyone cutting a little bit of slack would be appreciated.Cheers,
Bruce
Quoted 9 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
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"
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Re: [PATCH 1/1] kern-tools: checkpoint restoration for reset branches
Quoted 44 lines · Bruce Ashfield
Quoted 42 lines · Bruce Ashfield
Quoted 30 lines · Phil Blundell
Quoted 21 lines · Bruce Ashfield
Quoted 20 lines · Darren Hart
Quoted 16 lines · Bruce Ashfield
Updating the SRCREV to pickup the following fix:
createme: fix checkpoint restoration for reset branches
The meta branch can optionally be merged out to BSP branches. This removes the need to restore the checkpoint when working with the tree. The way it detects the merge is by checking to see how many branches contain the meta data. If there's more than one, the branch was was merged out.
Unless you are a BSP that isn't tracking the latest meta, and you get meta and meta-orig created. That's two branches and the code opts to not restore the checkpoint, which leads to configuration errors.
The fix is simple. We allow for 2 or less branches with meta, and will still restore the checkpoint. Three and up, we won't.
Quoted 7 lines
Quoted 3 lines
Uhm... am I the only one for whom this language is really confusing? "merged out" ?
"restore the checkpoint" ?I could be more verbose, but it's like reading a kernel -mm commit. I don't grok everything they write, but they aren't writing it for me as a -mm newbie.
Quoted 7 lines
So, who exactly is the target audience for the above text? I'm not sure that "really confusing" does it justice: from my point of view (though admittedly I am very far from being an eleet k3rn3l h4x0r) it just looks like gibberish. If it's going into oe-core then I would have hoped that the checkin comment would be intelligible to oe-core users at large, not just those who are schooled in the mysterious ways of some particular subgroup.
It's a quote from the kern-tools commit log. I could just put: 'fixes stuff', but that's not good either. Writing a novel isn't good either.
Quoted 8 lines
Quoted 5 lines
I'm not sure why everyone is having such an issue with this, there's many other examples of commits like this, and everyone sits in a glass house in this regard.
I can re-work it of course, I wrote it very late at night to fix a
I rewrote the SRCREV update commit into something more legible. It's on the same branch as the original pull request.
Thanks, I think this is a timely reminder to everyone to think about the people who might read a commit message and try and make it meaningful to them. I've merged the revised version to master.
Cheers,
Richard