It turns out that scp can't be used to copy symlinks because it follows
them instead of copying them, and this is by design (since it emulates
rcp which also behaved this way); the unfortunate result is that
symlinks that point to valid files on the host translate into the host
file being copied to the target (yuck). The simplest alternative that
does not have this undesirable behaviour is to use tar and pipe it over
ssh.
At the same time, it would be even better if we properly reflect file
permissions and ownership on the target that have been established
within the pseudo environment. We can do this by executing the copy
process under pseudo, which turns out to be quite easy with access to
the pseudo environment set up by the build system.
Fixes [YOCTO #7868].
(From OE-Core rev: 69adaed0e982d627ebfa57b360b0ee049ea7a276)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Quite often what you want to do having made customisations to a piece of
software is to apply those customisations in your own layer rather than
in the original recipe. Thus, add a -a/--append option to the
update-recipe subcommand which allows you to specify the layer to write
a bbappend into. The bbappend will be created at the appropriate path
within the specified layer directory (which may or may not be in your
bblayers.conf) or if one already exists it will be updated
appropriately.
(This re-uses code written for recipetool appendfile.)
Implements [YOCTO #7587].
(From OE-Core rev: 87d487ea4fdfb6cd30e3b3fad47732db12e86f23)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Locating which recipe provides a file in an image that you want to
modify and then figuring out how to bbappend the recipe in order to
replace it can be a tedious process. Thus, add a new appendfile
subcommand to recipetool, providing the ability to create a bbappend
file to add/replace any file in the target system. Without the -r
option, it will search for the recipe packaging the specified file
(using pkgdata from previously built recipes). The bbappend will be
created at the appropriate path within the specified layer directory
(which may or may not be in your bblayers.conf) or if one already exists
it will be updated appropriately.
Fairly extensive oe-selftest tests are also provided.
Implements [YOCTO #6447].
(From OE-Core rev: dd2aa93b3c13d2c6464ef0fda59620c7dba450bb)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These tests really belong in their own module; if we refactor
out a base class from DevtoolTests with shared functions then we can
move them out easily. Also create temp directory in setupLocal() so we
don't have to do that in individual tests anymore.
(From OE-Core rev: 2f88f6e7b2e54b13376338354aae1d61c0c0db60)
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 rev: 2258345e19efff7717fe19a5026ec55f1b6f90b6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After OE-Core commit 67db7182faf6742b0d971d61d8c5ba34f69d2e12, PV is
appended to the end of the gcc-source PN, thus we need to handle that in
devtool and the corresponding test.
Part of the fix for [YOCTO #7729].
(From OE-Core rev: 440029dc229a566b9bead1481215d5e5760c5fe6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I already had the file fetched from some previous work and thus it
didn't attempt to download the invalid URL when I tested it earlier.
Part of the fix for [YOCTO #7729].
(From OE-Core rev: f9bad5aeb507f5b3c1346118011c7766c44d9ba4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tests the following aspects of "devtool add" with the -f option:
* Works for a git and https URI
* Extracts to the appropriate directory
* Uses the correct recipe file name with and without -V
* Sets SRC_URI and S appropriately with and without -V
* Sets SRCREV if rev= is specified in the URI
A lot of this functionality relies on "recipetool create" which
"devtool add" wraps around, so the associated behaviour of that is also
being tested here.
Refactor out the code to check a recipe for variable values / inherits
at the same time so we can use it to check the generated recipe.
(From OE-Core rev: 0e626639ee75d42cb44d357efe2d9c4d2ff65294)
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 rev: bdbeff0cd342e31053d7203d78fc5dda611052b1)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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)
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>
Add a -a/--all option to allow you to quickly reset all recipes in your
workspace.
(From OE-Core rev: 0c83788b111a761f6f500b86780cc51aed255402)
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>
