linux/poky.git/scripts/devtool, branch kirkstone-4.0.6

devtool: error out when workspace is using old override syntax

2022-08-23T14:22:52+00:00

When the workspace bbappends are still using the old override syntax with EXTERNALSRC_pn-*, externalsrc_re will not match, and pn will never be assigned, leading to a nondescript UnboundLocalError being raised on the user's terminal. Try to detect that situation and give the user a hint how to solve it. (From OE-Core rev: 3aee3425956020166d99ec085e35e21b3daf625f) Signed-off-by: Roland Hieber Signed-off-by: Luca Ceresoli Signed-off-by: Richard Purdie (cherry picked from commit d42ea8e849cf2df3708406418b961168268b316a) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

meta: Manual override fixes

2021-08-02T14:44:10+00:00

The automated conversion of OE-Core to use the new override sytax isn't perfect. This patches some mis-converted lines and some lines which were missed by the automation. (From OE-Core rev: 4e9a06b64b43131b731fb59a0305f78a98e27fbd) Signed-off-by: Richard Purdie

meta/lib+scripts: Convert to SPDX license headers

2019-05-09T15:31:55+00:00

This adds SPDX license headers in place of the wide assortment of things currently in our script headers. We default to GPL-2.0-only except for the oeqa code where it was clearly submitted and marked as MIT on the most part or some scripts which had the "or later" GPL versioning. The patch also drops other obsolete bits of file headers where they were encoountered such as editor modelines, obsolete maintainer information or the phrase "All rights reserved" which is now obsolete and not required in copyright headers (in this case its actually confusing for licensing as all rights were not reserved). More work is needed for OE-Core but this takes care of the bulk of the scripts and meta/lib directories. The top level LICENSE files are tweaked to match the new structure and the SPDX naming. (From OE-Core rev: f8c9c511b5f1b7dbd45b77f345cb6c048ae6763e) Signed-off-by: Richard Purdie

devtool: Use ConfigParser instead of SafeConfigParser

2018-08-14T10:36:31+00:00

The SafeConfigParser class has been renamed to ConfigParser in Python 3.2+ see http://bugs.python.org/issue10627 This alias will be removed in future versions.So we can use ConfigParser directly instead. (From OE-Core rev: 3c05c8fff779bd190b31fa8aa16b7a1b24420a60) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

devtool/oeqa: Ensure added layers set LAYERSERIES_COMPAT

2018-04-07T10:44:50+00:00

Now that we see warnings if LAYERSERIES_COMPAT is unset, the auto generated code from devtool/oeqa needs to set this to avoid warnings which break various tests. (From OE-Core rev: 27568410ebb0d40db3428550704f35199df0e034) Signed-off-by: Richard Purdie

devtool: fix poor handling of upgraded BBCLASSEXTENDed recipes

2018-03-01T22:13:56+00:00

Fix two aspects of handling BBCLASSEXTENDed targets (e.g. openssl-native) that have been run through "devtool upgrade": * Fix recipe name not showing up in "devtool status" * Fix "devtool reset" not deleting empty directories under the recipe directory within the workspace, which may lead to problems if you subsequently run "devtool upgrade" on the same target again (From OE-Core rev: 56e04260d64de9c5b83893d97cf41b7ea9a45878) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

devtool: stop always moving workspace to end of BBLAYERS

2017-11-11T12:14:27+00:00

I noticed that using bitbake-layers add-layer followed by a devtool command resulted in bitbake re-parsing all of the recipes, which is annoying. Upon closer inspection I could see that devtool was moving the workspace layer path to the end of BBLAYERS if it happened to be somewhere in the middle - there's no need for it to be doing this. This occurred because we were passing the current workspace path to remove and the "new" path to add even if the path is not being changed, and I think earlier versions of bb.utils.edit_bblayers_conf() didn't move the existing entry under these circumstances as it clearly does now. Fix it so we only pass the path to be removed if we're actually changing the path. (From OE-Core rev: 284426dbad91a3c52eaf7da5c58fe8a2c2dfb826) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: fix handling of oe-local-files when source is in a subdirectory

2017-11-11T12:14:27+00:00

If S points to a subdirectory of the source rather than the "base" of the source tree then we weren't handling the oe-local-files directory properly - it got extracted to the base of the tree but devtool update-recipe and devtool finish assumed it would be under S which would be the subdirectory, thus it would be missing and devtool would assume the files had been deleted and remove them from the recipe. Record the base of the source tree in the bbappend and read it into the in-memory workspace so we can use that to find out where oe-local-files should be found. (From OE-Core rev: 30d2ea67b2c4727e23d06a35745b1afa64b130cc) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: ensure recipes devtool is working on are unlocked within the eSDK

2017-09-18T10:07:29+00:00

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 Signed-off-by: Richard Purdie

devtool: check locale and refuse to start if it isn't UTF-8

2017-01-23T12:05:22+00:00

We need to ensure the locale is UTF-8 or otherwise strange errors will occur later on during execution - the same reason we check this in BitBake itself. Unfortunately this check has to be before command line parsing and therefore showing the help text in response to --help, since that relies upon parsing bitbake's configuration (as we need to load plugins in other layers). Fixes [YOCTO #10908]. (From OE-Core rev: 370c6ba16c72bb52e80da098a5812ed1e09ac659) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie