linux/poky.git/scripts/devtool, branch 2.6_M3

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

scripts: 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: 0a36bd96e6b29fd99a296efc358ca3e9fb5af735) Signed-off-by: Joshua Lock Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: prevent BBHandledException from showing traceback

2016-12-14T12:30:50+00:00

If we don't catch this then attempting to run devtool in non-memres mode when bitbake is already running will produce a traceback instead of just an error message. (From OE-Core rev: e01b75dff599ffa2b66e6608b28bbb3564365eee) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: Load plugins in a well defined order

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

To allow devtool plugins in one layer to shadow another in a well defined way, first search BBPATH/lib/devtool directories and then scripts/lib/devool and load only the first found. The previous search and load loop would load all found plugins with the ones found later replacing any found before. (From OE-Core rev: 1b2b8a0a80de17ea053002fdd124055d2798029a) Signed-off-by: Ola x Nilsson Signed-off-by: Ross Burton Signed-off-by: Richard Purdie