diff options
author | Paul Eggleton <paul.eggleton@linux.intel.com> | 2017-09-06 21:55:01 +1200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2017-09-18 11:07:29 +0100 |
commit | 3fde63363ab90672d6baf204c2b2dca98320fe7d (patch) | |
tree | 17bd84f02a82e57ce9068aafc28338bf282de835 /meta/recipes-kernel/blktrace | |
parent | 10af6d86b3effc523cfa0ec49741c5b02ee2cf86 (diff) | |
download | poky-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/blktrace')
0 files changed, 0 insertions, 0 deletions