This is a preparation for making the strip_execs function callable from
devtool without going via tinfoil and a bitbake server process.
(From OE-Core rev: af8ee73cdef90b83556a7ac5e139a08108706486)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This has been tested in poky by default for a while and ew've hopefully resolved
most of the gremlins. THis is the direction we're recommending for license/manifest
requirements so set it by default for OE.
(From OE-Core rev: b34032ec22921d4fd0982c17e63732cdbbc1885a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The modesetting driver works well in qemu, so install it by default. The
plain framebuffer has been buggy in recent 6.4 kernels, a sign that it's
not getting much testing. The Xorg modesetting driver that can use more
powerful virtualised hardware is much better.
We override the default XSERVER because we want to pull in the GLX
extension to exercise that.
(From OE-Core rev: 7b5fc42488a514bf51d49ee5274731c6432efd1b)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When SPDX manifests are enabled for OE-Core, it hightlights that the SDK_NAME
default isn't working well. Add IMAGE_BASENAME to it to help avoid conflicts
between outut files.
I suspect the defaults aren't working well and most distros are already
overriding this.
(From OE-Core rev: fba8fc22898f8455bd39f9a5f21ff056f2c0cd91)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Review the last of the historical kernel CVEs. Issues which are
specific to other platforms or distributions are ignored in the kernel
recipe itself, whereas general security concerns like "ICMP leaks
information" and "USB has flaws" are ignored with more details in the
extra-exclusions file as before.
(From OE-Core rev: fe1c0b9725f88d15ba48b02b5fef01f2cf2e9d78)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If virtio-serial-device is used, the following error occurs on loongarch64:
qemu-system-loongarch64: -device virtio-serial-device: No "virtio-bus" bus found for device "virtio-serial-device"
(From OE-Core rev: 08734ec0c2083e90207559ecc659809b86b8779d)
Signed-off-by: Zang Ruochen <zangruochen@loongson.cn>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This upgrade isn't straighforward as upstream made changes. A pyenv
is now needed containing meson. This doesn't work for us for reasons
as yet unclear however it does mean we need python3native inherited
for that to stand a chance of working as otherwise host system
dependencies may be missing. For now, allow meson to work from our
sysroot via a patch. Our meson is always deterministic anyway so
we don't need their help for that.
The submodules approach used previously has changed, switch the options
for new ones to disable downloads and docs.
Some of the images binaries shipped for s390 show QA warnings for
relocations in code sections. Drop those binaries to avoid the QA
warnings since we don't need them anyway.
Drop a backported patch and refresh another.
(From OE-Core rev: a7176c3b2a7e2041b9be5dabb6b0f1e62f235f76)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These BlueZ issues were mislabelled as Linux issues, but now that the
CPE data is accurate this ignore can be removed.
(From OE-Core rev: 7f354aed364b17259a642cc97e30a0a2b8218134)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bulk of the historic kernel CVEs in this file are now handled by
the include files generated by linux/generate-cve-exclusions.py, so
remove them.
Those that remain date from 2017 or earlier, so rename the group to
'historic' and update the comment.
(From OE-Core rev: b46930641b9b5b38997b41ba8036e99387ed4225)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
rpm2cpio.sh can make calls to bunzip2 to uncompress the RPM payload that
conform the cpio file.
bzip2 is already part of HOSTTOOLS, as a link to the system installed
bzip2.
This patch add bunzip2 in HOSTOOLS list as a non-optional binary, so is
available to rpm2cpio.sh when it is required.
The currect rpm2cpio.sh has other calls to gunzip (present in HOSTOOLS),
xzcat (missing), unlzma (missing) and unzstd (present in HOSTTOOLS since
bff58d337890e804d33d7decbaa46065a4d3bba4)
Adding the missing ones will not add any new host dependency as xz-utils
is already listed as a requirement.
(From OE-Core rev: fd376a11ed8d1b79633c2572ec0b4341d3ca2f1c)
Signed-off-by: Alberto Planas <aplanas@suse.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that SRCPV isn't needed we can simplify things in a few places...
(From OE-Core rev: 843f82a246a535c353e08072f252d1dc78217872)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Source control information being present in PV used to be a hard requirement
for bitbake to operate correctly. Now that hashes are a required part of task
stamps, this requirement no longer exists.
This means we can defer the hash pieces to PKGV and simplify PV.
Use new bitbake fetcher API to inject the source revisions directly into the hash
allowing removal of some horrible code from base.bbclass and avoiding any hardcoding
about how SRCREV may or may not be used.
Use that API to object the string to append to PKGV and append that directly.
The user visible effect of this change is that PV will no longer have revision
information in it and this will now be appended to PV through PKGV when the
packages are written. Since PV is used in STAMP and WORKDIR, users will see
small directory naming and stamp naming changes.
This will mean that sstate reuse through hash equivalence where the source
revision changes but the output does not will become possible as the sstate
naming will become less specific and no longer contain the revision.
The SRCPV variable will no longer be needed in PV and is effectively now just
a null operation. Usage can be removed over time.
(From OE-Core rev: a8e7b0f932b9ea69b3a218fca18041676c65aba0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This package make it easier to generate C/C++ ABI compatible
header, library and also generate package config file.
It is built around cbindgen (https://github.com/mozilla/cbindgen)
for the header generation, it compiles the library (static or dynamic)
through cargo and finally handle the generation of a custom
package config file.
(From OE-Core rev: dfce5f9ffb5240aadae311c2a2e912a315afc703)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Native recipes are not able to use ccache currently, due to a circular
dependency between ccache-native and cmake-native.
This affects also other native recipes, but not all, imposing a
limitation in build time optimizations.
The introduction of CCACHE_NATIVE_RECIPES_ALLOWED allows the user to specify
which native recipes should use ccache, keeping it disable by default for all
native recipes.
(From OE-Core rev: 87cb2be71e0c0c123eaae6a5ae135900c95535db)
Signed-off-by: Angelo Ribeiro <Angelo.Ribeiro@criticaltechworks.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similarly to x86, ensure we have the flags to the linker operating correctly (it
defaults to 32 bit). Normally it is driven by gcc so this hasn't shown up but
it does lead to hundreds of binutils test failures.
(From OE-Core rev: 2cf9013fd8df2bb67f93ffd44ccc23453cedf42a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ensure the CPU enabled in QEMU is correct for this architecture.
(From OE-Core rev: 6e0d176c4ce2bbbd975b74e41f63e60df7e3a554)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Once, we relied upon stamps changing to rebuild. PE and PR are packaging
variables and are reflected in the taskhashes when/where they're used so
they do not need to be in STAMP.
Similarly, once, multiple versions were something which was useful in
WORKDIR but this is really just noise causing long pathnames now.
Drop PR and PE from these variables to clean up the paths a bit.
This may break some tool assumptions about paths but those are probably
things we need to fix.
(From OE-Core rev: cc83e45484656a6b577ff84817131735023daad4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
usrmerge is now required by systemd, ensure this is also added to DISTRO_FEATURES
when systemd is selected.
(From OE-Core rev: fa8c59c49940af4cb03df49f5b6a2a53d50fbefb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch is to ensure recipes get rebuilt correctly and avoid
incorrect sstate cache reuse when toggling multilib.
The following steps show one example of such incorrect sstate cache reuse.
1. enable multilib && bitbake <some_image> -c populate_sdk
2. disable multilib && bitbake <some_image> -c populate_sdk
The error message is as below:
Error:
Problem: conflicting requests
- nothing provides binutils-cross-canadian-i686 needed by packagegroup-cross-canadian-intel-x86-64-1.0-r0.x86_64_nativesdk
- nothing provides gcc-cross-canadian-i686 needed by packagegroup-cross-canadian-intel-x86-64-1.0-r0.x86_64_nativesdk
- nothing provides gdb-cross-canadian-i686 needed by packagegroup-cross-canadian-intel-x86-64-1.0-r0.x86_64_nativesdk
(try to add '--skip-broken' to skip uninstallable packages)
We get this error because packagegroup-cross-canadian recipe is
not rebuilt when it should be.
Current codes have tracked the dependency to MULTILIB_VARIANTS, as
shown in the following chain:
RDEPENDS:packagegroup-cross-canadian-intel-x86-64 ->
all_multilib_tune_values -> MULTILIB_VARIANTS.
However, MULTILIB_VARIANTS cannot automatically depend on MULTILIBS.
See some results from 'bitbake-dumpsigs' below:
List of dependencies for variable MULTILIB_VARIANTS is ['extend_variants']
Variable MULTILIB_VARIANTS value is ${@extend_variants(d,'MULTILIBS','multilib')}
It's obvious that the value of MULTILIB_VARIANTS depend on the
value of MULTILIBS, so let's set this dependency manually.
(From OE-Core rev: 9f47d8eb51816d16078a23c0cef4d697555f913f)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
we now have more rust/cargo recipes and tests that cover various use cases
so this is no longer needed.
(From OE-Core rev: 8baaf94d200f5355791ecd980727698b1ab0e539)
Signed-off-by: Frederic Martinsons <frederic.martinsons@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This provides pylibfdt, which is a runtime dependency for the dtschema
module that we already carry in oe-core.
(From OE-Core rev: 123077ecd9f3c1839da0d7b1474d689e5c6a689c)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
The CVE_STATUS should contain an information about status wich
is decoded in 3 items:
- generic status: "Ignored", "Patched" or "Unpatched"
- more detailed status enum
- description: free text describing reason for status
Examples of usage:
CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on Windows"
CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
(From OE-Core rev: 34f682a24b7075b12ec308154b937ad118d69fe5)
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Include support for ACLs for native builds by default.
(From OE-Core rev: eeb3f8e893e351520f3b8e642027e0dd6ca7c08b)
Signed-off-by: Piotr Łobacz <p.lobacz@welotec.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The Xdmx server was removed from the xorg-server sources in xorg-server
21 (released Oct. 2021), so this is only useful for communicating with
Xdmx from the 1.20 and older releases.
Also remove the DEPENDS on libdmx in xdpyinfo for the same reason.
(From OE-Core rev: 09a1a0473a5ab0fb984121443f5be8f0188e8883)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 6.4 kernel causes parselog failures when Xorg starts:
(II) FBDEV(0): checking modes against framebuffer device...
(II) FBDEV(0): mode "640x480" test failed
(II) FBDEV(0): mode "640x480" test failed
(II) FBDEV(0): mode "640x480" test failed
(II) FBDEV(0): mode "640x480" test failed
(II) FBDEV(0): mode "640x480" not found
It appears to be specific to qemuarm without GL. Until this is resolved,
pin the qemuarm BSP to 6.1.
(From OE-Core rev: 28615ad284243db4465c843c456083c9d4b3a0c4)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enable branch protection (PAC/BTI) for all aarch64 builds. This was
previously enabled at a global level in the GCC build, but that breaks
the gcc test suite.
(From OE-Core rev: 8905639d1cdc5ce809cc5ecd9672f5e86bf8a579)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kernel version 6.4 is the reference kernel for the fall
release.
This brings libc-headers up to date with that tested
reference
For musl, we drop one patch that has been merged upstream.
(From OE-Core rev: 8dce94b89396a99bb20a0a0ba9db0244d95db7e0)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've a slew of CVE_CHECK_IGNOREs in cve-extra-exclusions which are to
mark a CVE as not valid with the current default kernel. However, this
file is kernel agnostic so if someone decides to build a 6.0 kernel then
these ignores are no longer valid.
Move the ignores which are to simply reflect backports to
cve-exclusions_6.1.inc so that they're version-specific. As the kernel
is upgraded these exclusions should be made redundant and removed from
the file.
(From OE-Core rev: 157f7b62e271df5dfd8a3bc4d3821bf806fde51e)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The ptest problems reported in e21021dc00ec ("mdadm: drop from PTESTS_SLOW")
should now be fixed, so mdadm can be added back to PTESTS_SLOW (a qemux86-64
test run takes about ~12 minutes to execute with kvm).
root@qemux86-64:~# ptest-runner mdadm
START: ptest-runner
2023-06-30T08:25
BEGIN: /usr/lib/mdadm/ptest
PASS: /usr/lib/mdadm/ptest/tests/00linear
PASS: /usr/lib/mdadm/ptest/tests/00multipath
...
PASS: /usr/lib/mdadm/ptest/tests/19repair-does-not-destroy
PASS: /usr/lib/mdadm/ptest/tests/20raid5journal
PASS: /usr/lib/mdadm/ptest/tests/21raid5cache
DURATION: 723
END: /usr/lib/mdadm/ptest
2023-06-30T09:16
STOP: ptest-runner
TOTAL: 1 FAIL: 0
For the testcases to run correctly, there must be enough rootfs space to create
13 loop devices. Similar to strace and lttng-tools, add a new
IMAGE_ROOTFS_EXTRA_SPACE entry for mdadm-ptest.
(From OE-Core rev: dfefff63c547adb1add0c8e3a308b2d0bd6cfc8c)
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
