Bug 6710

*** Bug 6742 has been marked as a duplicate of this bug. ***

I've done some digging into this but so far am not seeing what is (significantly) different between qemux86-64 (which works) and intel-corei7-64 (which does not). The SRCREV in the bug report is valid. I updated to the latest meta and machine SRCREV, but the error persists (with the new SRCREVs).

I thought it might be something weird with the common architecture feature, but removing that from the BSP and making it machine specific didn't change the behavior.

I was surprised to see do_patch fail, instead of do_validate_branches, in this particular way.

Adding Bruce on Cc for ideas.

The branch created for qemux86-64 is standard/preempt-rt/base as expected, but for intel-corei7-64 it is standard/standard/preempt-rt ... and it has checked out standard/base, not standard/preempt-rt/base...

Turns out it's "updateme" in do_patch() that changes the branch from standard/preempt-rt/base (which we start do_patch with) to standard/standard/preempt-rt....

| + echo Branch post createme: * standard/standard/preempt-rt
| Branch post createme: * standard/standard/preempt-rt
| + [ 0 -ne 0 ]
| + sccs=
| + patches=
| + feat_dirs=
| + set +e
| + [ -n  features/netfilter/netfilter.scc features/taskstats/taskstats.scc ]
| + addon_features= --feature features/netfilter/netfilter.scc
| + addon_features= --feature features/netfilter/netfilter.scc --feature features/taskstats/taskstats.scc
| + [ -n  ]
| + echo  updateme  -DKDESC=intel-corei7-64:preempt-rt   --feature features/netfilter/netfilter.scc --feature features/taskstats/taskstats.scc x86 intel-corei7-64
|  updateme  -DKDESC=intel-corei7-64:preempt-rt   --feature features/netfilter/netfilter.scc --feature features/taskstats/taskstats.scc x86 intel-corei7-64
| + updateme -DKDESC=intel-corei7-64:preempt-rt --feature features/netfilter/netfilter.scc --feature features/taskstats/taskstats.scc x86 intel-corei7-64
| + git branch
| + grep *
| + echo Branch post updateme: * standard/standard/preempt-rt
| Branch post updateme: * standard/standard/preempt-rt

Bruce, does anything in that call to updateme look off to you?

commit 1d86365fb6548d2eae089910b22bda683ae27746
Author: Bruce Ashfield <bruce.ashfield@windriver.com>
Date:   Mon Sep 8 15:08:50 2014 -0400

    intel: create intel-common-preempt-rt and use it
    
    The -preempt variants were including intel-common-standard.scc, and
    then the preempt-rt kernel type.
    
    But since preempt-rt also includes the standard kernel, this results
    in a double include of the standard kernel, at a different point in
    the branch structure, and hence a less than obvious branch is created
    like: standard/standard/preempt-rt.
    
    To fix this, we create a parallel intel-common-preempt-rt and include
    it when necessary.
    
    Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>

:000000 100644 000000000000... 555744152ef4... A        bsp/intel-common/intel-common-preempt-rt.scc
:100644 100644 b5f56035e409... 070047c95ccb... M        bsp/intel-common/intel-core2-32-preempt-rt.scc
:100644 100644 d5bed7657d26... 6e3f6cc9677d... M        bsp/intel-common/intel-corei7-64-preempt-rt.scc

That commit above is from: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/

So that duplicates a lot of config, which defeats the purpose of intel-common-standard.scc. I've worked up a change which removes the include of the ktype from intel-common-standard.scc and renames it to intel-common-drivers.scc and includes the ktype in each top level BSP explicitly. This avoids the duplication across a standard and preempt-rt version of the same file. I'll submit for 3.14 and it should apply to 3.17 after reverting the commit in Comment 4.

This gets past the do_patch failure, but now compilation fails for pch_gbe_main.c. 
I'm working on that now.

Patch on the list.

commit b25eb7e4dfee7802d4eae657fa5e482a1a010190 (HEAD, refs/remotes/origin/master, refs/remotes/origin/HEAD, refs/heads/master)
Author: Darren Hart <dvhart@linux.intel.com>
Date:   2014-09-26

    linux-yocto*_3.14: Update SRCREV_meta to avoid rt build failure

Hello,

I tested to build this recipe and it didn't work for me. I tested two times, once with a clean environment and the other with an already existing one. Both tests were performed on Ubuntu 14.10 OS on master branch.

BSP tested for: intel-corei7-64

poky hash:  master:08d3f44d784e06f461b7d83ae9262566f1cf09e4

Doing tests I noticed something that I haven't encounter until now; though running bitbake without -k flag, the build continued despide encountering an error at the begining of build. The error messages can be seen in the attached log files.

Regards,

Costin

Created attachment 2361 [details]
logs

logs

Firstly, please only reopen a bug if the issue matches the original issue. Here, the error you're seeing is:

ERROR: The recipe linux-yocto is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
   /media/poky/3poky/build/tmp/sysroots/intel-corei7-64/sysroot-providers/virtual_kernel
 Matched in manifest-intel-corei7-64-linux-yocto-rt.populate_sysroot
Please verify which recipe should provide the above files.
The build has stopped as continuing in this scenario WILL break things, if not now, possibly in the future (we've seen builds fail several months later). If the system knew how to recover from this automatically it would however there are several different scenarios which can result in this and we don't know which one this is. It may be you have switched providers of something like virtual/kernel (e.g. from linux-yocto to linux-yocto-dev), in that case you need to execute the clean task for both recipes and it will resolve this error. It may be you changed DISTRO_FEATURES from systemd to udev or vice versa. Cleaning those recipes should again resolve this error however switching DISTRO_FEATURES on an existing build directory is not supported, you should really clean out tmp and rebuild (reusing sstate should be safe). It could be the overlapping files detected are harmless in which case adding them to SSTATE_DUPWHITELIST may be the correct solution. It could also be your build is including two different conflicting versions of things (e.g. bluez 4 and bluez 5 and the correct solution for that would be to resolve the conflict. If in doubt, please ask on the mailing list, sharing the error and filelist above.

and this is not the error in this original bug. I'm therefore marking the original bug as resolved again.

Secondly, the most common cause of the error above is as described, you changed virtual/kernel provider without wiping the tmp directory.

If you are still seeing the issue please open a new bug and describe the steps taken to reproduce.