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

[Hart, Darren]

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

>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-l
>>>>>>>in
>>>>>>> ux
>>>>>>> /l
>>>>>>> i
>>>>>>>
>>>>>>> 
>>>>>>>nux-yocto/3.10.32+gitAUTOINC+6e0e756d51_78afd3095c-r0/linux/.meta/cf
>>>>>>>g/
>>>>>>> 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

I like the sound of that.

Here's to less code!

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