linux/poky.git/scripts/lib/devtool/standard.py, branch 2.3_M2

devtool: fix source extraction to work with recipe specific sysroots

2017-01-20T11:53:49+00:00

When extracting source for a recipe within devtool (for extract, modify or upgrade) We need to redirect WORKDIR, STAMPS_DIR etc. under a temporary directory so that: (a) we pick up all files that get unpacked to the WORKDIR, and (b) we don't disturb the existing build However, with recipe-specific sysroots the sysroots for the recipe will be prepared under WORKDIR, and if we used the system temporary directory i.e. usually /tmp) as used by mkdtemp by default, then our attempts to hardlink files into the recipe-specific sysroots will fail on systems where /tmp is a different filesystem, and we'd have to fall back to copying the files which is a waste of time. Put the temp directory under the WORKDIR to prevent that from being a problem. (From OE-Core rev: e10a973cd9390eacb13bdb99693a0622bd3695f5) Signed-off-by: Paul Eggleton [RP: Add needed mkdirhier call] Signed-off-by: Richard Purdie

devtool: modify: fix usage on the kernel

2016-12-22T08:50:16+00:00

When using devtool modify on the kernel, we have to do a bit of a dance with tinfoil instances because we only find out that we're working on a kernel recipe after tinfoil is initialised, but then we need to build kern-tools-native which we're doing just by running bitbake directly. With the tinfoil2 changes, a datastore for the recipe that we were keeping around across the opening and closing of tinfoil is no longer able to be used. Re-parse the recipe to avoid this problem. (In future this whole thing will be able to be done in the same tinfoil instance thanks to tinfoil2, but that refactoring is yet to be done.) (From OE-Core rev: 06127d0115ba449bf04e2579cd1010065e0ed6e3) 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: extract: disable basehash mismatch errors

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

Using the setVariable commands here followed by buildFile will result in "basehash mismatch" errors, and that's expected since we are deviating *at runtime* from what was previously seen by changing these variable values. Set BB_HASH_IGNORE_MISMATCH to turn off the errors. (From OE-Core rev: b0169796f294bbec0397b7eae86454a46b68cdc5) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: fix extraction of source to work in memres mode

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

Extracting the source for a recipe (as used by devtool's extract, modify and upgrade subcommands) requires us to run do_fetch, do_unpack, do_patch and any tasks that the recipe has inserted inbetween, and do so with a modified datastore primarily so that we can redirect WORKDIR and STAMPS_DIR in order to have the files written out to a place of our choosing and avoid stamping the tasks as having executed in a real build context respectively. However, this all gets much more difficult when in memres mode since we can't call internal functions such as bb.build.exec_func() directly - instead we need to execute the tasks on the server. To do this we use the buildFile command which already exists for the purpose of supporting bitbake -b, and setVariable commands to set up the appropriate datastore. (I did look at passing the modified datastore to the buildFile command instead of using setVar() on the main datastore, however its use of databuilder makes that very difficult, and we'd also need a different method of getting the changes in the datastore over to the worker as well.) (From OE-Core rev: eb63b5339014fc72ba4829714e0a96a98e135ee2) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

classes/patch: move in logic to commit for additional tasks

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

If PATCHTOOL is "git", and PATCH_COMMIT_FUNCTIONS is set to "1", for additional tasks between do_unpack and do_patch, make a git commit. This logic was previously implemented in devtool itself, but it makes more sense for it to be implemented in the patch class since that's where the rest of the logic is for this (or in lib/oe/patch.py). It also makes it possible for this to work with tinfoil2. (From OE-Core rev: f24f59ea1d8bc335ea8576f6a346d0935f4a3548) Signed-off-by: Paul Eggleton 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: modify: support recipes with only local files as source

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

The hello-mod recipe is unusual in that it has only local files in SRC_URI and builds these out of ${WORKDIR}. When you use devtool modify on it, devtool puts all of those files in an "oe-local-files" subdirectory of the source tree, which is not ${S} (or ${B}) any more and thus building the recipe afterwards fails. It's a bit of a hack, but symlink the files in oe-local-files into the source tree (and commit the symlinks with an ignored commit so that the repo is clean) to work around the problem. We only do this at time of extraction, so any files added to or removed from oe-local-files after that won't be handled, but I think there's a limit to how far we should go to support these kinds of recipes - ultimately they are anomalies. I initially tried a hacky workaround where I set effectively set B = "${WORKDIR}" and that allowed it to build, but other things such as the LIC_FILES_CHKSUM checks still broke because they expected to find files in ${S}. Another hack where I set the sourcetree to point to the oe-local-files subdirectory works for hello-mod but not for makedevs since whilst that is similar, unlike hello-mod it does in fact have files in the source tree (since it has a patch that adds COPYING) and thus the same issue occurred. Also tweak one of the tests that tries devtool modify / update-recipe on the makedevs recipe to try building it since that would have caught this issue. Fixes [YOCTO #10616]. (From OE-Core rev: 857c06d6a1d161bf5a01311d07758bd4241929a3) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: update-recipe: support replacing remote patches

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

If you have a patch remotely fetched in a recipe (e.g. from an http server) that needs updating then add a local version and substitute the entry in SRC_URI to point to it. One can argue about how desirable it is to be modifying patches fetched in this way, but then one can argue about how desirable it is to have such patches in the recipe in the first place - and in any case if devtool update-recipe is to correctly transfer changes to such patches made in the git repository within the source tree to the recipe then there isn't much choice but to do it this way. (From OE-Core rev: a19c26cc78a181f9dd2706dd42e7e450d7ad4082) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

devtool: update-recipe: fix handling of compressed local patches

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

It is possible to use gzip or bzip2 to compress patches and still refer to them in compressed form in the SRC_URI value within a recipe. If you run "devtool modify" on such a recipe, make changes to the commit for the patch and then run devtool update-recipe, we need to correctly associate the commit back to the compressed patch file and re-compress the patch, neither of which we were doing previously. Additionally, add an oe-selftest test to ensure this doesn't regress in future. Fixes [YOCTO #8278]. (From OE-Core rev: e47d21624dfec6f71742b837e91da553f18a28c5) Signed-off-by: Paul Eggleton Signed-off-by: Ross Burton Signed-off-by: Richard Purdie