[OE-core] [PATCH 1/4] linux-yocto: make KBRANCH the exception and not the rule

[Bruce Ashfield]

On Sat, Aug 18, 2012 at 8:07 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Wed, 2012-08-15 at 16:06 -0400, Bruce Ashfield wrote:
>> The kernel branch is no longer required by the yocto-kern-tools
>> to locate BSP feature descriptions (it is the MACHINE:KTYPE
>> descriptor), so we no longer require that the BSP branch be
>> explicitly set.
>>
>> If a kernel branch is explicitly set, it is now used to trigger
>> a checks to ensure that the branch really is being built.
>> Otherwise the branch that the machine description creates will
>> be built (just as it always was).
>>
>> This further simplies the use and configuration of a linux-yocto
>> based kernel recipe.
>
> [...]
>
>>
>> -     # We have SRCREVs and we have branches so validation can continue!
>> -     current=`git branch |grep \*|sed 's/^\* //'`
>> -     if [ -n "$target_branch_head" ] && [ "$branch_head" != "$target_branch_head" ] &&
>> -           [ "$target_branch_head" != "AUTOINC" ]; then
>> -             ref=`git show ${target_branch_head} 2>&1 | head -n1 || true`
>> -             if [ "$ref" = "fatal: bad object ${target_meta_head}" ]; then
>> -                     echo "ERROR ${target_branch_head} is not a valid commit ID."
>> -                     echo "The kernel source tree may be out of sync"
>> -                     exit 1
>> -             else
>> -                     echo "Forcing branch $current to ${target_branch_head}"
>> -                     git branch -m $current $current-orig
>> -                     git checkout -b $current ${target_branch_head}
>> -             fi
>> +     containing_branches=`git branch --contains $target_branch_head | sed 's/^..//'`
>> +     if [ -z "$containing_branches" ]; then
>> +             echo "ERROR: SRCREV was set to \"$target_branch_head\", but no branches"
>> +             echo "       contain this commit"
>> +             exit 1
>> +     fi
>> +     ref=`git show ${target_branch_head} 2>&1 | head -n1 || true`
>> +     if [ "$ref" = "fatal: bad object ${target_meta_head}" ]; then
>> +         echo "ERROR ${target_branch_head} is not a valid commit ID."
>> +         echo "The kernel source tree may be out of sync"
>> +         exit 1
>>       fi
>
> There is a bit of uncertainty flying around at the moment about why
> these changes are failing on the autobuilder. For example:
>
> http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/560/steps/shell_138/logs/stdio
>
> Log data follows:
> | DEBUG: Executing shell function do_validate_branches
> | ERROR: SRCREV was set to "1c17c082b6ee565acc176cde5be835ac4269817b", but no branches
> |        contain this commit
> | ERROR: Function failed: do_validate_branches
>
> It looks like:
>
> http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/fetch2/git.py?id=64662290d3e7deb0b6093b3959c3f3eddb873893
>
> doesn't totally fix the problem. It allows the correct revisions to be
> found and sets alternatives correctly but imports the wrong branch
> config.

bugger. eh. But that's what I saw on the autobuilder as well. There are
two repos, one is being updated, another isn't and the older/non updated
one isn't being updated.

But what's causing the inconsistency in the .git and no ".git" repos ? i.e
aren't all the SRC_URIs now the same ? So why would one be fetched
into in the downloads, and the other used for the build ?

>
> I don't really want to have to require a patched git binary so we may
> end up having to rebuild the branch structure manually.

Where would we have to do the branch rebuild ? From what I saw, in the
broken repo, the blobs aren't even present .. so even if you know the
branch names, you can't set the SRCREV and just dump it in the branch
ref (which I've tried in the past, and it just breaks in equally impressive
ways as).

>
> I guess the older code cared less about the branch name and more about
> the revisions being present.

And the old code was wrong .. or at least not very good. It misses scenarios
where new BSPs are created, or other branches selected to be built by the
board descriptions. Human's working on a kernel, work on branches, not
git hashes and floating branches .. so this actually allows a BSP developer to
control the content, and have the build system build what he wants.

I can say is that this works fine here, has been working for over two months
within Wind River and never a failure seen, but the fetch infrastructure is
configured differently here.

We can skip the changes for 1.3, but they are a big step forward in the tools
and flexibility for working with the tree .. which was one of the macro goals
that I for 1.3.

Cheers,

Bruce

>
> Cheers,
>
> Richard
>
>
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at 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"