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

[Hart, Darren]

On 3/14/14, 21:56, "Bruce Ashfield" <bruce.ashfield at windriver.com> wrote:

>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_7
>>>>>8a
>>>>> 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-lin
>>>>>ux
>>>>> /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.

Ah, but you didn't merge standard/base, you merged standard/ltsi (same
HEAD). But that doesn't matter. What if I wanted 3.10.1. All the branches
feature branches have that, and they would all be effectively expunged by
me setting my SRCREV_machine to that (or pick any other common ancestor).

If this isn't always obvious to you either, it definitely needs fixing :-)

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

It doesn't break now (I wouldn't go so far as to say it works) because
standard/base has moved on to 3.10.33 while emgd is still based on
3.10.32, so it doesn't contain the HEAD of standard/base anymore. Which is
fine. Until standard/base breaks emgd and we have to fix up the merge
again by first merging with standard/base and then fixing the sources....

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