[PATCH 0/1] kern-tools: fix meta-intel builds

[PATCH 0/1] kern-tools: fix meta-intel builds

[Bruce Ashfield]

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.

cc: Tom Zanussi <tom.zanussi@intel.com>
cc: Darren Hart <dvhart@linux.intel.com>

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

[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.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 .../kern-tools/kern-tools-native_git.bb            |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index b6fab39..b5e203e 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -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}"
 
-- 
1.7.0.4

Re: [PATCH 1/1] kern-tools: checkpoint restoration for reset branches

[Darren Hart]

On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
> 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.
> 

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

> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  .../kern-tools/kern-tools-native_git.bb            |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> index b6fab39..b5e203e 100644
> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> @@ -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}"
>  

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: [PATCH 1/1] kern-tools: checkpoint restoration for reset branches

[Bruce Ashfield]

On Wed, May 9, 2012 at 11:40 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>
>
> On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
>> 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.
>>
>
> 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.

> 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

>
> 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
>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>>  .../kern-tools/kern-tools-native_git.bb            |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> index b6fab39..b5e203e 100644
>> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> @@ -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}"
>>
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
>
> _______________________________________________
> 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/1] kern-tools: checkpoint restoration for reset branches

[Phil Blundell]

On Wed, 2012-05-09 at 11:48 -0400, Bruce Ashfield wrote:
> On Wed, May 9, 2012 at 11:40 AM, Darren Hart <dvhart@linux.intel.com> wrote:
> >
> >
> > On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
> >> 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.
> >>
> >
> > 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

[Bruce Ashfield]

On Wed, May 9, 2012 at 12:02 PM, Phil Blundell <philb@gnu.org> wrote:
> On Wed, 2012-05-09 at 11:48 -0400, Bruce Ashfield wrote:
>> On Wed, May 9, 2012 at 11:40 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>> >
>> >
>> > On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
>> >> 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.
>> >>
>> >
>> > 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.

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

>
> p.
>
>
>
> _______________________________________________
> 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/1] kern-tools: checkpoint restoration for reset branches

[Bruce Ashfield]

On Wed, May 9, 2012 at 12:11 PM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Wed, May 9, 2012 at 12:02 PM, Phil Blundell <philb@gnu.org> wrote:
>> On Wed, 2012-05-09 at 11:48 -0400, Bruce Ashfield wrote:
>>> On Wed, May 9, 2012 at 11:40 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>>> >
>>> >
>>> > On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
>>> >> 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.
>>> >>
>>> >
>>> > 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.
>
> 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

> fairly blocking
> bug, so everyone cutting a little bit of slack would be appreciated.
>
> Cheers,
>
> Bruce
>
>>
>> p.
>>
>>
>>
>> _______________________________________________
>> 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"



-- 
"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

[Richard Purdie]

On Wed, 2012-05-09 at 12:42 -0400, Bruce Ashfield wrote:
> On Wed, May 9, 2012 at 12:11 PM, Bruce Ashfield
> <bruce.ashfield@gmail.com> wrote:
> > On Wed, May 9, 2012 at 12:02 PM, Phil Blundell <philb@gnu.org> wrote:
> >> On Wed, 2012-05-09 at 11:48 -0400, Bruce Ashfield wrote:
> >>> On Wed, May 9, 2012 at 11:40 AM, Darren Hart <dvhart@linux.intel.com> wrote:
> >>> >
> >>> >
> >>> > On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
> >>> >> 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.
> >>> >>
> >>> >
> >>> > 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.
> >
> > 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.

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