linux/poky.git/scripts/lib/recipetool, branch 2.4_M2

scriptutils: pass in logger as parameter

2017-07-21T21:51:37+00:00

logger was not defined in scriptutils.py based on the observation in python traceback. Traceback (most recent call last): File "/workdir/poky/scripts/devtool", line 351, in ret = main() File "/workdir/poky/scripts/devtool", line 338, in main ret = args.func(args, config, basepath, workspace) File "/workdir/poky/scripts/lib/devtool/utilcmds.py", line 55, in edit_recipe return scriptutils.run_editor(find_recipe(args, config, basepath, workspace)) File "/workdir/poky/scripts/lib/scriptutils.py", line 141, in run_editor logger.error("Execution of '%s' failed: %s" % (editor, exc)) NameError: name 'logger' is not defined We pass in logger as parameter to run_editor() from where it has been called (devtool/utilcmds.py and recipetool/newappend.py), which both modules already has logger setup. (From OE-Core rev: 21f04b61973dd9029f0e6bff5445e31cd762bf32) Signed-off-by: Chang Rebecca Swee Fun Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

recipetool: create: refactor code for ensuring npm is available

2017-07-21T07:44:25+00:00

Across devtool and recipetool we had an ugly set of code for ensuring that we can call an npm binary, and much of that ugliness was a result of not being able to run build tasks when tinfoil was active - if recipetool found that npm was required and we didn't know beforehand (e.g. we're fetching from a plain git repository as opposed to an npm:// URL where it's obvious) then it had to exit and return a special result code, so that devtool knew it needed to build nodejs-native and then call recipetool again. Now that we are using real build tasks to fetch and unpack, we can drop most of this and move the code to the one place where it's still needed (i.e. create_npm where we potentially have to deal with node.js code in a plain source repository). (From OE-Core rev: 8450de16ddb02d863204b411a94c6d84e0f88817) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

recipetool: create: reimplement fetching with normal fetch/unpack tasks

2017-07-21T07:44:25+00:00

Now that we have the ability to run the tasks in a more standard context through tinfoil, change recipetool's fetching code to use that to fetch files using it. This has the major advantage that any dependencies of do_fetch and do_unpack (e.g. for subversion or npm) will be handled automatically. This also has the beneficial side-effect of fixing a recent regression that prevented this fetch operation from working with memory resident bitbake. Also fix devtool's usage of fetch_uri() at the same time so that we can completely replace it. Fixes [YOCTO #11710]. (From OE-Core rev: 9a47a6690052ef943c0d4760630ee630fb012153) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

recipetool: create: eliminate second fetch for packages

2017-07-21T07:44:25+00:00

When dealing with package files (.rpm, .ipk etc.) we need to unpack them ourselves to get the metadata, which is thrown away when the fetcher unpacks them. However, since we've already fetched the file once, I'm not sure as to why I thought I needed to fetch it again - we can just get the local path and then unpack it directly. (From OE-Core rev: be45e9b17e9dbc8c2594d3a939be377ab0720a7c) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

recipetool: create: ensure meaningful error for malformed tarballs

2017-07-21T07:44:25+00:00

If you pointed recipetool at a URL that should be a tarball e.g. https://tls.mbed.org/download/start/mbedtls-2.4.2-apache.tgz but instead it returns an HTML page, we try to unpack it, gzip complains but the operation doesn't seem to fail - instead we just get back an empty source tree. Change the checks to account for this - if the source tree is empty, check if the downloaded file in DL_DIR looks like an HTML file and error accordingly if it is. If it's not, error out anyway because no source was unpacked and it should have been (otherwise we just blindly set up EXTERNALSRC for this which is pointless). Fixes an aspect of [YOCTO #11407]. (From OE-Core rev: 8496113b63d5a5d1f99056610c0fdb972a6200d4) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

recipetool: git reformat URI mangling & parameter stripped

2017-07-17T13:01:38+00:00

recipetool seems to be mangling and stripping out the parameters for git URI. This will fix this issue as well as resolve the conflict of protocol parameter added by user. If a user adds their own protocol as an argument, it'll be honored. [YOCTO #11390] [YOCTO #11391] (From OE-Core rev: 0cd2fc8ca278ebaa76de95545eef26a07b350c8e) Signed-off-by: Stanley Cheong Kwan, Phoong Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

recipetool: create: extract name of package from a repository

2017-05-23T16:45:36+00:00

For git repositories in the absence of any other indicator, it's not an unreasonable assumption that the name of the repository is the name of the software package it contains, so use that as PN if we don't have anything else. (From OE-Core rev: ef73fa70f0955912b0da140922465a3c817424e9) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

recipetool: create: skip values extracted from spec files containing macros

2017-05-23T16:45:36+00:00

If a value we extract from a spec file contains an unexpanded macro (e.g. %{macroname}) then we should discard it since we're not seeing the actual value and we don't have an easy way of expanding it at the moment. This fixes for example getting %{name} as the recipe name when running the following: recipetool create https://github.com/gavincarr/mod_auth_tkt.git (From OE-Core rev: eee56a19cda051da6267f808cd3a04a4c644acb3) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

recipetool: create: hide missing npm error when called from devtool

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

If devtool is called with a URL to a source repository containing a node.js module, we don't know that until recipetool has fetched it, and due to the structure of the code we have to exit with a special code in order to let devtool know it needs to build nodejs-native. We also want to suppress the error message that recipetool would normally print under these circumstances; there is already a mechanism for this but it wasn't operative in the case where we're pointed to a source repository rather than an npm:// URL, so create some plumbing so that we know to hide the message. (From OE-Core rev: 0c2d0fbb1c6c5b82183799eb7ef80074f86bcfc4) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

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