linux/poky.git/scripts/lib/recipetool, branch dunfell-23.0.1

recipetool/create: npm: remove the 'noverify' url parameter

2020-01-27T16:48:09+00:00

This commit removes the 'noverify' parameter which was added to the url to fix warnings with the shrinkwrap / lockdown file generation. This is not needed anymore with the new npm fetcher. (From OE-Core rev: 401a9818c633373854d3c7dec032b9f455f2b2b4) Signed-off-by: Jean-Marie LEMETAYER Signed-off-by: Richard Purdie

recipetool/create_npm: handle the licenses of the dependencies

2020-01-27T16:48:09+00:00

As usual the 'LICENSE' and the 'LIC_FILES_CHKSUM' values reflects all the license files discovered in the source tree (including the dependencies). For npm recipes the 'LIC_FILES_CHKSUM' value contains also the status of the 'package.json' file of every packages as it contains license informations. Finally each package has a separate 'LICENSE_${PN}-package-name' value which describes its license. (From OE-Core rev: 9a70d4996c84b277f423eda5aac4acbe344599f4) Signed-off-by: Jean-Marie LEMETAYER Signed-off-by: Richard Purdie

recipetool/create_npm: refactor the npm recipe creation handler

2020-01-27T16:48:09+00:00

This commit refactors the npm recipe creation handler to use the new npm behavior. The process is kept as simple as possible and only generates the shrinkwrap file. To avoid naming issues the recipe name is now extracted from the npm package name and not directly mapped. (From OE-Core rev: 1deccb0f0c204cd02fb8606f180d8a13df9f31db) Signed-off-by: Jean-Marie LEMETAYER Signed-off-by: Richard Purdie

devtool: npm: rename npm command line options

2020-01-27T16:48:09+00:00

This commit renames the '--fetch-dev' option into '--npm-dev' as it is a npm only option. (From OE-Core rev: 2b75cc848ceebee4067788a621299bfd5fb62231) Signed-off-by: Jean-Marie LEMETAYER Signed-off-by: Richard Purdie

recipetool: always use python 3 in recipe creation

2019-12-30T08:47:12+00:00

(From OE-Core rev: 59e63a2d22988ef11fe36200692b967b67ca8641) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

devtool: fix devtool upgrade with reproducible_builds class

2019-11-21T23:08:20+00:00

If the reproducible_build class is inherited then there may be a "source-date-epoch" subdirectory in a fetched source tree; devtool upgrade was not expecting that in the upgraded source. Take a small snippet of code from recipetool create which already handles this, and make it a shared function that can be used in both places. Additionally, fix an assumption that the source is always in a subdirectory in the cleanup code that blocked debugging this. [YOCTO #13635] (From OE-Core rev: 0d642861cd9cf034b8d4951433980addc215d4fd) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

recipetool/create: Fix to work with reproducible_builds

2019-11-21T23:08:19+00:00

The extra diretory created by reproducibile_builds was confusing recipetool and hence devtool. Ignore this directory to restore the correct behaviour and allow it to work with the class. (From OE-Core rev: 188ba30ef290efab6d5a9b95fba8e991b779ab33) Signed-off-by: Richard Purdie

recipetool: add MD5 hash for the line-wrapped MPL-1.1 license

2019-07-11T08:32:50+00:00

(From OE-Core rev: d2755523d339a4eba7a034bdef5563657609f563) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

recipetool: ignore zero-length setup.py files

2019-07-03T16:00:57+00:00

If a setup.py file exists it ought to have something in it before we consider the source tree to be a Python module and treating it as such. (A counter-example is https://www.bro.org/downloads/binpac-0.50.tar.gz - it's not clear why this has a zero-length setup.py in it but we should pay no attention to it.) Fixes [YOCTO #12923]. (From OE-Core rev: 548a5c8f42c6ac1b0f7962926d05276e71505678) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

package: Build pkgdata specific to the current recipe

2019-06-30T21:40:52+00:00

This switches the code to build pkgdata specific to the current recipe which means that its filtered to the recipes dependencies and can perform better as we can drop the lockfile. It uses a similar method to the staging code to do this, using BB_TASKDEPDATA to construct a list of packagedata task output which this recipe should "see". The original pkgdata store is left unaltered so existing code works. The lock file was there to prevent files disappearing as they were read or as directories were listed. Since we have a copy of the data and only access output from completed tasks (as per their manifests), we can remove the lock. The lock was causing starvation issues on systems with parallelism. There was also a potential determinism problem as the current code could "see" data from recipes which it doesn't depend upon. [YOCTO #13412] (From OE-Core rev: 1951132576bfb95675b4879287f8b3b7c47524fa) Signed-off-by: Richard Purdie