summaryrefslogtreecommitdiffstats
path: root/meta/recipes-kernel
diff options
context:
space:
mode:
authorPaul Eggleton <paul.eggleton@linux.intel.com>2017-09-06 21:55:01 +1200
committerRichard Purdie <richard.purdie@linuxfoundation.org>2017-09-18 11:07:29 +0100
commit3fde63363ab90672d6baf204c2b2dca98320fe7d (patch)
tree17bd84f02a82e57ce9068aafc28338bf282de835 /meta/recipes-kernel
parent10af6d86b3effc523cfa0ec49741c5b02ee2cf86 (diff)
downloadpoky-3fde63363ab90672d6baf204c2b2dca98320fe7d.tar.gz
devtool: ensure recipes devtool is working on are unlocked within the eSDK
Alongside reworking the way devtool extracts source, we now need to ensure that within the extensible SDK where task signatures are locked, the signatures of the tasks for the recipes being worked on get unlocked at the right time or otherwise we'll now get taskhash mismatches when running devtool modify on a recipe that was included in the eSDK such as the kernel (due to a separate bug). The existing mechanism for auto-unlocking recipes was a little weak and was happening too late, so I've reimplemented it so that: (a) it gets triggered immediately when the recipe/append is created (b) we avoid writing to the unlocked signatures file unnecessarily (since it's a global configuration file) and (c) within the eSDK configuration we whitelist SIGGEN_UNLOCKED_RECIPES to avoid unnecessary reparses every time we perform one of the devtool operations that does need to change this list. Fixes [YOCTO #11883] (not the underlying cause, but this manifestation of the issue). (From OE-Core rev: 4e9a0be32fc30fb87d65da7cd1a4015c99533aff) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-kernel')
0 files changed, 0 insertions, 0 deletions