There are some features in testimage/testexport that are not tested;
this might lead to break some of these features without notice.
This adds a new test in order to test two features of testimage:
- Import test from other layers.
- Install/Unistall in the DUT without a package manager.
[YOCTO #9764]
[YOCTO #9766]
(From OE-Core rev: cffab2257dacfa741c64611dfdf361f77aff9460)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add three tests to verify that the git URL mangling is working the way
it's supposed to. This should prevent us regressing on this again in
future.
(From OE-Core rev: d8d01f462ddbb79cff23b544fcd0ce251f05f8ce)
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>
If you supplied an empty file to patch_recipe() (or an empty list to
patch_recipe_lines()) then the result was IndexError because the code
checking to see if it needed to add an extra line of padding didn't
check to see if there were in fact any lines before trying to access the
last line.
Fixes [YOCTO #9972].
(From OE-Core rev: 92a73e870478ddb2a2d137e3fff28828809bec2e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the new oe-check-sstate to filter the sstate artifacts shipped with
the extensible SDK by effectively running bitbake within the produced
eSDK and and getting it to tell us which tasks it will restore from
sstate. This has several benefits:
1) We drop the *-initial artifacts from the minimal + toolchain eSDK.
This still leaves us with a reasonably large SDK for this
configuration, however it does pave the way for future reductions
since we are actually filtering by what will be expected to be there
on install rather than hoping that whatever cuts we make will match.
2) We verify bitbake's basic operation within the eSDK, i.e. that
we haven't messed up the configuration
3) We verify that the sstate artifacts we expect to be present are
present (at least in the sstate cache for the build producing the
eSDK). Outside deletion of sstate artifacts has been a problem up to
now, and this should at least catch that earlier i.e. during the
build rather than when someone tries to install the eSDK.
This does add a couple of minutes to the do_populate_sdk_ext time, but
it seems like the most appropriate way to handle this.
Should mostly address [YOCTO #9083] and [YOCTO #9626].
(From OE-Core rev: 4b7b48fcb9b39fccf8222650c2608325df2a4507)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're to completely replace the standard SDK with the extensible SDK,
we need to be able to provide the standard toolchain on install without
doing anything other than installing it, so that you can install the SDK
and then point your IDE at it. This is particularly applicable to the
minimal SDK which normally installs nothing by default.
NOTE: enabling this option currently adds ~280MB to the size of the
minimal eSDK installer. If we need to reduce this further we would have
to look at adjusting the dependencies and/or the sstate_depvalid()
function in sstate.bbclass which eliminates dependencies, or look at
reducing the size of the artifacts themselves.
Implements [YOCTO #9751].
(From OE-Core rev: ed0d8ed72370df694f720cc13897493478dc1de9)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of using a directory in the layer as the GPG home and carefully deleting
the right files from it, use tempfile to create a temporary directory which will
be cleaned up for us.
Also change the public/secret key variables to be absolute paths as they're
always used as absolute paths.
(From OE-Core rev: d4a5b5d11c6d7d5aba5f2eb88db091c1b98ef87c)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
tar's --no-recursion flag only applies to files mentioned after the
flag, which made it a no-op in this invocation of tar, because it was at
the end of the command line.
This is simple to verify with GNU tar 1.29:
| $ mkdir foo
| $ mkdir foo/dir
| $ touch foo/dir/file
| $ tar -cf - foo --no-recursion | tar t
| foo/
| foo/dir/
| foo/dir/file
| $ tar -cf - --no-recursion foo | tar t
| foo/
Modify the code so that it actually does what the comment says by moving
the flag in front of the --files-from argument.
(From OE-Core rev: d45f5e71fef5ffbd4408f69c5c179dc71a3eb452)
Signed-off-by: Clemens Lang <clemens.lang@bmw-carit.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oe.utils.getstatusoutput() is a wrapper for subprocess.getstatusoutput() which
uses Universal Newlines, so the output is a str() not bytes().
(From OE-Core rev: ce24d4c3632b71939ad198268a900ee823a89b27)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When checking if a link exists before creating it, use os.path.lexists() as
otherwise os.path.exists() on a broken link will return False.
(From OE-Core rev: ec24b6de2b8686e1f779fef3a963e66f70eeba74)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is possible in an attempt only install, that everything listed is not
available to be installed. This will have the effect of clearing the
package list. However, we only check for an empty package list at
the beginning of the function. We need to also check before running the
install, otherwise we can fail due to 'error: no package(s) given".
(From OE-Core rev: 9ae6a2830dacb3c335754a6da91bd5cc30546b31)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using PR service the buildhistory-diff output contains a lot of
PKGR changes: In practice the mass of PKGR updates hide other important
changes as they often account for 80% of all changes.
Skipped incremental and decremental changes of PKGR versions to reduce
amount of the script output. All changes are still included in the
output if script is run with -a/--report-all command line option.
[YOCTO #9755]
(From OE-Core rev: a343788b11f6c4f92ae8d2035fe8cb54f922227e)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A new test target is neede to test Systemd-boot similar
to gummiboot. Created a copy of GummibootTarget class
and named as SystemdbootTarget, at this point the
gummibootTarget will remain until documentation is
updated with new systed information.
(From OE-Core rev: d1fd3a7dbc363bdc02d810f796b3b810cb13f029)
Signed-off-by: Jose Perez Carranza <jose.perez.carranza@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allow to have more than one test to have json file in order
to install packages in the DUT without using a package manager.
[YOCTO #9926]
(From OE-Core rev: 129c2b4589710aa24e23108f2728f1625b72cb06)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This task runs all functions in IMAGE_QA_COMMANDS after the image
construction has completed in order to validate the resulting image.
Image sanity checks should either be Python functions which raise
bb.build.FuncFailed on failure or shell functions with return a
non-zero exit code.
Python functions may instead raise an oe.utils.ImageQAFailed
Exception which takes an extra argument, a description of the
failure.
python image_check_python_ok () {
if True:
raise bb.build.FuncFailed('This check always fails')
else:
bb.note("Nothing to see here")
}
image_check_shell_ok () {
if true
exit 1
else
exit 0
fi
}
[YOCTO #9448]
(From OE-Core rev: c9bef2ecf1a30159d11781184829f41844a58c13)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
xsettings-client is not meant to be a shared library and the only
user in oe-core (libmatchbox) now has an in-tree copy.
(From OE-Core rev: ed5cbf977dca8f3d85c8d933071c6e49fb4bd95f)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bmap-tools-native is required to generate .bmap file. Without it
wic fails with this error when run with --bmap option:
Error: A native program bmaptool required to build
the image was not found
Added bmap-tools-native to the list of requirements to build
in Wic.setUpLocal method.
(From OE-Core rev: dd11ab551f9bf1d8761d0430f19510a9caa53a12)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a subcommand which will "finish" the work on a recipe. This is
effectively the same as update-recipe followed by reset, except that the
destination layer is required and it will do the right thing depending
on the situation - if the recipe file itself is in the workspace (e.g.
as a result of devtool add), the recipe file and any associated files
will be moved to the destination layer; or if the destination layer is
the one containing the original recipe, the recipe will be overwritten;
otherwise a bbappend will be created to apply the changes. In all cases
the layer path can be loosely specified - it could be a layer name, or
a partial path into a recipe. In the case of upgrades, devtool finish
will also take care of deleting the old recipe.
This avoids the user having to figure out the correct actions when
they're done - they just do "devtool finish recipename layername" and
it saves their work and then removes the recipe from the workspace.
Addresses [YOCTO #8594].
(From OE-Core rev: fa550fcb9333d59b28fc0e4aebde888831410f5c)
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>
This provides us with the information we need to remove the original
version recipe and associated files when running "devtool finish" after
"devtool upgrade".
(From OE-Core rev: 92eb42c347af919cd9f8739515fdf806c12b5ba8)
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>
* Allow the function to be called with the base layer path (in which
case it will just return the same path)
* Ensure that the function doesn't recurse indefinitely if it's called
on a file that's not inside a layer
* Correct the doc comment for accuracy
(From OE-Core rev: 912026d85c2f535be2f60c45979162ea25c7f356)
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>
During a parallel build it's possible for unrelated shlib files to be removed if
the recipe they came from is about to be rebuilt. They can't be involved in the
dependency chains as otherwise they wouldn't be removed, so just silently handle
files disappearing.
[ YOCTO #8555 ]
(From OE-Core rev: 1e355da3fda742c78d99ddd2ee5caa9df52f92e1)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add ability to specify extra_bootargs (kernel cmdline) in order to enable systemd
debug log in images that enables systemd init.
[YOCTO #9299]
(From OE-Core rev: 09d62551c289b5607341a4f9c46eecd6390ad774)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This application needs GTK+ 2 which we're trying to move away from for Sato
images.
(From OE-Core rev: 5e52f208a17e7122209675fa96de6e7807c62feb)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With Python 3, the encoding of a file is significant; several recipes in
OE-Core have patches which are not fully utf-8 decodable e.g. man,
lrzsz, and gstreamer1.0-libav, leading to errors when using devtool's
modify, upgrade or extract subcommands on these recipes. To work around
this, try reading the patch file as utf-8 first and if that fails try
latin-1 before giving up.
(From OE-Core rev: 7f4d7a6f51569954e204f110827a8ce256bcdc68)
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 new pid monitoring code we have for recent versions of
gnome-terminal we can just drop the --disable-factory code now since
the other solution handles this case as well.
(From OE-Core rev: ed4957c444a2982c19e2f1f96d9afb2a992c1daf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently gnome-terminal just returns straight away, opening a terminal in a new
separate process we have no insight into. For patch resolution, this leads to
spawning many different terminal windows, for pydevshell, it just flashes a window
up and then closes.
We need to block until the command completes but gnome-terminal gives us no way
to do this. We therefore write the pid to a file using a "phonehome" wrapper
script, then monitor the pid until it exits.
[YOCTO #7254]
(also fixing do_devpyshell)
(From OE-Core rev: 76e8ab47c936674b8bb9bf1c48de53b30f5bf74a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This test refers to a function that no longer exists after the eSDK
install double execution of bitbake has been removed, and since
test_prepare_unexpected is the only test in this module, drop the
entire module. We can easily resurrect it if we have unit tests to add
in the future.
(From OE-Core rev: 7e792a22e62904ed2dafb1ea214911235e3f3efc)
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>
The progress patches change the output slightly, update the test to
deal with this.
(From OE-Core rev: 90dbd838fa97c89ace5cb147aa5cff39b94178b1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was a copy-and-paste of subprocess.check_output() from when we supported
Python <2.7, so simply delete it and use subprocess.check_output() instead.
(From OE-Core rev: b1f2d9ed8d4dc89c9e669f43f546463ccc2a76b9)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're building the extensible SDK we don't need to see the "Writing
locked sigs" message; it's only necessary when the user explicitly runs
bitbake -S none <target>.
(From OE-Core rev: 440a351ee13920045c9d3e51882908f7b3f01d35)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the new task progress functionality to report progress during
do_rootfs. This is a little coarse and ideally we would have some
progress within the installation section, but it's better than
nothing.
(From OE-Core rev: 370f08d434480c1790950e40db8f7687da78cb14)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a GTK+3 application, so we don't need to ship GTK+ 2 in Sato just for
the SDK test suite.
[ YOCTO #9780 ]
(From OE-Core rev: 53fcfe4348a2ca727844f2b0bd3fca2902cbdda0)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The test test_syslog_help doesn't exist, so skipping unless it passed just
produced a warning.
(From OE-Core rev: 9856fe02bf30cd9e834a7d324e357070f4d7735f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using this option the script appends test results into a 'global results
file'. A CSV-formatted output of the results. This option is to provide
compatibility with the old build-perf-test.sh.
(From OE-Core rev: e9f18e63220e452f2b0c878998e57d944ae83980)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
BuildPerfTestRunner determines these from the Git repository under which
it is being run (i.e. where the build directory exists). The branch and
revision may be defined/overridden with OE_BUILDPERFTEST_GIT_BRANCH
and OE_BUILDPERFTEST_GIT_BRANCH environment variables, if needed. This
makes it possible to run the build performance test script even if the
top directory is not a git repository clone, for example.
(From OE-Core rev: e6004582454d8c6a18f617c12e6e408ded5be8df)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A new helper module for easier interaction with Git repositories.
Provides GitRepo class that represents one local Git repository clone.
The GitRepo class currently only has one method, run_cmd(), for running
arbitrary git commands in the repository. More specialized methods for
commonly used git operations can be added later.
(From OE-Core rev: 4eaf434f885afbda03fe67ab6e9ff291c7a9c77e)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Re-implement "test1_p3" from build-perf-test.sh which measures
'bitbake core-image-sato' with rm_work enabled.
(From OE-Core rev: bfe48d343e8a281760da0b6744c08d47039f93e0)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
