On Wed, May 9, 2012 at 11:40 AM, Darren Hart <dvh...@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.ashfi...@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"
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
