Test case ID 1422 is not correct for this issue, the correct test
case ID for test_qemu is 1424.
(From OE-Core rev: d214b1dc9339c4873156934f5291b9373a11471f)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The beaglebone BSP provided in this layer is a reference implementation
usingonly mainline components available in core Yocto Project layers,
whereas Texas Instruments maintain a full-featured BSP in the meta-ti
layer.
Rename the reference machine to prevent namespace collisions with the
version maintained by the SoC vendor.
[YOCTO #12326]
(From meta-yocto rev: e32882938eca7f50548deab84dab78b4aef31b95)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a simple test case to being testing of the Go toolchain:
1) build meta-go-toolchain
2) create a temp directory and install the generated Go toolchain within
3) fetch an archive of the Go Dep tool
4) create an appropriately laid out GOROOT and inflate the dep archive there
5) build the dep command with the SDK's Go toolchain and check it returned
successfully.
[YOCTO #12152]
(From OE-Core rev: bca999644e28e1666357bcbeab685547c6f9dd65)
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>
With the removal of yocto-bsp and yocto-kernel there are no longer any users
of this library, therefore delete it.
(From meta-yocto rev: 0d44e59bfaa95162cf2133df1d08f6419314bb8e)
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>
yocto-kernel is not actively maintained and requires active feature
development to make it a useful and compelling tool.
(From meta-yocto rev: fae757e972c7df9adba4b012784c0b161e54eb82)
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>
The bitake-layers tool in bitbake is much more featurful, widely used and
better maintained.
(From meta-yocto rev: 803f6256fde4a7d1d4ef1f365b6f10252e99674e)
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>
The yocto-bsp script has been removed, thus there's no need for this test
for the script.
(From meta-yocto rev: 280130bb02b550e882eb203328689b1526fa462c)
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>
The yocto-bsp tool is not actively maintained and requires active
feature development to make it a useful and compelling tool.
(From meta-yocto rev: f659eefcb0914acabe453991711b3a64a87ef9c1)
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>
* Fedora 24 reached end-of-life on 2017-08-08 and hasn't been tested in
some time.
* Fedora 25 reaches end-of-life in Q4 2017 and is exhibiting a bug which
makes it an extremely unreliable host OS for workers on the Yocto
Autobuilder. For that reason we'll no longer be using this distro on the
Yocto Autobuilder and thus cannot claim the distro is sanity tested.
(From meta-yocto rev: 976ee9a60ab786ae07057577975e3b91e388cd47)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to match the other meta-yocto-bsp MACHINE definitions add wic.bmap
to the produced images.
(From meta-yocto rev: 43c3e1194bf789d16c3e9bd41b8aae0098362677)
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>
The new Ubuntu releases on 2017-04-13, after cutoff for Yocto Project 2.3.
I've been running builds of some images and a world build in a container
over the past couple of days without issue. I've also run a complete
oe-selftest run (with SANITY_TESTED_DISTROS = "") and did not observe any
errors.
(From meta-yocto rev: ecdaf38e0b6beaeaf8ea7f804ca73a18f0dbe371)
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>
IMAGE_EXTENSION_live is no longer used. It was used by Hob to map the
live image type, but Hob is no longer part of the Bitbake codebase.
(From OE-Core rev: 2b30dcdc903c1b0c18e14e39b954177628d058bd)
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>
Mandriva is no longer maintained, with its last release having been in
2011. It's no longer useful as a yard-stick distro, therefore drop it from
distro_check.create_distro_packages_list()
(From OE-Core rev: 4e1bef31e04044d26a948a9682a5122b46d15c0f)
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>
Since openSUSE switched to their dual development model of Leap and
Tumbleweed the urls we need to check for package lists has changed. Update
get_latest_released_opensuse_source_package_list() to use the new Leap
urls.
(From OE-Core rev: 263da717ba689eb7efe99234566e2b474e8ce95a)
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>
Ensure that when an item fetched from a premirror has an invalid checksum the
fetcher falls back to the usual logic of trying the upstream and any configured
mirrors.
(Bitbake rev: 022adb30dbb0df764c9fb515918cb9a88e4f8d6f)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By exporting KBUILD_BUILD_USER with a pre-defined value we improve the
reproducibility of the kernel and remove the requirement for whoami in the
HOSTTOOLS.
KBUILD_BUILD_HOST also helps improve the reproducibility of the kernel.
For more kernel reproducibility options see:
https://lwn.net/Articles/437864/
(From OE-Core rev: a5a14edb5573e33667b63b1e34cb4e19d075e8e8)
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>
All build project test cases will try to copy the requested source
artefacts from DL_DIR before fetching. This testcase is referencing bzipped
tarball whereas the recipe fetches a gzipped tarball.
Switch to fetching the gzipped tarball in the test case so that we're able
to use a cached tarball from DL_DIR
(From OE-Core rev: 27a5883e8ae01e69f5425efe8b035bea7087b2f9)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Building gcc-cross-initial with GCC7 on the host fails due to the
comparison of a pointer to an integer in ubsan_use_new_style_p, which
is forbidden by ISO C++:
ubsan.c:1474:23: error: ISO C++ forbids comparison between pointer and
integer [-fpermissive]
|| xloc.file == '\0' || xloc.file[0] == '\xff'
Backport the fix from upstream GCC to enable the build with GCC 7
(From OE-Core rev: 7a7fcbab0365b9501c737dbc02715be14dda72a3)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport a fix from upstream for a -Wformat-truncation=2 warning
and implement a simple fix for a -Wimplicit-fallthrough warning.
(From OE-Core rev: aaf4c4f3d09ac3897205417eb15e19d54e0c0d05)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than hard-coding the tmpdir for TargetBuildProject to /tmp allow the
parent's default handling to define an appropriate tmpdir.
(From OE-Core rev: 901659a51cd53625a93f57a9c5865e90a07ec09d)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Don't hard-code /tmp as the tmpdir, instead use WORKDIR as the tmpdir if the
instantiater doesn't specify a value.
(From OE-Core rev: c43c966e0ed4ed836bdf90b1d4c3f2f45426f1ec)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than hardcoding /tmp as the default tmpdir make a more unique tmpdir
with tempfile.mkdtemp() when the caller doesn't specify a tmpdir value.
(From OE-Core rev: 9425c2658fea0b45468a04574cd77bffc6668a8d)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* devtool: oeqa.selftest.devtool.DevtoolTests is taking 4 or more hours on the
autobuilder because the cleanall call deletes the tarball of the kernel
source, forcing a large clone which is especially long on an NFS mount.
The cleanall invocation isn't really required here and switching to clean
instead should avoid hours of re-cloning the same repository each time we
run oe-selftest on the autobuilder.
* buildoptions: We only need to ensure the first image isn't an incremental
image, clean will suffice here.
* runtime-test: no need to clean up the artefacts generated during the test,
let's leave that to a higher level process rather than using the cleanall
hammer.
(From OE-Core rev: 9c948d3de08f158387e08a17cdc0cedc7d26bb54)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This postfunc assumes it's run from S, whereas that seems not to always
be the case in practice. Explicitly define the full path of the file
we wish to sed.
(From OE-Core rev: 6486dd71c6c9977e5d67fd803d1bd85001654b5a)
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>
GPLv2 recipes have been moved to a new layer (meta-gplv2), instead of
readline perform this test on the selftest-ed recipe in meta-selftest
which has gplv2 and gplv3 variants.
Tested with oe-selftest -r bbtests.BitbakeTests.test_non_gplv3
(From OE-Core rev: 35b244b292cddb3ded31c2766fb1313511343f06)
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>
Use a recipe which is bundled in the meta-selftest layer for this test,
rather than relying on OE-Core remaining static (or updating the tests
when OE-Core changes recipes).
Tested with oe-selftest -r oescripts.TestScripts.test_cleanup_workdir
(From OE-Core rev: f8aabeb1a755f3312782a7b64fe863c155510b33)
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>
The oe-selftest oescripts.TestScripts.test_cleanup_workdir was using
gzip and the GPLv2 variant to test cleanup of the workdir. This broke
with the removal of GPLv2 recipes from OE-Core.
Instead of relying on recipes in OE-Core remaining static we should
ensure that meta-selftest provides recipes required for the tests to pass.
To that end we take a copy of the current GPLv2 and GPLv3 variants of ed
and include them in meta-selftest as new recipes.
We chose ed over gzip as gzip has dependencies which would require
additional GPLv2 recipes to be included in meta-selftest.
(From OE-Core rev: 2ac83239698c403bb575e6c5b19f19fcffa389ed)
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>
Since 59a99cd8 "oeqa/sdk: Updates sanity tests for minimal eSDK"
we can now run oe-selftests against a minimal eSDK.
We need to increase the layer version so that we can detect this
change in behaviour in our automated testing.
(From OE-Core rev: def3800c7e58d9d1b54ea1df27b190a0f6d1d544)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update to the newly minted 1.8.2, dropping several patches we'd
backported since the last release.
(From OE-Core rev: 6437f14c9177fd7ec7a9b6bca873362b0c94abfb)
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>
Remove several old/untested distros from the list:
* poky-1.8 and poky-2.0 are no longer supported releases
* ubuntu-14.04 is an LTS but we plan to remove it from the
project's autobuilder cluster as the kernel is old and
it doesn't use systemd -- therefore this will no longer
be tested.
* ubuntu-14.10 and ubuntu-15.10 are no longer supported
* fedora-22 and fedora-23 are EOL
* opensuse-13.2 is discontinued
Add opensuse-42.2, it's the openSUSE version we run on the Yocto
Project autobuilder cluster.
The distro support plan is documented on the Yocto Project wiki:
https://wiki.yoctoproject.org/wiki/Distro_Testing_Plan
they are easily summarised as:
- Fedora: most recent 2 releases
- Ubuntu: most recent LTS and latest release, unless they are the same
in which case the most recent 2 releases
- CentOS: latest release
- openSUSE: latest release
(From meta-yocto rev: ba5ad19cbe9066823fe3a3b432a893f4cf67be47)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CCACHE_PATH was added to the toolchain-scripts in commit
1d31ddb856a80ba9da1a64ed5d701dc0f7351ef7 without a detailed
explanation as to why. This commit removes that environment
variable as it's causing failures since the introduction of
host_gcc_version() to oe.utils in
d36f41e5658bbbb6080ee833027879c119edf3e0, as used by
uninative to determine NATIVELSBSTRING.
This causes errors when the host has ccache available in in PATH
- host_gcc_version() fails because ccache has been told to only
look for the compiler in CCACHE_PATH and can't find gcc in order
to check its version. Toolchain compilers aren't detected due to
the binaries being prefixed with the triplet of the target.
(From OE-Core rev: e47fb403c2cb472d2666ed3ba4b10933467c8c7b)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream have removed the file from zlib.net as a new version has
been released, switch to fetching from the official sourceforge
mirror.
[YOCTO #10879]
(From OE-Core rev: bb99e4a620efd59556539c156cd98ea23aae74c8)
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>
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\)
(a follow on patch to fix up a few recent introductions)
(Bitbake rev: f9961fd5beb31d5ab9656a5be59f7ab3effef2f0)
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>
getVarFlag() now defaults to expanding by default, thus remove the
True option from getVarFlag() calls with a regex search and
replace.
Search made with the following regex:
getVarFlag ?\(( ?[^,()]*, ?[^,()]*), True\)
(From OE-Core rev: 3e4806063fe11092b2307f113a6c0b0f04104091)
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>
getVarFlag() now defaults to expanding by default, thus remove the
True option from getVarFlag() calls with a regex search and
replace.
Search made with the following regex:
getVarFlag ?\(( ?[^,()]*, ?[^,()]*), True\)
(From OE-Core rev: 2dea9e490a98377010b3d4118d054814c317a735)
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>
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 <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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: 7c552996597faaee2fbee185b250c0ee30ea3b5f)
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>
getVarFlag() now defaults to expanding by default, thus remove the
True option from getVarFlag() calls with a regex search and
replace.
Search made with the following regex:
getVarFlag ?\(( ?[^,()]*, ?[^,()]*), True\)
(Bitbake rev: c19baa8c19ea8ab9b9b64fd30298d8764c6fd2cd)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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\)
(Bitbake rev: 3b45c479de8640f92dd1d9f147b02e1eecfaadc8)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some rolling release distros, such as Arch Linux, don't include a
VERSION_ID field in their os-release file.
Change release_dict_osr() to better handle this optional field
being absent.
Further improve the resilience of the release_dict_*() methods by
always returning a dict and using dict.get() in distro_identifier()
to supply a default, empty string, value when then key is missing.
(From OE-Core rev: e36066dcc3b56cac1c695370ea178b566c0ebfd6)
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>
The distribution identifier determined by oe.lsb.distro_identifier()
is now returned as a lowercase string. Update the values for tested
distros to match.
(From meta-yocto rev: cb171bdc9b8dc485b25b9176949427f6d755aeec)
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>
The LSB Distributor ID and os-release NAME differ for most of the
distributions tested by the Yocto Project (CentOS, Debian, Fedora,
openSUSE and Ubuntu) however for all but openSUSE the os-release ID
matches the LSB Distributor ID when both are lowered before
comparison.
Therefore, in order to improve the consistency of identification of
a distribution, switch to using the os-release ID and converting
the ID value to lowercase.
Table showing comparison of LSB Distributor ID to os-release fields NAME
and ID for current Yocto Project supported host distributions:
Distribution | Version | Distributor ID | NAME | ID |
-------------------------------------------------------------------------
CentOS | 7 | CentOS | CentOS Linux | centos |
Debian | 8 | Debian | Debian GNU/Linux | debian |
Fedora | 23 | Fedora | Fedora | fedora |
Fedora | 24 | Fedora | Fedora | fedora |
openSUSE | 13.2 | openSUSE project | openSUSE | opensuse |
openSUSE | 42.1 | SUSE LINUX | openSUSE Leap | opensuse |
Ubuntu | 14.04 | Ubuntu | Ubuntu | ubuntu |
Ubuntu | 16.04 | Ubuntu | Ubuntu | ubuntu |
[YOCTO #10591]
(From OE-Core rev: 8689e5618d45c2119134ea64754430c06a93ea09)
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>
os-release(5) is an increasingly standard source of operating system
identification and more likely to be present on modern OS deployments, i.e.
many container variants of common distros include os-release and not the
lsb_release tool.
Therefore we should favour parsing /etc/os-release in distro_identifier(),
try lsb_release when that fails and finally fall back on various distro
specific sources of OS identification.
(From OE-Core rev: fc4eddecddec68d03a985086fa32db40ad0c7bfc)
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>
Rather than have the distro_identifier method look for different keys in
the dict depending on the source ensure that each function for retrieving
release data uses the same key names in the returned dict.
(From OE-Core rev: 2ddd6ddaf0c5ba14ae83347eba877ac9ef179c76)
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>
There's no need to import glob inside copyhardlinktree() as it's
already imported for the entire path module.
(From OE-Core rev: 42dc4695da136a15bebb7525b1da5c2722b10a28)
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>
RM_OLD_IMAGE has been removed so don't include this variable in
sample local.conf
(From meta-yocto rev: 0a881d01ab2b0a3f721323447b4c970ab3fd4755)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since the move to put image deployment under sstate control in
d54339d4b1a7e884de636f6325ca60409ebd95ff old images are automatically
removed before a new image is deployed (the default behaviour of the
sstate logic).
RM_OLD_IMAGE is therefore no longer required to provide this
behaviour, remove the variable and its users.
(From OE-Core rev: 93631befe8b962bf99524746b49f4ebca336175c)
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>
It's not uncommon for qemumips[64] builds on the Yocto Project
autobuilder to fail during Sanity Tests after a very long timeout
period. This is due to the MIPS emulation in QEMU being slow and
some of the build tests taking a very long time on MIPS machines.
This patch works around this slowness by disabling the more
complex build tests for QEMU MIPS machines.
[YOCTO #10340]
(From OE-Core rev: 4a1c04c0d509b2cda9b2ccd5a80523c05fa279c6)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
renameat calls under pseudo were losing extended attributes.
Backport the fix for this from pseudo upstream.
[YOCTO '10349]
(From OE-Core rev: 16f6b020ebea49f012f2e65997a8d464f94d6605)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use logger.addHandler(), rather than assigning an array of Handlers
to the loggers handlers property directly, to avoid a warning from
Python 3 about unclosed files:
$ bitbake
Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.
WARNING: /home/joshuagl/Projects/poky/bitbake/lib/bb/event.py:143: ResourceWarning: unclosed file <_io.TextIOWrapper name='/home/joshuagl/Projects/poky/build/tmp/log/cooker/qemux86/20161004094928.log' mode='a' encoding='UTF-8'>
logger.handlers = [stdout]
(Bitbake rev: 1e23b1f1a80066223b98e18b163840051ac74944)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Much as with -native recipes, as addressed in commit
b15730caf0, arch specific variables
like MIPSPKGSFX_ABI were affecting -nativesdk sstate checksums for
recipes like nativesdk-glibc-initial.
Disable multilib_header for nativesdk as we don't use multilibs in
this scenario.
[YOCTO #10320]
(From OE-Core rev: f1c7b4f16dc9a7e5155108641fed8b3d98c931f3)
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>
buildtools-tarball shouldn't be regenerated when MACHINE changes,
nor should variants for other SDKMACHINE be removed from the deploy
directory when SDKMACHINE changes.
Remove target architecture dependencies so that deploy artefacts
can overlap.
(From OE-Core rev: b7d1a310f6b880e92b124a78af3c948abaab4236)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We use toolchain_create_sdk_version() in buildtools-tarball but
don't want the extra classes toolchain-scripts pulls in, therefore
split out a separate base class for this function which both
toolchain-scripts and the buildtools-tarball can inherit.
(From OE-Core rev: a398dfa654dc035c404fc12279fac9edf6403e11)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise the stamps for x86-64 and i686 uninative tarballs match
and we can't deploy both to the DEPLOYDIR.
(From OE-Core rev: fee426ae0c2b27925b05b856ada676958ee10869)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If DEPLOY_DIR_IMAGE doesn't exist during check_arg_machine() we
will attempt to guess a suitable value later when check_and_set()
calls validate_paths(), therefore this shouldn't raise an exception
(From OE-Core rev: ed8d6f391c567048bd50dc3234804915f8212cef)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a MACHINE value is passed we can't validate it by running bitbake
as the toolchain environment doesn't include the build system, we
must assume that the passed value for MACHINE is correct.
(From OE-Core rev: 2c569678566c49b3ea237ef2de0fbae782263449)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Emulate some logic from the prior, shell based, version of runqemu
to try and infer the correct setting for MACHINE from the kernel
and rootfs filenames.
(From OE-Core rev: a5adabe1414061d6864c5913dd5e66a4527838f1)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to validate and ensure all paths are set regardless of
whether runqemu was invoked with a .qemuboot.conf file or
otherwise. Split this logic out into a separate method called
during check_and_set()
(From OE-Core rev: e843b2d49a151c1fe0d2a7ba00c41d2a35775736)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise the stamps for x86-64 and i686 uninative tarballs match
and we can't deploy both to the DEPLOYDIR.
(From OE-Core rev: 2a9603759fe87d6326c145f6213ffffeb6afc6ae)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Include SDKMACHINE in the tasks stamp information and the name of
the sstate-inputdirs so that changing SDKMACHINE doesn't result in
valid output of the task being deleted when SDKMACHINE is changed.
Without this patch changing SDKMACHINE and building an SDK resulted
in toolchain installers for other SDKMACHINE's being deleted from
the deploy directoy.
[YOCTO #10275]
(From OE-Core rev: d7a06b53af0066bd12f5f42e10e82b307fd069ce)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A qemuboot conf file is a convenience but it should still be
possible to invoke runqemu without them, especially for examples
such as using the SDK with an extracted rootfs via NFS.
As read_qemuboot() is always called we need to be sure that function
can return cleanly, without throwing Exceptions, even if a qemuboot
conf file isn't found.
(From OE-Core rev: 3541c21f1976b517b79a19882240a8f36b970292)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the kernel or rootfs names written to the qemuboot.conf can't
be found, try and find the symlinked variant of the filename.
This will help usability of runqemu, for example where a user
downloads an image and associated files as the symlinked names
yet the qemuboot.conf variables point to the full, non-linked,
file names.
(From OE-Core rev: ca5a686c6e165a51f95cb6a834cd53f6f66d42d4)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will allow runqemu to fall back to trying the link name when
a file matching the full name can't be found.
(From OE-Core rev: 3ccbaaad75f0a53d8bcf6a5c748ec80c96a383bd)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make it clearer that we are looking for a file which ends with
qemuboot.conf
(From OE-Core rev: 2579e05269a14b53a54232a8bf4414ac2dfe6472)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
KERNEL_IMAGETYPE gives the filename of a symlink to the kernel,
which may not be available i.e. if the user downloads some build
artefacts to run on a local machine. It's also possible that the
link will point to a newer kernel than was intended for use with
the rootfs in the qemuboot.conf.
It's much more reliable to read the name of the file
KERNEL_IMAGETYPE is linking to and assign the full filename to
QB_DEFAULT_KERNEL.
[YOCTO #10285]
(From OE-Core rev: d57bdacab13605ada4cd9e9159c18fdcd6eeacbc)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a required binary cannot be found print some guidance pointing
to using a sourced OE build environment or a qemuboot.conf file,
based on a similar message from the previous shell-based runqemu.
(From OE-Core rev: 87cfb5165490cd4e7a8c2570ef5a62898db8395e)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've had a builder in the Yocto Project Autobuilder cluster
using Fedora 24 for some time now, I think it's safe to say it's
tested.
(From meta-yocto rev: 8774ecd08f36858db3f047b41d91113ed20aa6be)
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>
testimage.bbclass uses runqemu to execute runtime tests on a qemu
target, this means that bitbake is already running and `bitbake -e`
can't be called to obtain bitbake variables.
runqemu tries to work around being unable to read values for
bitbake variables by inferring the MACHINE from the
DEPLOY_DIR_IMAGE setting, however if a user sets that variable in
a manner which doesn't follow the systems expectations (i.e. if
running `bitbake -c testimage` against a directory of pre-generated
images in a user-specified path) the inferring of the MACHINE name
from the DEPLOY_DIR_IMAGE location will fail.
It's possible that check_arg_machine() shouldn't cause runqemu to
fail and that runqemu should proceed with the user-supplied value
even if it can't be verified. This patch simply ensures that a
workflow where the user sets DEPLOY_DIR_IMAGE continues to work
without changing too much of the runqemu code.
[YOCTO #10238]
(From OE-Core rev: f94ac02f459e2ea0fc471463966997814a67e0ca)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When runqemu is invoked from a running bitbake instance it will be
unable to call `bitbake -e` due to the lock held by the calling
bitbake instance.
Our test code sets an OE_TMPDIR environment variable from which we
can infer/guess paths. Add code to do so when self.bitbake_e can't
be set, much as the sh version of runqemu did.
[YOCTO #10240]
(From OE-Core rev: 1e8165ea2f19aecdc03ccd102ee44ef0544f0f39)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a test to ensure that oe.path.copytree() preserves extended
attributes on files.
(From OE-Core rev: 2b047b8e3218f95978e41fee13635bff9af03dd6)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Pass appropriate options to tar invocations in copytree() and
copyhardlinktree() to ensure that any extended attributes on the files
are preserved during the copy.
We have to drop the use cpio in "Copy-pass" mode in copyhardlinktree()
because cpio doesn't support extended attributes on files. Instead we
revert back to using cp with different patterns depending on whether
or not the directory contains dot files.
(From OE-Core rev: e591d69103a40ec4f76d1132a6039d9cb1555103)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
One motivation for the use of cpio in oe.path.copytree() was to
ensure that files with spaces in their names were copied. Add a new
unittest module to test the OE module with a test case for copytree
with a spaces in a filename.
(From OE-Core rev: a408f8310d9426db4439cf8db0cf49f9bfe90b3b)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update the SRCREV to 2 commits beyond the 1.8.1 tag (to the current
HEAD) in order to include a fix for the xattr performance regression
[YOCTO #9929].
(From OE-Core rev: 94eb2552cdcbe99ba684780c9a6fbbbe7328c906)
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>
In the 1.8 series of pseudo extended attribute handling was reworked
to be a property of inodes, not paths, and as a product fixed extended
attribute semantics on hardlinks. Unfortunately this rework introduced
a slow path around file deletion.
Add a patch for use by the pseudo 1.8.1 recipe which backports a fix
for this regression from the master branch of pseudo.
[YOCTO #9929]
(From OE-Core rev: 75627af164f027de0036b91854e9b926de786bcd)
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>
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>
We're no longer building CentOS 6, Debian 7 or Fedora 21 on the
Autobuilder cluster.
(From meta-yocto rev: e4d81d1bcd8aa3ecdd247b8c05a015a87f10cb5e)
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>
The openssl-c_rehash.sh script reports duplicate files and files which
don't contain a certificate or CRL by echoing a WARNING to stdout.
This warning gets picked up by the log checker during rootfs and results
in several warnings getting reported to the console during an image build.
To prevent the log from being overrun by warnings related to certificates
change these messages in openssl-c_rehash.sh to be prefixed with NOTE not
WARNING.
(From OE-Core rev: 88c25318db9f8091719b317bacd636b03d50a411)
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>
The read method of the data_stream File object now returns bytes,
not a str, so we must decode it.
(From OE-Core rev: cfae302c4996c49a8754497ea9f13f8331d6975d)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without these extra space characters the messages are ill-formatted, i.e:
'The meta-qt3 layer should be added, this layer provides Qt 3.xlibraries.
Its intended use is for passing LSB tests as Qt3 isa requirement for LSB.'
Changes to:
'The meta-qt3 layer should be added, this layer provides Qt 3.x libraries.
Its intended use is for passing LSB tests as Qt3 is a requirement for LSB.'
(From OE-Core rev: f0220cd4e686c3d28d222d434f2dbd7f0b41188c)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add "-Wformat -Wformat-security -Werror=format-security" to the default
SECURITY_CFLAGS to catch potential security vulnerabilities due to the
misuse of various string formatting functions.
These flags are widely used in distributions such as Fedora and Ubuntu,
however we have 15 recipes in OE-Core which fail to build with these
flags included and thus the flags are removed for:
- busybox
- console-tools
- cmake
- expect
- gcc
- gettext
- kexec-tools
- leafpad
- libuser
- ltp
- makedevs
- oh-puzzles
- stat
- unzip
- zip
[YOCTO #9488]
(From OE-Core rev: f335f8e744fb312b3eb599c331d08a9a6e5a8ff8)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The PACKAGES variable doesn't include all packages potentially
generated by a recipe, not least of all because it doesn't include
dynamic packages created via do_split_packages() or similar.
Instead of trying to guess which packages were generated, walk
${PKGDESTWORK}/runtime to find all package information that was
written to disk. This allows us to read all information for the
complete list of packages generated by the recipe.
For example before this patch we get SinglePackageInfo events for
9 packages from ncurses. With the patch applied we get 20 events
for all of the packages created during an ncurses build.
As a bonus we also switch to using the same postfuncs for both
do_packagedata and do_packagedata_setscene as they each result
in a PKGDESTWORK with the relevant directories and files
created.
[YOCTO #9115]
(From OE-Core rev: f1f012962a18d16b1cc22bde836cbb46fe9e6088)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have been seeing UnicodeDecodeErrors when handling the
ImagePkgList MetadataEvent in ORMWrapper's
save_target_file_information() if the event includes filenames
that include non-ASCII characters.
In the short term work around this by converting paths to the
unicode type when passing them to Django's ORM. This is a bit of
a hack but it's too late in the cycle to do anything more invasive.
[YOCTO #9142]
(Bitbake rev: f50fff03b3de02e73a3cc2eb9935f7c345dbddc4)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We were doing a string search for the literal string "require" and
assuming that a match meant the recipe uses the require keyword to
include the contents of another recipe. This test isn't very smart (it
should at least have matched on "require ") and triggers on the word
require anywhere in the recipe, i.e. the word "required" in the
DESCRIPTION of core-image-lsb.bb, and then breaks as the much smarter
regex fails to match anything.
Instead always run the regex search and only try to update the
require entry when the regex matches.
(Bitbake rev: a6add0e95d3d1e9a6a9fcabd73543bc5c278915f)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Elliot Smith <elliot.smith@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Return early in write_image_manifest () if the IMAGE_MANIFEST
variable is unset. This allows us to prevent writing of the
manifest where we prevent images being created for a recipe by
unsetting IMAGE_FSTYPES.
(From OE-Core rev: 54387be24d6a157574496f1b20b21c7fc2a51d3e)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
xattr removal doesn't work in pseudo 1.7.5, backport a patch from
pseudo master to fix this.
[YOCTO #9324]
(From OE-Core rev: e4f6156ffdc840e99b546369493aaf37c4856b3b)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We're dropping RPM 4 as it's not well maintained, therefore remove
a selftest which tests RPM 4 availability.
(From OE-Core rev: ed005dd51c121c27a89a878bfc6abfca496bf51c)
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>
Simplify the RPM code by removing support for RPM 4 now that we've
dropped the RPM 4 recipe.
(From OE-Core rev: 7db6f0a402948ce489bafadf2e389802f764f122)
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>
The RPM4 support we added to SMART doesn't appear to work, remove
it as part of the removal of RPM4 from OE-Core.
Refresh the smart-add-for-rpm-ignoresize-check.patch which was
applied after smart-rpm4-fixes.patch and doesn't apply cleanly once
that patch is removed.
(From OE-Core rev: e1108fa41742e726aa578d0298fa6397b2663ff3)
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>
RPM4 support is buggy and incomplete. As we don't have the
resources or interest to maintain it this patch removes it.
(From OE-Core rev: a6e7a86f1635be9a688c56c25e9d215ea4d2cc84)
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>
Including the entirety of DL_DIR in the generated build appliance
image adds a significant amount of space and makes the build
appliance image more awkward to distribute. Add a configuration
option to make the inclusion of sources option and default to
disabling this functionality.
(From OE-Core rev: 7975325e3d8dee159752ae2304b0c00361bfd2a7)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
hob has been removed so don't try and autostart it with the mini-x
session in the build appliance.
Remove the please_wait_dialog program which informed the user to
wait for Hob to start.
Rename the mini-x autostart file to reflect the removal of hob, we
now just start a matchbox-terminal with the environment configured.
(From OE-Core rev: cd43436def38a0a87f0cd330fa487ad5fc0748d0)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Joshua Lock