This class was added by me back in 2007 and has changed one for a whitespace issue
since. It only has two lines and neither are particularly useful, one was replaced
by the nopackages class, the other adding recursive dependencies also is now
mainly problematic adding tons of unneeded dependencies. The name is hard to
understand and the class doesn't have a clear purpose. Drop it.
Remove the references in devtool (which may be the one reason to keep it around
but in my view still not worth it).
(From OE-Core rev: 6e2cbfc561dac89bf9183d24d90e52f7d9117826)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The class adds an emtpy PACKAGES setting but most code now uses the
nopackages class which is much clearer. It also adds recursive do_build
dependencies which don't really serve any useful purpose any more.
Simplify the code and drop the class use.
(From OE-Core rev: 030d56e2e8ece93472adc51fe467221d846c9ac0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 'meta' is old and not very useful. It empties PACKAGES and creates
recursive do_build dependencies.
We shouldn't need such recursive build dependencies any more so simplify the code.
This does cause behaviour changes as some dependencies are no longer built.
It did show up issues with qemu-helper-native handling for example but those
issues look like real races and the underlying dependency chains were not correct.
'bitbake XXX --runall build' would give the previous behaviour.
(From OE-Core rev: 41d7f1aa2cc9ef5dba4db38435402d4c9c0a63e1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a controversial change which removes the recursive dependencies
from the do_build target of packaging tasks of recipes.
Currently this means when you "bitbake <image>" or "bitbake <recipe>",
the packaging tasks run for all packaging backends enabled for all recipes
in the dependency chain. The same therefore then applies to images.
We don't actually need that, it is a convinience thing. Removing it
massively simplifies the task graph and causes much fewer tasks to execute
in many common scenarios. It also means less sstate is fetched for
example when building an image.
This means when building a recipe all package formats would be built
but when building an image, only the format used by the image would be
generated. This should be an improvement in most cases but some CI systems
may need to be explict about what they're building.
'bitbake XXX --runall build' would give the previous behaviour.
(From OE-Core rev: 220d29a5abb5be8b80c64d8f2f48949bc8c534a3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, if you change the site files, nothing rebuilds since they are
not accounted for in task checksums. They could/should be through the
file-checksums task flag. We need to cache all the files looked for,
whether the exist or not so that if they do exist and didn't,
the checksum also changes.
This gets complicated by the need to clean out hardcoded build
paths from the variable and that other layers can have site files.
This patch adds this functionality. A new variable, SITEINFO_PATHVARS
is added which controls which substitutions to make on the file-checksum
values to remove the hardcoded paths. Layers adding site files will need
to set this to a variable that has the layer path in it and is excluded
from task hashes (COREBASE is the one the core layer uses).
This patch will cause yocto-check-layer to fail for some layers
where site files are added yet the layer isn't a machine specific layer.
This is arguable correct since these additional site files apply to
all recipes and things from a layer like core could be changed by such
changes so it is right they should rebuild. There is a determinism issue
potentially there if not. meta-openembedded does have some such references
but looking at them they should move to core or likely just be removed as
most look obsolete anyway.
[YOCTO #13729]
(From OE-Core rev: 29daffc2410f06f36b779d5bf1fd1ef6e900ca8f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The populate_sysroot task isn't enough for qemu-helper-native, we need
it's addto_recipe_sysroot task. This corrects what amounts to bad
dependency information to be explicit.
(From OE-Core rev: 55623420208bc4c77a61492d2bbcbc71d3123acd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
recipe for libidl has long been deleted
(From OE-Core rev: 587d0b51b09cd426dc4b2b7646fa063d10ae4f2f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream database uses both "connman" and "connection_manager" to report CVEs
(From OE-Core rev: eadf7bb17289731be9747822e3d4084ab69cf109)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The target_dumper property is only set by the QemuTarget subclass, so
assign a default value and check it isn't None before calling it.
(From OE-Core rev: add36cf85380bf7dc5339a9d65f951923317440b)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This hasn't been needed since libsoup 2.65.2.
(From OE-Core rev: 250a3f9a804917c8a9427d0209365d27b1b8fa4a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For example we don't need to talk about historic build dependencies.
(From OE-Core rev: b67ae98ef803b889fceb5713c539504d48f1a926)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All the users of the cross class I could find redefine the do_install
function. It is unusual and likely undesirable for the class to be
changing this from the default and likely a leftover from different
times. Remove it as it isn't doing anything.
[YOCTO #9272]
(From OE-Core rev: 72f0e03a6909e6856510d913863fc9301de32cec)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
intltool was replaced with gettext in the 0.8 release.
(From OE-Core rev: 0438c8e73419c0a81bbb42f777eb3e36f4878e79)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
aarch64/qemuarm64 has had graphics support for some time. Remove this
exclusion and allow graphics tests to be against qemuarm64.
(From OE-Core rev: 1b436e4894663fa76865636b0b41c0c1503cc3bf)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* with many native dependencies excluded in:
layer.conf: Extend recipes not to install without explict dependencies
this was now failing with:
ERROR: Cannot find Ninja
and after adding ninja-native to DEPENDS it was failing due to missing meson as well:
/OE/build/oe-core/tmp-glibc/work/x86_64-linux/qemu-native/6.0.0-r0/qemu-6.0.0/configure: 6415: --version: not found
/OE/build/oe-core/tmp-glibc/work/x86_64-linux/qemu-native/6.0.0-r0/qemu-6.0.0/configure: 6418: setup: not found
(From OE-Core rev: 7b2dfb49105e6465c5436869863e6a9720c60bbd)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was being provided by other pieces of the dependency chain but is
specifically required by configure and could fail if those pieces come
from sstate. Fix such builds by adding the missing dependency.
(From OE-Core rev: ba2587beb2a3fb0ef9139f846e161542d2c5c4ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Various recipes were missing a pkgconfig inherit or pkgconfig-native
dependency despite using pkgconfig.
Add the inherit to igt-gpu-tools/gdb/libmodulemd/libwpe/xwayland/waffle
shaderc/iputils/wpebackend-fdo/lttng-ust/cargo.
(From OE-Core rev: 777d9744570c2dc119dc5d04985896bbb1da5885)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Issue is in an experimental extension we don't have/use. Could also
be windows only.
(From OE-Core rev: 6f5770b49f06168e3d6914bd92f0594bd05f1f8f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Includes a fix for CVE-2021-40528.
(From OE-Core rev: 24664297abd3844902fa40c21e4e975d89f40383)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes it easier for the AB scripts (particularly, collect-results)
to access and archive these items, as they can contain useful information
when ptests or other qemu tests fail (and also if they don't fail).
[YOCTO #14518]
(From OE-Core rev: 1965b344abcff0ba584136f929b4a14645f1585e)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It fails to run task rust_create_wrappers of recipe which inherit
rust-common.bbclass such as rust-hello-world if no host ccache exists:
| DEBUG: Executing shell function do_rust_create_wrappers
| /path/to/project/tmp-glibc/work/core2-64-wrs-linux/rust-hello-world/git-r0/temp/run.do_rust_create_wrappers.3422:
line 179: ccache: command not found
Run task rust_create_wrappers before do_prepare_recipe_sysroot to make
sure required tools such as ccache exist.
(From OE-Core rev: 46575e0d5b9e722558b64e22ed928e6d7b2c654a)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
collections.abc is available since 3.3 and doesn't need special handling.
(From OE-Core rev: 01152c9410ba00274c8415a5d914dc33dfd0cf46)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
rngd needs to start after `systemd-udev-settle` in order for the kernel
modules of the random source hardware to be loaded before it is started.
However, since the `rngd.service` does not require or want
`systemd-udev-settle.service` it might not be scheduled for start and
the `After=systemd-udev-settle.service` there has no effect.
Adding `Wants=systemd-udev-settle.service` provides a weak requirement
to it, so that the `rngd` is started after it, if possible.
(From OE-Core rev: e9715d4234eb7b45dee8b323799014646f0a1b07)
Signed-off-by: Claudius Heine <ch@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Switch to using virtio graphics for the Arm QEMU machines. You will
noticed the difference in the dmesg by seeing:
[ 2.693337] [drm] pci: virtio-gpu-pci detected at 0000:00:10.0
(From OE-Core rev: 961158653170f53de58672e474c41f1533f469fc)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When attempting to execute runqemu on qemuarmv5, the following error is
encountered:
runqemu - ERROR - Failed to run qemu: qemu-system-arm: versatilepb: memory size must not exceed 256MB
To work around this, limit the QB_MEM size for qemuarmv5, similar to
what is being done for qemumips.
(From OE-Core rev: 6450138afebffcc55ab32afadd5fb979274fff2b)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There has not been a release since 2018, the 1.7.0 release. A number of
recent improvements around thumb and clang debugging prompted this move
to a newer version.
The patch is no longer necessary as it was a backport patch.
(From OE-Core rev: b98c739aa1204ecd842278a6e36a56243bfbc2a5)
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sometimes we can find release tarballs from sourceforge are not fully
distributed along all download mirrors leading to fetching faiilures,
depending on what download mirror will be chosen by sourceforge
servers.
As the project moved to github anyway, it's better to pull the tarballs
directly from github releases - serving the very same static artifacts.
Add an override UPSTREAM_CHECK_URI to enable devtool upgrade checks
(From OE-Core rev: 9b5b797b0e9e6f2cb3e29be92c4f9b763c4a41e9)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Expat isn't a license name we have, use MIT instead.
(From OE-Core rev: b1821691c2d7eafb29cf182fc1f2ec7b0cc8340f)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The TPM2 support is used, among other things, for unlocking encrypted
volumes.
(From OE-Core rev: 7b7dfbfaedde775add3be7a3cb44b115d8ec5036)
Signed-off-by: Kristian Klausen <kristian@klausen.dk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Before, even if the code was seemingly written to search through all
licenses in ${COMMON_LICENSE_DIR} and ${LICENSE_PATH}, it would
actually bail out after only searching ${COMMON_LICENSE_DIR} due to
the exception handling.
Also refrain from using f-strings.
(From OE-Core rev: f58d54b31a1ddb4e60eb07365bfb7dfe78ed56af)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable tk in PACKAGECONFIG as below in conf/local.conf.
PACKAGECONFIG_append_pn-python3 = " tk"
$ bitbake lib32-python3
ERROR: lib32-python3-3.9.6-r0 do_package_qa: QA Issue: /usr/lib/python3.9/lib-dynload/_tkinter.cpython-39-i386-linux-gnu.so contained in package lib32-python3-tkinter requires libtk8.6.so, but no providers found in RDEPENDS_lib32-python3-tkinter? [file-rdeps]
ERROR: lib32-python3-3.9.6-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
So add MLPREFIX prefix to fix the above issue.
(From OE-Core rev: 4a839d7c66e4589050ce3f145a8c7cf820e6b35d)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of FILERDEPENDS_*, the FILERDEPENDS should be FILERDEPENDS:*
such as FILERDEPENDS:/usr/bin/python3.9:lib32-python3-core as an example,
so switch to new override syntax to make sure the related check in effect.
(From OE-Core rev: 6e5650be0ce5575da1ce5b6ea8b24a82ec7b1210)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When multilib enabled, instead of checking RDEPENDS_lib32-python3-core,
we should check RDEPENDS:lib32-python3-core as new override syntax applied.
So switch to new override syntax to make sure the related RDEPENDS check
logic is in effect.
(From OE-Core rev: 63d53e515d8f3d92a4143dc25c2e639c7fb8c3fb)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The package task references WORKDIR at it's top level and we can't
easily make the timestamp for that determnistic due to writes to files
there and in other subdirs. We could try and force it to a specific value
but it is easier to just remove it from the package task, we don't need
it there or care about it in this case.
(From OE-Core rev: 9cceeb906527f90d8dd3aad75aa3a8805e2a1df5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bash keeps a count of the number of times make was invoked on a directory
and changes the output versioning accordingly. We want deterministic output
so disable this behaviour.
(From OE-Core rev: 13a039e03195a47c750d5901e96fe81cf523481f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When creating packages we build them with --clamp-mtime and use
SOURCE_DATE_EPOCH as the maximum mtime. This makes the end packages
reproducible. The data stored in sstate for do_package and the package
task doesn't benefit from this though and have varying timestamps.
This means their outhash varies and means hash equivalance isn't
effective at all and doesn't work as intended/desired.
We could create the sstate archives with the same clamping however
that would lead to different results depending on whether a task was
installed from sstate or not. Making that differ is a path to madness.
It also wouldn't fix the outhash of the task to be determninistic
without clamping of the date in the hash calculation code.
Instead, iterate over the files in sstate output and clamp them at
the code level. This isn't ideal but does make the file timestamps
determnistic everywhere and means we don't have to change the hash
calculation code.
This issue can be clearly seen looking at the do_package outhash for
a recipe which you then re-run the package task for after adding
something like whitespace to the install task. The outhash shouldn't
change but currently does.
(From OE-Core rev: c3b3cc4745811b48b9193f83889946b2e1788932)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pkgdata output isn't entirely deterministic since the sorting of some of the
variables can change. This likely doesn't have any real world effect but fix
this with some additional sorting as it allows better hash equivalency of
task output.
(From OE-Core rev: a30c4de8a0b309c398c42fe710c45a4df7fcc64d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The preinst data in pkgdata will not expand out the ${XXX_PARAM} variables
since they don't use a package suffix. It happens that the final expansion
used for the packages is corrected by a second trip through the datastore.
The first version is used for calculation of the task output hash and
recent improvements in hash reuse showed this data wasn't using included
in the hashes, meaning for example builds with dynamic IDs were mixing
sstate with builds using static IDs. The result was a mess.
Fix this by expanding the data in the preinst correctly to use the
package specific _PARAM values.
(From OE-Core rev: 375430f249e7e0b6622e566e2478b40ba7e606ab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These three CVEs are specific to the Node package node-tar.
exclude: CVE-2021-37701 CVE-2021-37712 CVE-2021-37713
(From OE-Core rev: 9f9317a02d73c1e5aea026683a037e52c996c7bb)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
raw.h has been dropped in linux-libc-headers-5.14 leading to:
configure: error: raw selected, but required raw.h header file not available
WARNING: exit code 1 from a shell command.
(From OE-Core rev: 7f577c10913104860121f682b9b3754870c4db23)
Signed-off-by: MarkusVolk <f_l_k@t-online.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since libdebuginfo was default distro feature[1], cross build of binutils
has been broken due to absence of pkg-config. To find the dependency
properly, we should inherit pkgconfig bbclass.
checking for aarch64-poky-linux-pkg-config... no
checking for pkg-config... no
checking whether to use debuginfod... yes
checking for libdebuginfod >= 0.179... no
configure: error: "--with-debuginfod was given, but libdebuginfod is missing or unusable."
[1]: https://lists.openembedded.org/g/openembedded-core/message/150666
(From OE-Core rev: 50154869b496cf63a4fae2c8278350fcf9a2591d)
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When fetching sstate, SRCPV can be expanded withuin PV which breaks the
sstate fetcher as other variables like SRC_URI are changed by the fetcher
code. Expand the variable before doing this to avoid those problems and
hence avoid setscene task failures with remote sstate storage in git
recipes.
(From OE-Core rev: 0d9d7acebe0be42d4cf8a30ecbbbbcb2dfd16a4b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
rpm output packages currently depend on the value of XZ_THREADS which
is ok if left to the default value but problematic if system limits
are set such as on the autobuilder.
Force the value to a specific one in the hashes for better sstate reuse
and consistent rpm task checksums.
(From OE-Core rev: 0296dc71c01d1b7953d74ef37d56429e2f4fcfab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
An out-of-bounds array read in the apr_time_exp*() functions was fixed in the
Apache Portable Runtime 1.6.3 release (CVE-2017-12613). The fix for this issue
was not carried forward to the APR 1.7.x branch, and hence version 1.7.0 regressed
compared to 1.6.3 and is vulnerable to the same issue.
(From OE-Core rev: d52b78c75323fb254b5d0216f9183573b353abd3)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
0001-rpm-rpmio.c-restrict-virtual-memory-usage-if-limit-s.patch changed
to avoid critical issues
Handled return values of getrlimit() and lzma_cputhreads() functions
to avoid unexpected behaviours like devide by zero and potential read
of uninitialized variable 'virtual_memory'
Upstream-Status: Pending [merge of multithreading patches to upstream]
(From OE-Core rev: 5aae9c2cb464350bc443a0f60fd6602942e61f46)
Signed-off-by: Ranjitsinh Rathod <ranjitsinh.rathod@kpit.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
