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

Fri Mar 14 21:56:48 PDT 2014

On 2014-03-15, 12:50 AM, Hart, Darren wrote:
> 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

Right. I managed to miss that.

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

The error would have been me merging standard base into emgd, that
never should happen to a topic branch. When I was merging your
patches, that was my mistake.

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

All I can say, is that what is there, is there for a reason. It's
the nature of the beast, jiggling it one way breaks one thing ..
and fixes another.

That being said, this has to work now that I've got that merge in
the EMGD branch and I actually have some code for this, that checks
before patching, not during validation. Let me dust that off.

Bruce

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