linux/poky.git/meta/classes/kernel-yocto.bbclass, branch uninative-1.5

kernel-yocto: trivial: remove extra } from bsp_definition

2017-02-19T14:16:58+00:00

A typo introduced an extra } in the logging of the bsp_definition. While this won't cause problems .. it needs to be fixed! (From OE-Core rev: 9b95f3fca2a94ca922e05321096e07a11e98f9bb) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

kernel-yocto.bbclass: ensure repatching when HEAD is checked out

2017-02-19T14:16:57+00:00

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. (From OE-Core rev: d57aeafdd2b49010a9fa6d1cd9d10f3cfd5754a5) Signed-off-by: Awais Belal Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

kernel-yocto: log the BSP definition file

2017-02-05T09:22:17+00:00

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. (From OE-Core rev: 1003615b866bfe196994bdc25d305ff5eace2715) Signed-off-by: Bruce Ashfield Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kern-tools: re-enable scc merge command

2017-02-05T09:22:17+00:00

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 , there is once again a valid use case for this functionality, so we restore the capability. (From OE-Core rev: a0059ebbb52c659282e355664bba1a2fa282170e) Signed-off-by: Bruce Ashfield Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

meta/scripts: Various getVar/getVarFlag expansion parameter fixes

2017-01-09T13:39:11+00:00

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). (From OE-Core rev: 688f7a64917a5ce5cbe12f8e5da4d47e265d240f) Signed-off-by: Richard Purdie

meta: remove True option to getVar calls

2016-12-16T10:23:23+00:00

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\) (From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f) Signed-off-by: Joshua Lock Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel-yocto: explicitly trap subcommand errors

2016-12-13T22:55:21+00:00

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. (From OE-Core rev: a4705e62d0973c290011fc0d250501d358b659e8) Signed-off-by: Bruce Ashfield Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

kernel-yocto: exit on non-zero return code

2016-12-07T10:46:09+00:00

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. (From OE-Core rev: 476ffd57cf5b6fba40d4e3f5dd913824ab8a8d3d) Signed-off-by: Bruce Ashfield Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

utils.bbclass: add function to check for git config user

2016-10-07T15:43:57+00:00

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 (From OE-Core rev: 25b43cb05c645e43f96bc18906441b8fdc272228) Signed-off-by: Stephano Cetola Signed-off-by: Richard Purdie

kernel-yocto: remove do_shared_workdir from SRCTREECOVEREDTASKS

2016-09-14T21:22:12+00:00

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. (From OE-Core rev: 29e99d7a57803e450920600b5d35c5b4e58a0ede) Signed-off-by: Andre Draszik Signed-off-by: Richard Purdie