A typo introduced an extra } in the logging of the bsp_definition.
While this won't cause problems .. it needs to be fixed!

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

In some cases it is seen that kernel_checkout and validate_branches are
run again in simultaneous builds. During do_patch the kgit-s2q mechanism
looks for a sentinel file inside the .git directory, finds a fence post
and starts picking up patches after that.

This can create trouble as validate_branches checks out the HEAD of the
branch and so the patches should be reapplied rather than skipped due to
finding of the fence post.

We can call kgit-s2q --clean to remove the sentinel file when the
branches are checked out.

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

When debugging a kernel configuration issue, one of the first questions
is "what BSP was used". To answer this qusetion, we log the BSP .scc
file that was used to generate the kernel configuration in the kernel
source meta directory.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

The ability to merge two branches directly from a .scc file was
dropped during the streamlining of the tools.

As was pointed out by David Vincent <freesilicon@gmail.com>, there is
once again a valid use case for this functionality, so we restore the
capability.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

There were a few straggling expansion parameter removals left for
getVar/getVarFlag where the odd whitespace meant they were missed
on previous passes. There were also some plain broken ussages such
as:

d.getVar('ALTERNATIVE_TARGET', old_name, True)
path = d.getVar('PATH', d, True)
d.getVar('IMAGE_ROOTFS', 'True')

which I've corrected (they happend to work by luck).

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.

Search made with the following regex: getVar ?\(( ?[^,()]*), True\)

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

To trap errors and halt processing, do_kernel_metadata was recently
switched to exit on any non zero return code. While the concept is
sound, there are subcommands that have legitimate non-zero return
codes.

Instead of removing set +e, we'll explicitly check the return code
of the commands that can error, and throw a bbfatal to alert the
user.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Historically the processing of kernel meta data contained some
commands that exited with a non-zero return code. Special processing
was required to properly deal with their exit.

That is no longer true, and instead of handling all return codes
and doing an explicit 'exit' call, we can remove set -e from the
routine and have all errors be trapped and stop processing.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

If attempting to patch a git repo without a proper git config setup,
an error will occur saying user.name/user.email are needed by git
am/apply. After some code was removed from kernel-yocto, it was
simple enough to reproduce this error by creating a kernel patch and
using a container to build.

This patch abstracts out functionality that existed in buildhistory
for use in other classes. It also adds a call to this functionality
to the kernel-yocto class.

Fixes [YOCTO #10346]

introduced in OE-core revision
0f698dfd1c8bbc0d53ae7977e26685a7a3df52a3

Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Various recipes depend on the kernel's do_shared_workdir
task, a quick grep suggests all external kernel modules
(via module.bbclass), but also perf, and potentially any
additional headers as outlined in linux-libc-headers.inc
are affected.

Having do_shared_workdir in SRCTREECOVEREDTASKS means this
task is removed when externalsrc is enabled, making all
those recipes fail as the task they depend on,
virtual/kernel:do_shared_workdir, doesn't exist.

Remove do_shared_workdir from SRCTREECOVEREDTASKS so that
all those recipes work even if externalsrc is activated.

According to the comment in here, the reason for
do_shared_workdir to be removed as a task is because it
modifies the source tree, but that doesn't seem to be
case.

Signed-off-by: Andre Draszik <git@andred.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>