Make this test work after recent changes to the mtd-utils recipe, and
hopefully make it robust against any future changes.
(From OE-Core rev: 5be62624a6537659f9f6229c82762da45909f902)
(From OE-Core rev: fd4b4390af0bcbfdaee0d4ddbc6766d7775c52d0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Check up front in test_devtool_deploy_target whether the tap devices
exist and skip if not. If we don't do this we get a significantly less
comprehensible error via pexpect.
(From OE-Core master rev: 2258345e19efff7717fe19a5026ec55f1b6f90b6)
(From OE-Core rev: cdad3ea375590f6fa9330f481b6712681ad00cd2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We weren't adding the version into the bbappend file name when -V was
specified which meant that building or resetting failed.
Also adjust one of the tests so that we're testing devtool add both with
and without this option.
Fixes [YOCTO #7647].
(From OE-Core master rev: bdbeff0cd342e31053d7203d78fc5dda611052b1)
(From OE-Core rev: 0b9e8817fc8ba375a1045a66d04b3fd2b498427b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libmatchbox links to libjpeg if it is present so just explicitly build
it and then check it appears in DEPENDS.
(From OE-Core rev: 00ca890d8a56c4c05ce5bda87b3d9d1452ddfa36)
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>
With the change to externalsrc we can now handle these, so add a test
to ensure they can be built.
(From OE-Core rev: efd46543524db98e4369c1d85a1e1c0e76f12899)
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>
Whilst this test would seemingly be better placed as a runtime test,
unfortunately the runtime tests run under bitbake and you can't run
devtool within bitbake (since devtool needs to run bitbake itself).
Additionally we are testing build-time functionality as well, so
really this has to be done as an oe-selftest test.
This test does have a few perhaps unusual requirements in order to run:
* pexpect is installed
* MACHINE is set to one of the qemu machines
* runqemu tap devices have been set up
(From OE-Core rev: 9dc16a8a87bef5dc408aefb256c01e2a4fe3563c)
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>
Consolidate code for checking compatible recipes and consider meta and
packagegroup recipes as well as package-index and gcc-source to be
incompatible.
(From OE-Core rev: 4be9bf637583b341a89af1b9924752abc7d49c94)
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>
Because we move the workdir when extracting source, then move the source
and delete the temporary workdir, you lose the indirection symlink
pointed to by the alternates file (which is created when the fetcher
clones it from DL_DIR with -s) and the resulting repository is broken.
In any case, for a source repo that the user may put their own changes
into, we can't really rely on a clone made with -s in case the
original goes away - because of cleanall, DL_DIR disappearing, etc. So
repack the repository so that it is a complete, non-shared clone after
unpacking.
(While I'm at it, add a test for devtool modify with a git recipe which
verifies that this works.)
(From OE-Core rev: dccdde4321c48a571677995a4e1dfc583e899cbe)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When updating git-based recipes, in a lot of cases what you want is to
push the changes to the repository and update SRCREV rather than to
apply patches within the recipe. Updating SRCREV is now the default
behaviour for recipes that fetch from git, but this can be overridden
in both directions using a new -m/--mode option.
(From OE-Core rev: 654792bb87610ee3569d02a85fa9ec071bf8ab6d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you want to be able to make use of libraries in conjunction with
devtool then we need to install them into the sysroot for other recipes
to use. Make it a configuration option in case it needs to be changed at
runtime.
(From OE-Core rev: 94f517ad8e55edfbe6f06afd963bcfeb849626ff)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you've added a new recipe, you want the output cleaned when you do
devtool reset, otherwise cruft from building the recipe may remain which
could interfere with future builds.
(From OE-Core rev: 664d1a7fe8f8288fabc582d00f6e36ab29496ec5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Build some recipes so that we have the needed data in the sysroot for
recipetool to refer to when scanning for dependencies.
(From OE-Core rev: 67bf1dac68d76c7e6a4d95e5bdd1eba468331f01)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
assertTrue prints "False is not True" if it fails, which is pretty much
useless. Use a more appropriate assertion test where practical and add a
message where it isn't.
(From OE-Core rev: 0e0dd2575bb2a1b6f6c5eba1f8cfb0d81cc1b091)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add some QA tests for devtool (and recipetool). These aren't
comprehensive but at least they are a start, and have already helped me
catch and fix a number of regressions.
(From OE-Core rev: 79486a8aea7af138535e139e696fbdbd5d57581b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
