linux/poky.git/scripts/lib/devtool/init.py, branch yocto-2.3.1

devtool: add: fix node.js/npm handling with recipe specific sysroots

2017-04-13T09:54:10+00:00

The change over to recipe specific sysroots means that we can no longer get a known location simply from configuration for the npm binary - we need to get the recipe sysroot for nodejs-native, look there for npm if we need to check it's present, and add that to PATH when calling out to npm. Unfortunately this means anywhere we need to get that path we have to have parsed all recipes, otherwise we have no reliable way of resolving nodejs-native. Thus we have to change recipetool create to always parse all recipes (the structure of the code does not allow us to do this conditionally). In the worst case, if npm hasn't already been added to its own sysroot and we are fetching from a source repository rather than an npm registry, this gets a bit ugly because we end up parsing recipes three times: 1) recipetool startup, which then fetches the code and determines it's a node.js module, finds that npm isn't available and then exits with a specific error to tell devtool it needs to build npm 2) when we invoke bitbake -c addto_recipe_sysroot nodejs-native 3) when we re-invoke recipetool This code is badly in need of refactoring, but now is unfortunately not the time to do that, so we're going to have to live with this ugliness for now. Fixes [YOCTO #10992]. (From OE-Core rev: acfdbd796c99882b8586023c8c6b848716105c8d) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

devtool: tidy up handling of parse failures

2017-03-22T11:35:21+00:00

Since the tinfoil2 refactoring, if an error occurred during parsing, we were showing a traceback and not correctly exiting (since we weren't calling shutdown()). Fix both of these issues. (From OE-Core rev: 18304036e1b513fd12c049dbf549ba75c503ed84) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: improve parse failure handling

2017-02-07T14:50:09+00:00

With the move to tinfoil2, the behaviour when parsing failed has changed a bit - exceptions are now raised, so handle these appropriately. Specifically when if parsing the recipe created when running devtool add fails, rename it to .bb.parsefailed so that the user can run bitbake afterwards without parsing being interrupted. (From OE-Core rev: b9592bd3c1ab2155b9f62d18ce593b9c88eff279) Signed-off-by: Paul Eggleton 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 / recipetool: use tinfoil parsing API

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

Use Tinfoil.parse_recipe_file() and Tinfoil.parse_recipe() instead of the recipeutils equivalents, and replace any local duplicate implementations. This not only tidies up the code but also allows these calls to work in memres mode. (From OE-Core rev: f13b56266ee96dfab65a3a7db50e8051aa9f071a) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: fix handling of unicode characters from subprocess stdout

2016-11-23T11:10:15+00:00

In previous implementation, a UnicodeDecodeError exception will be raised if multi-byte encoded characters are printed by the subprocess. As an example, the following command will fail in an en_US.UTF-8 environment because wget quotes its saving destination with '‘'(0xE2 0x80 0x98), while just the first byte is provided for decoding: devtool add recipe http://example.com/source.tar.xz The patch fixes the issue by avoiding such kind of incomplete decoding. (From OE-Core rev: 1875ea92546d23abcab1b40b562477a0016f712d) Signed-off-by: Jiajie Hu Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: add: build nodejs-native if npm is needed and not available

2016-10-05T09:10:11+00:00

If the user runs devtool add on an npm:// URL (or source tree that uses node.js), and npm is not available, just build nodejs-native instead of telling the user they need to do it; if that fails because there isn't any such recipe (which would be the default, since it's not in OE-Core) then produce a slightly more readable error message hinting at what the user needs to do. Note that this forces the use of nodejs-native rather than npm on the host - this makes sense for two reasons: (1) we need it to be compatible with nodejs for the target, and (2) we have to have a recipe for that anyway, so allowing you to avoid having a recipe for the native version isn't really beneficial. There's a bit of a hack in here in order to allow this - for node.js sources that aren't fetched via npm we don't know that they are that until we've fetched and unpacked them, by which time we're inside recipetool and have an active tinfoil instance that will prevent bitbake being run. To avoid this being an issue, we allow recipetool to get to the point where we know we need npm and then exit with a specific exit code, at which point devtool can try to build it and then if that succeeds, it will re-execute recipetool. This is definitely not ideal, but it can't really be refactored and done properly until we do the tinfoil2 refactoring; in the mean time though we still want to be helpful to the user. Fixes [YOCTO #10337]. (From OE-Core rev: f40662bde5aab158c4e4c3c3ff5e68665a4194a5) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

lib/oe/patch: commit with a dummy user/email when PATCHTOOL=git

2016-09-03T22:45:52+00:00

When using PATCHTOOL = "git", the user of the system is not really the committer - it's the build system itself. Thus, specify "dummy" values for username and email instead of using the user's configured values. Various parts of the devtool code that need to make commits have also been updated to use the same logic. This allows PATCHTOOL = "git" and devtool to be used on systems where git user.name / user.email has not been set (on versions of git where it doesn't default a value under this circumstance). If you want to return to the old behaviour where the externally configured user name / email are used, set the following in your local.conf: PATCH_GIT_USER_NAME = "" PATCH_GIT_USER_EMAIL = "" Fixes [YOCTO #8703]. (From OE-Core rev: 765a9017eaf77ea3204fb10afb8181629680bd82) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

devtool/recipetool/meta: Adapt to bitbake API changes for multi-configuration builds

2016-08-18T09:07:23+00:00

Unfortunately to implenent multiconfig support in bitbake some APIs had to change. This updates code in OE to match the changes in bitbake. Its mostly periperhal changes around devtool/recipetool [Will need a bitbake version requirement bump which I'll make when merging] (From OE-Core rev: 041212fa37bb83acac5ce4ceb9b7b77ad172c5c3) Signed-off-by: Richard Purdie

devtool: return specific exit code for incompatible recipes

2016-07-12T22:10:15+00:00

Certain recipes cannot be used with devtool extract / modify / upgrade - usually because they don't provide any source. Return a specific exit code (4) so that scripts such as scripts/contrib/devtool-stress.py know the difference between this and a genuine failure. (From OE-Core rev: ffd295fed4ab81fc0bd00bb145ef4d72c49584bf) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

linux/poky.git/scripts/lib/devtool/__init__.py, branch yocto-2.3.1