On Fri, Mar 14, 2014 at 5:40 PM, Hart, Darren <darren.h...@intel.com> wrote:
> On 3/14/14, 13:18, "Hart, Darren" <darren.h...@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;bra
>>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_78afd
>>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/kern
>>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 :)
>
> Why on earth does this blob of time suckage exist?
Check the mailing list archives, I've answered this about 3 times :)
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.
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@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"
--
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
