[linux-yocto] kernel-yocto: validate_branches questions

[Bruce Ashfield]

On 14-02-18 03:23 PM, Moore, Tysen wrote:
> I looked for the file you requested but did not see it.  Where can I
> find this?  Is it part of the linux kernel WORKDIR?  If so, I greped the
> tree and I don't see it.  Or am I looking in the wrong place?  If I can
> find it I will be sure to pass it on.

What yocto branch are you using ?

It's in the WORKDIR/linux/.meta/ directory.

>
> What I've got are two branches:
> - My KBRANCH branch with the last commit being: (717bdd797)
> - Another branch with the last commit being (c826758fb), then the commit
> (717bdd797)
>
> So the validate_branches does a checkout of master, the goes over these
> two branches and puts them on the commit I wanted--I think this is
> fine.  Then the KMETA check takes place and fails because I do not have
> KMETA defined, thus exiting early and leaving me at master.  The problem
> seems to be the failing of this KMETA that is not defined.  It seems
> like KMETA is required for this to work properly.

KMETA is definitely not required, I do korg based builds all the time,
all without a meta branch, so we can make this work, I just need to know
what has broken .. with a bit more information, we'll get there.

Bruce

>
> ------------------------------------------------------------------------
> *From:* Bruce Ashfield [bruce.ashfield at windriver.com]
> *Sent:* Tuesday, February 18, 2014 2:29 PM
> *To:* Moore, Tysen; linux-yocto at yoctoproject.org
> *Subject:* Re: [linux-yocto] kernel-yocto: validate_branches questions
>
> On 14-02-18 10:51 AM, Moore, Tysen wrote:
>
> XSe Logo
>
> *XS Embedded LLC*
> 29065 Cabot Drive, Suite 200
> Novi, MI 48377
> USA
>
> Phone 	+1 (248) 209 - 6613
> Fax 	+1 (248) 281 - 7020
>
>
> www.xs-embedded.com <http://www.xs-embedded.com>
> Tysen.Moore at xs-embedded.com <mailto:Tysen.Moore at xs-embedded.com>
>
> *:::::::::: based.on.visions ::::::::::*
>
> XS Embedded LLC
> Managing Director: Joachim Kobinger
>
> Confidentiality Notice: This e-mail message, including any attachments,
> is for the sole use of the intended recipient(s) and may contain
> confidential and privileged information. Any unauthorized review, use,
> disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by return e-mail and destroy all
> copies of the original message.
>
>
>> Bruce,
>>
>> Thanks for the fast response.  I only posted the question yesterday.
>
> I like to reply quickly to problems :)
>
>>
>> The "KMETA Check" that I am referring to is:
>>     ## KMETA branch validation
>>      meta_head=`git show-ref -s --heads ${KMETA}`
>>      target_meta_head="${SRCREV_meta}"
>>     git show-ref --quiet --verify -- "refs/heads/${KMETA}"
>>     if [ $? -eq 1 ]; then
>>         return                            #<<<<<<<<<<<<<<< EXITS HERE
>>     fi
>>
>> Because with KMETA not defined here it exists early.  The problem is
>> that the earlier "SRCREV loop" starts with, "git checkout -q master".
>> Since KMETA is not defined and we exit early the code that follows the
>> KMETA check to change back to KBRANCH is not executed.
>
> Correct. But that's supposed to be safe, the checkout of the machine
> branch at the bottom of the routine is not supposed to be the last
> manipulation of the branches. You should still end up on the right
> branch when the build happens.
>
> I'm driving to understand why that is happening.
>
> Can you share some specific details ?  If this is master, and you
> go into the kernel's source directory tmp/work/*/linux/ and cat
> .meta/top_tgt, that should point to a generated file, what are the
> contents of that generated description.
>
> One solution would be to allow that final git checkout to run (as
> you mentioned), but if other manipulations of the tree happen,
> you'll still be broken, and I want to avoid that.
>
> Bruce
>
>>
>> The only workaround I've come up with is very hackish--embarrassing to
>> post;-)
>> do_validate_branches_prepend() {
>>     KMETA="${KBRANCH}"
>>     SRCREV_meta="${SRCREV}"
>>     SRCREV_machine="${SRCREV}"
>> }
>> do_validate_branches_append() {
>>     KMETA=""
>>     SRCREV_meta=""
>>     SRCREV_machine=""
>> }
>> [As you can imagine I'd prefer not to use this hack.]
>>
>> The problem is that if I do not clear KMETA the configme (kgit-meta
>> and friends) call later fails.  The kernel_configme code allows KMETA
>> to be undefined but it is almost like the validate_branches is coded
>> without that same option.  Shouldn't the KMETA "check" code listed
>> above be skipped when KMETA is not defined? I think this change to the
>> validate_branches code would fix this use case.  I don't think it
>> would break other use cases, but I am rather green with Yocto.
>>
>> Thanks again for the detailed description and help.
>>
>> Tysen
>>
>> XSe Logo
>>
>> *XS Embedded LLC*
>> 29065 Cabot Drive, Suite 200
>> Novi, MI 48377
>> USA
>>
>> Phone 	+1 (248) 209 - 6613
>> Fax 	+1 (248) 281 - 7020
>>
>>
>> www.xs-embedded.com <http://www.xs-embedded.com>
>> Tysen.Moore at xs-embedded.com <mailto:Tysen.Moore at xs-embedded.com>
>>
>> *:::::::::: based.on.visions ::::::::::*
>>
>> XS Embedded LLC
>> Managing Director: Joachim Kobinger
>>
>> Confidentiality Notice: This e-mail message, including any
>> attachments, is for the sole use of the intended recipient(s) and may
>> contain confidential and privileged information. Any unauthorized
>> review, use, disclosure or distribution is prohibited. If you are not
>> the intended recipient, please contact the sender by return e-mail and
>> destroy all copies of the original message.
>>
>>
>