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

[Bruce Ashfield]

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

meh, what's in a branch name ? ;)

> 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 :-)

oh, it's painfully obvious to me, I have the scars to prove it.
Writing email in the middle of the night is the problem.

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

That was always the problem .. only when the HEADs matched did they
get reset. I've actually run into this before in a different context,
but that problem was resolved by an update, and I managed to forget :(

The solution I had in place for this was to shuffle the validation to a
later point in the build. Once we know the branch has been confirmed
by the kernel meta data.

But with the new fetcher changes, I need much less of this now, and
have been throwing large chunks out. So my suggestion is to drop most
,if not all, of the branch resetting completely. I'll factor that out,
and send it your way for some testing (After I soak it briefly).

I completely agree that the code isn't clear, I'd just rather delete
it than tweak it more :P

Bruce


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