commit 61001aa [kernel-yocto: respect SRC_URI modified branch selection]
changed branch processing such that a branch specified in the SRC_URI
would set the branch forced as the build branch.

This change broke compatibility with the yocto-bsp, linux-yocto-custom
based recipes. These recipes specify the branch to be built via KBRANCH,
but allow the fetcher to use master for keeping the repository up to
date. This means that no explicit branch is set in the SRC_URI and the
routines return the default branch of 'master', which is not what is
set in KBRANCH.

To support this case, we simply pass a default branch into the routine
returning the branch to build, and ensure that the default is KBRANCH
so if no branch is passed in the SRC_URI, KBRANCH is always built.

[YOCTO #4145]

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The linux-yocto recipes themselves always set S="${WORKDIR}/linux" and
arrange for the fetcher default of ${WORKDIR}/git to be renamed before
building.

Part of this rename involves an assumption that the directory used by
the fetcher can be removed as part of the renaming process, or in fact
that renaming is required.

If a derived recipe uses S="${WORKDIR}/git", the checkout phase fails
since the kernel source is removed as part of the processing.

To fix this the code now detects this situation and does not clean the
source directory before renaming the fetcher default (and in fact does
not rename it at all).

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

Although the setting of KBRANCH is the suggested/primary way to interact with
the yocto kern-tools and the fetcher, some users may be more comfortable
modifying the SRC_URI branch parameter directly.

If they do, the tools will not force their branch and build output will be
different then they expect, in non obvious ways.

It's easy enough to detect this scenario, but checking the SRC_URI in the
same way that the git fetcher checks for the branch (and SRCREV). If we take
the value from the SRC_URI and use it directly in the patch/validate/update
routines, we'll stay consistent with KBRANCH if it is used, and also
automatically adapt to a manually changed branch parameter on the SRC_URI.

For all other users, there are no visible or behavioural changes as a result
of this change

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

To support configurations where active development is not being done within
the oe/bitbake build environment and restricted bandwidth situations, this
commit allows the SRC_URI to point to a kernel tgz instead of a full git
repository.

Outside of the upstream tgz instead of a kernel git repository, the
restrictions, config and patch process is the same as any linux-yocto-custom
recipe.

An example linux-yocto-custom based recipe would have a configuration like
this to build the 3.7 kernel, using an externally supplied config, from the
3.7 tgz:

  SRC_URI = "http://kernel.org/pub/linux/kernel/v3.0/linux-3.7.tar.bz2"
  PV = "3.7"
  S = "${WORKDIR}/linux-3.7"
  SRC_URI[md5sum] = "5323f3faadd051e83af605a63be5ea2e"
  SRC_URI[sha256sum] = "dc08d87a579fe2918362e6666e503a95a76296419195cb499aa9dd4dbe171a9e"

[YOCTO #2686]

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

To promote the reuse and sharing of configuration fragments this change
allows any kernel-yocto based recipe to have multiple alternate git repositories
which provide kernel feature directory trees listed on the SRC_URI.

These feature directories are in addition to any in-tree kernel meta data branches
that may be available (described via the KMETA variable in linux-yocto recipes).

Features found within these directories can be used from recipes via the
KERNEL_FEATURES variable. Features found within a feature directory are free
to include any other features that are available in any directories. In both
cases the path to a feature description (a .scc file) is relative to the
root of a given feature directory (which is how existing .scc files work)

The search order for features is determined by the order that repositories
appear on the SRC_URI.

Normal SRC_URI rules apply to any repository that is added as a kernel
feature container. A SRCREV must be supplied and it must be unpacked to
a unique directory, which is controlled via the "destsuffic" url parameter.

In addition to these standard requirements, any kernel feature repository
reference should identify itself via the "type=kmeta" url parameter. If
type=kmeta is not supplied, the repository will not be processed for
kernel features.

As an example, the following in a linux-yocto bbappend makes two additional
feature directories available to KERNEL_FEATURES and fragments.

 SRC_URI += "git://git.yoctoproject.org/yocto-kernel-cache;protocol=git;branch=master;type=kmeta;name=feat1;destsuffix=kernel-cache/"
 SRC_URI += "git://${KSRC_linux_yocto_3_4};protocol=file;branch=meta;name=feat2;type=kmeta;destsuffix=kernel-features-experimental/"

 SRCREV_feat1 = "${AUTOREV}"
 SRCREV_feat2 = "${AUTOREV}"

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

SRC_URIs that contained git repositories or other constructs that resulted
in an extension of "." or a substring of "scc" or "cfg" were matching the
tests for patches and configs. This was due to a python tuple being used
instead of an array. Switching to an array makes the match exact and the
behaviour we want.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

The details of the kernel configuration audit are typically a
debug action, so should be moved to bb.debug(). But in order
to maintain visibility of the results, a reference to the log
file is provided in the standard message.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

Since linux-yocto based recipes have a split build and source directory,
we should export KBUILD=${B} to the devshell. This allows the kernel to
be incrementally build within the shell and not dirty the source
directory (which breaks subsequent full builds).

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

In the past working from a non-bare clone would cause problems,
due to branches not existing in the WORKDIR clone. This hasn't
been true for some time, since the routines which convert remotes
into local branches have been functioning without problems.

So we no longer need the warning and it can be removed.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

We should always leave the tree on a BSP branch or master when
do_validate_branches completes to avoid modifying version tracked
files are part of the build process. Modifying these files will lead
to errors when changing branches, since the contents would be lost.

This is evident in the case that a the meta branch is reset to a
known SRCREV and the tree was left on the meta branch. This branch
tracks the meta/meta-series, and other artifacts of the original
tree construction. When the build process runs, it updates these same
files, which creates a conflict when switching branches.

This has been fixed in the tree construction scripts to not track
these files, but a secondary fix is also required of not leaving
the build on these branches, to allow arbitrary trees to be built.

[YOCTO #3413]

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>