These recipes should be excluded from target 'world' because these are
just intended to be used internally by oe-selftest (devtool, recipetool, etc.)
(From OE-Core rev: 4868bc94b8c4ebcf427ea6d321332d8b8fe6ce4a)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you have a file:// entry in SRC_URI with a subdir= parameter that
makes it extract into the source tree, then when you update that file in
oe-local-files and run devtool update-recipe then you want the original
file to be updated. This was made to work by OE-Core commit
9069fef5dad5a873c8a8f720f7bcbc7625556309 together with
31f1bbad248c36a8c86dde4ff57ce42efc664082, however until now there was no
oe-selftest test to verify it.
Note that in order to succeed this test also requires the fix
"lib/oe/recipeutils: ignore archives by default in
get_recipe_local_files()" since the test recipe uses a local tarball.
(From OE-Core rev: 936eba3e1059d1dcd5e58c1ce76870fff7b11b3c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a test to ensure devtool update-recipe works properly on recipes
that contain only local files (since the other tests we have didn't test
that).
Relates to [YOCTO #10563].
(From OE-Core rev: bdc844b3f0c3fbddcd3523095899a5bd29797704)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a test for devtool upgrade with a recipe pointing to a git
repository, since this uses several different code paths.
(From OE-Core rev: d3ec74ff4db248ea11a568d5214708d6a1757012)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Use a more real-world test of a recipe pointing to a remote file
* The cleanup tracking / teardown commands need to be added towards the
top, or they won't have the desired effect of cleaning up if the test
fails.
* Check that a versioned subdirectory gets renamed to match the new
version
* Ensure the recipe contents gets changed as we expect it to
* Check that the recipe directory is deleted by devtool reset at the end
(From OE-Core rev: d0ae258e963f9bafffc4ca43c87497d27e57c127)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upgrades a recipe to a particular version and downloads the source code
into a folder. User can avoid patching the source code.
These are the general steps of the upgrade function:
- Extract current recipe source code into srctree and create a branch
- Extract upgrade recipe source code into srctree and rebase with
previous branch. In case the rebase is not correctly applied, source
code will not be deleted, so user correct the patches
- Creates the new recipe under the workspace
[YOCTO #7642]
(From OE-Core rev: 4020f5d91b3e4d011150d5081d36215f8eab732e)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Leonardo Sandoval
Paul Eggleton