[linux-yocto] linux-yocto-3.10 emgd-1.18 checking out as standard/base

[Hart, Darren]

On 3/14/14, 19:57, "Bruce Ashfield" <bruce.ashfield at gmail.com> wrote:

>On Fri, Mar 14, 2014 at 5:40 PM, Hart, Darren <darren.hart at intel.com>
>wrote:
>> On 3/14/14, 13:18, "Hart, Darren" <darren.hart at intel.com> wrote:
>>
>>>Trying to build minnow/dora with the latest linux-yocto 3.10-ltsi
>>>including the recent emgd fixes results in a build source tree that has
>>>no
>>>emgd patches applied.
>>>
>>>The recipe has good SRCREVs:
>>>
>>>Minnow linux-yocto_3.10.bbappend:
>>>
>>>SRC_URI_minnow =
>>>"git://git.yoctoproject.org/linux-yocto-3.10;protocol=git;nocheckout=1;b
>>>ra
>>>n
>>>ch=${KBRANCH},${KMETA},emgd-1.18;name=machine,meta,emgd"
>>>
>>>SRCREV_machine_pn-linux-yocto_minnow ?=
>>>"78afd3095c9b37efbbfbfdc25eb3833ef3c6a718"
>>>SRCREV_meta_pn-linux-yocto_minnow ?=
>>>"6e0e756d51372c8b176c5d1e6f786545bceed351"
>>>SRCREV_emgd_pn-linux-yocto_minnow ?=
>>>"42d5e4548e8e79e094fa8697949eed4cf6af00a3"
>>>
>>>
>>>I verified with bitbake -e that is indeed using the correct SRC_URI and
>>>SRCREVs.
>>>
>>>After a clean all and fresh linux-yocto build:
>>>
>>>$ cd
>>>tmp/work/minnow-poky-linux/linux-yocto/3.10.32+gitAUTOINC+6e0e756d51_78a
>>>fd
>>>3
>>>095c-r0/linux
>>>$ git rev-parse HEAD
>>>78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
>>>
>>>This is the tip of standard/base. Appears as though the ddm-emgd feature
>>>was not applied. But...
>>>
>>>$ grep emgd .meta/meta-series
>>>   # _mark drm-emgd-1.18.scc start
>>># _kconf hardware
>>>/build/yocto/dora/minnow_20131203165453/build/tmp/work/minnow-poky-linux
>>>/l
>>>i
>>>nux-yocto/3.10.32+gitAUTOINC+6e0e756d51_78afd3095c-r0/linux/.meta/cfg/ke
>>>rn
>>>e
>>>l-cache/features/drm-emgd/drm-emgd.cfg
>>># _git merge emgd-1.18
>>>   # _mark drm-emgd-1.18.scc en
>>>
>>>
>>>So it did attempt to merge in the branch...
>>>
>>>$ git rev-parse emgd-1.18
>>>78afd3095c9b37efbbfbfdc25eb3833ef3c6a718
>>>
>>>
>>>Well... That's not good, emgd-1.18 is the same as standard/base in this
>>>checkout (although clearly not in the upstream repository). Any ideas
>>>what
>>>is going on here? I would guess one of my SRCREVs was wrong (or possibly
>>>the name of the variable in the recipe), but they all seem correct to
>>>me,
>>>and no warnings are issued that I have seen.
>>
>>
>> OK, I found it. It's rather ugly.
>>
>> do_validate_branches resets the HEAD of any branch that contains
>> SRCREV_machine. So if a feature branch is current with standard/base for
>> example, that feature branch gets reset to standard/base.
>
>Yep, and the answer is, don't set SRCREV to that value :)

Uhm... That can't be right...

>
>>
>> Why on earth does this blob of time suckage exist?
>
>Check the mailing list archives, I've answered this about 3 times :)

Then it warrants some commentary in the code itself that explains the
necessity. Very few people are as close to this stuff as I am, and if it
is still non-intuitive to me, we're likely to be running into this many
more times in the future.

>
>It has to work like this, it is fixing a specific set of bugs that
>were reported, and
>changes can break that workflow.
>
>The point is that *any* branch can be built in the tree, since the .scc
>files
>describe the BSP and the BSP descriptions have the branching information.
>
>The SRCREV and branch are in the recipe to keep the fetcher happy, but
>to make them actually *mean* something to the build (like any other git
>based build .. which resets the tree to SRCREV) then any branch that
>contains that SRCREV is reset to that same point. So no matter where a
>BSP wanders, it finds what you've specified as the SRCREV.
>
>Moral of the story, make sure that your SRCREV is what you want to
>build, not a default value.

But I didn't use a default value. See the SRCREVs listed from the recipe
above. I specifically stated that I wanted the head of standard/base. This
HEAD just happens to be what we merged with emgd-1.18. What this is saying
is that you can never use a SRCREV for a machine branch that exists in a
feature branch if you want to use that feature. That means the only way
the system can work is if every machine uses commits above and beyond
standard/base.... Which is exactly what we are trying to avoid for IA
systems.

There needs to be a way to make this work in a predictable way without all
this implicit mangling and silent failures.

--
Darren

>
>I've actually re-written the branch validation based on top of the fact
>that
>the fetcher now does a lot of this checking for me, so the code is a lot
>simpler.
>
>Bruce
>
>>
>> kernel-yocto.bbclass:
>> 349 |───────# force the SRCREV in each branch that contains the
>>specified
>> 350 |───────# SRCREV (if it isn't the current HEAD of that branch)
>> 351 |───────git checkout -q master
>> 352 |───────for b in $containing_branches; do
>> 354 |───────|───────branch_head=`git show-ref -s --heads
>> ${b}`|─────|───────
>> 355 |───────|───────if [ "$branch_head" != "$target_branch_head" ]; then
>> 356 |───────|───────|───────echo "[INFO] Setting branch $b to
>> ${target_branch_head}"
>> 357 |───────|───────|───────if [ "$b" = "master" ]; then
>> 358 |───────|───────|───────|───────git reset --hard
>>$target_branch_head >
>> /dev/null
>> 359 |───────|───────|───────else
>> 360 |───────|───────|───────|───────git branch -D $b > /dev/null
>> 361 |───────|───────|───────|───────git branch $b $target_branch_head >
>> /dev/null
>> 362 |───────|───────|───────fi
>> 363 |───────|───────fi
>> 364 |───────done
>>
>>
>>
>> --
>> Darren Hart
>> Yocto Project - Linux Kernel
>> Intel Open Source Technology Center
>>
>>
>>
>> --
>> _______________________________________________
>> linux-yocto mailing list
>> linux-yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/linux-yocto
>
>
>
>-- 
>"Thou shalt not follow the NULL pointer, for chaos and madness await
>thee at its end"
>


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