Dropping the 6.6 reference kernel as the upcoming LTS will use
6.12 as the main reference with 6.13+ as the -dev kernel.
6.6 will not be supported upstream for the duration of the
LTS release, so droping it now to avoid uncessary mid-release
churn.
(From OE-Core rev: 6c445a6995f810e48a25cc0c13f37271836cba00)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Both OE-Core and poky git repos have a .b4-config, both at the same
location and both different.
Therefore, changes made to .b4-config for OE-Core need to be sent to the
OE-Core mailing list and changes made to .b4-config for poky sent to the
poky mailing list.
Changes made to OE-Core's .b4-config can only be made from a vanilla
OE-Core git repo, not from poky git repo. With the current content of
OE-Core's .b4-config, b4-wrapper-poky.py script is NOT called to figure
out where to send patches, b4 gets it from the hardcoded value in
send-series-to.
Thus, we can say that if b4-wrapper-poky.py detects changes for
.b4-config, those changes are for poky since this script wouldn't be run
by b4 outside of poky git repo.
(From OE-Core rev: 1006712027812326fdeade2ab539b42bdf5b10e6)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We encountered the following error when building multipath-tools on
qemuppc64 platform:
| In file included from /build/tmp/work/ppc64p9le-wrs-linux/multipath-tools/0.10.0/recipe-sysroot/usr/include/urcu/uatomic/ppc.h:228,
| from /build/tmp/work/ppc64p9le-wrs-linux/multipath-tools/0.10.0/recipe-sysroot/usr/include/urcu/uatomic.h:73,
| from lock.h:5,
| from lock.c:1:
| /build/tmp/work/ppc64p9le-wrs-linux/multipath-tools/0.10.0/recipe-sysroot/usr/include/urcu/uatomic/generic.h: In function '_uatomic_and':
| /build/tmp/work/ppc64p9le-wrs-linux/multipath-tools/0.10.0/recipe-sysroot/usr/include/urcu/uatomic/generic.h:422:24: error: implicit declaration of function 'abort' [-Wimplicit-function-declaration]
| 422 | oldt = uatomic_read((uint32_t *) addr);
| | ^~~~~~~~~~~~
| /build/tmp/work/ppc64p9le-wrs-linux/multipath-tools/0.10.0/recipe-sysroot/usr/include/urcu/uatomic/generic.h:1:1: note: include '<stdlib.h>' or provide a declaration of 'abort'
| +++ |+#include <stdlib.h>
| 1 | // SPDX-FileCopyrightText: 1991-1994 by Xerox Corporation. All rights reserved.
| make[1]: *** [../Makefile.inc:155: lock.o] Error 1
| make[1]: Leaving directory '/build/tmp/work/ppc64p9le-wrs-linux/multipath-tools/0.10.0/git/libmultipath'
Add stdlib.h header file for abort() in uatomic/generic.h.
(From OE-Core rev: 6dd6da04485152971346ee3fc09402c72aacbf22)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License-Update: Update copyright year, attribution bounds
The project has changed to using a pyproject.toml with hatchling as the
build backend, so change the recipe to match.
Changelog (https://github.com/justinmayer/typogrify/releases/tag/2.1.0):
- Add ability to select which filters are applied (#1 by davidlesieur & barrysteyn)
- jinja_filters: Update import for Jinja 3.1 (by jyelloz)
- Ensure all available tests are run (by mcepl)
- Package via pyproject instead of Setuptools (by justinmayer)
- Improve testing, linting, and CI tooling
- Drop support for Python < 3.9
(From OE-Core rev: 037f04b08c76caee6bda176e18c1e0b824f3bcf6)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Solves CVE-2025-0167, CVE-2025-0665 and CVE-2025-0725.
Initialize WATT_ROOT variable to avoid looking in host dirs
when autotools are checking available features.
License-Update: copyright year refreshed
(From OE-Core rev: dd642c786e9c9eee06a90562e69e70cb37e704df)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow the '+' symbol as a valid character in filenames listed in the
IMAGE_EFI_BOOT_FILES variable.
The '+' symbol might be used to support boot counting for boot entries,
as described in the UAPI Boot Loader Specification [1]:
The boot counting data is stored in the name of the boot loader entry.
A boot loader entry file name may contain a plus (+) followed by a
number. This may optionally be followed by a minus (-)
followed by a second number. The dot (.) and file name suffix
(conf or efi) must immediately follow.
Boot counting is enabled for entries which match this pattern.
Example:
IMAGE_EFI_BOOT_FILES:append = " entry.conf;loader/entries/entry+3.conf"
[1] https://uapi-group.org/specifications/specs/boot_loader_specification/#boot-counting
(From OE-Core rev: 3f25822281eb9423ff86105eaebb0bed48663648)
Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ptest compile and install tasks do not have parallel build settings for
cmake. On powerful build machines this can cause overload situations
and oomkills.
Observed when building qtgrpc with ptest generally enabled in distro.
Having this in ptest class is suboptimal, but creating ptest-cmake class
just for these two variables is probably overkill.
(From OE-Core rev: 3c311fbf0c2090268e9b83123d762b05b61b4074)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The dbus.socket user unit file calls systemctl, and the meson.build uses
find_program() to find the path, falling back to a hardcoded value if it
cannot be found.
On the initial build the sysroot doesn't contain systemctl (as it is not
in the target systemd sysroot), however after the do_package_write_*
tasks have completed there is a systemd-systemctl-native recipe in the
sysroot which will be found and result in host paths being in the target
packages, specifically in /usr/lib/systemd/user/dbus.socket:
ExecStartPost=-/work/ross/build/tmp/work/core2-64-poky-linux/dbus/1.16.0/recipe-sysroot-native/usr/bin/systemctl
This can be replicated by forcing a rebuild after a forced packaging:
$ bitbake dbus -C do_package_write_ipk
$ bitbake dbus -C configure
ERROR: dbus-1.16.0-r0 do_package_qa: QA Issue: File
/usr/lib/systemd/user/dbus.socket in package dbus-common contains
reference to TMPDIR [buildpaths]
We could do the unit mask manually instead of using systemctl (as it's
just a symlink) but the hardcoded path is still wrong, so write a small
Meson cross file to specify where the binary is.
(From OE-Core rev: 2ebfe3d8df809f6cf057ac7b56cdbc265f05b37a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This class calls d.getVar('DEPLOY_DIR_IMAGE') twice within the same
method, but DEPLOY_DIR_IMAGE variable won't change during the run of
this class, so only retrieve it once.
(From OE-Core rev: 6866da9f3a273ed7217e9edfca299fc2e68b2f75)
Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
systemd update from 256 to 257 broke kernel secureboot signatures
inside signed UKI files with u-boot based UEFI firmware, e.g.
meta-arm and qemuarm64-secureboot machine config and secureboot:
$ cd meta-arm
$ kas build ci/poky.yml:ci/qemuarm64-secureboot.yml:ci/uefi-secureboot.yml:ci/testimage.yml
systemd-boot itself is secureboot signed and verified by firmware.
Same for the UKI file which combines kernel, initramfs etc.
Then kernel from UKI is additionally executed using UEFI firmware calls
which check signatures so the kernel binary inside signed UKI
needs to be signed with same keys too. PE file padding added
to systemd ukify in 257 release broke kernel signature validation
for u-boot and sbsign/sbverify tools. EDK2 based firmware like
OVMF may not be affected because systemd-boot is able to disable
signature checking after a signed UKI has been loaded. This feature
is not supported by u-boot.
Upstream systemd bug report:
https://github.com/systemd/systemd/issues/35851
Backport of:
38801c9129
Cc: Jon Mason <jdmason@kudzu.us>
Cc: meta-arm@lists.yoctoproject.org
(From OE-Core rev: 979d8b16a5238ea368b2ee39d436b6e13d94b076)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ukify tool can show important warnings and even errors
if it fails so capture the logs.
(From OE-Core rev: 6ac326a4f9d19fa154c9ce172a264f55ebe5b1ef)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The tasks were deleted and do_patch() was run after do_install()
which means that patches applied in SRC_URI were not in the
ukify.py binary installed. Moving do_install() to after do_patch()
fixes this.
(From OE-Core rev: 0218a7a7dbf12ef817608881a3a17d9670c0778a)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix a problem with `devtool modify` as suggested by Marcus Flyckt on
the mailing list:
```
I encountered an issue with `do_config` when using `devtool modify`
on `u-boot-imx`.
```
[...]
| cp: cannot stat '[...]/u-boot-imx/2024.04/build/imx8mp_wl400s_defconfig/.config': No such file or directory
| WARNING: exit code 1 from a shell command.
ERROR: Task ([...]/sources/poky/../meta-freescale/recipes-bsp/u-boot/u-boot-imx_2024.04.bb:do_configure) failed with exit code '1'
NOTE: Tasks Summary: Attempted 963 tasks of which 962 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
[...]/sources/poky/../meta-freescale/recipes-bsp/u-boot/u-boot-imx_2024.04.bb:do_configure
Summary: There was 1 ERROR message, returning a non-zero exit code
```
The issue seems to originate from the following lines in
`workspace/appends/u-boot-imx_2024.04.bbappend`:
```
do_configure:append() {
if [ ${@oe.types.boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG"))} = True ]; then
cp ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.baseline
ln -sfT ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.new
fi
}
```
For some reason `KCONFIG_CONFIG_ROOTDIR` does not point to the
correct directory. It gets its value in `uboot-config.bbclass`:
```
if len(ubootconfig) == 1:
d.setVar('KCONFIG_CONFIG_ROOTDIR', os.path.join(d.getVar("B"), d.getVar("UBOOT_MACHINE").strip()))
```
So the main issue is that B gets expanded in this expression, and
then later B gets changed by `externalsrc.bbclass`.
`d.getVar("B", False)` does not solve the issue, however the
proposed change does.
```
- https://lists.yoctoproject.org/g/yocto/topic/109254298#msg64152]
Fixes [YOCTO #15603]
Suggested-by: Marcus Flyckt <marcus.flyckt@gmail.com>
(From OE-Core rev: 57b21065a25100c31515b32fd7c77bde3355d684)
Signed-off-by: Tom Hochstein <tom.hochstein@oss.nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta-oe has switched from p7zip to 7zip.
p7zip recipe does not exist anymore and p7zip is provided and rprovided
by 7zip recipe.
Use real provider instead of replaced one.
(From OE-Core rev: 5aa516bfa295d5be919459dfe45f452cdec45e81)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The cap and acl configs were missing dependency specifications. They
could get satisfied transitively if archive was also used, but alone
get missed.
(From OE-Core rev: 7e89209fd52b1b1652c65013eb3bcc40cb24cda5)
Signed-off-by: Daniel McGregor <daniel.mcgregor@vecima.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As this recipe builds the tagged releases we can put the PV in the
filename.
(From OE-Core rev: 2c7c9eb6ff996639a632059102de4d1168958eb6)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport a patch from upstream to fix register tramping on aarch64.
(From OE-Core rev: 9005321e37030d916f4f26e7201e2f86c85ebdbd)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These were replaced with python3 in 2.5.2 (commit d1683f).
(From OE-Core rev: 85ae456a12bccabc62cb0906b92d6705f88c932f)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Gold hasn't seen development in some time and is being dropped from binutils
releases. Drop the small number of special cases for it we were carrying.
This patch also turns off gold in the binutils recipe.
(From OE-Core rev: a4addb9ab63011e7c604fc5daff95559e7d214e7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upgrade to latest 1.22.x release [1]:
$ git --no-pager log --oneline go1.22.11..go1.22.12
5817e65094 (tag: go1.22.12) [release-branch.go1.22] go1.22.12
0cc45e7ca6 [release-branch.go1.22] crypto/internal/fips140/nistec: make p256NegCond constant time on ppc64le
c3c6a50095 [release-branch.go1.22] cmd/go/internal/modfetch: do not trust server to send all tags in shallow fetch
e0a01acd04 [release-branch.go1.22] cmd/compile: fix write barrier coalescing
Fixes CVE-2025-22866
[1] https://github.com/golang/go/compare/go1.22.11...go1.22.12
(From OE-Core rev: 423ad5a67768738dac454b1e2aa27746f74511c5)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we remove gold from binutils, go-runtime fails to build. There was a
workaround in go to use gold as the bfd linker had a bug. The issue was
fixed so backport dropping the workaround fmr upstream.
(From OE-Core rev: 4636b7206b2e4247835d60956e62f5a2efea9e81)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We triggered a test of an older revision to narrow down when performance
changed. The issue is that git's timestamps are granular to 1s. We'll
usually merge a set of commits at the same time so they will all have
the same timestamp for a block of them. This means that even if we use
the commit date, all the points can't be distinguished on the graph.
The author date doesn't work either as the commits are not merged in
author date order.
To solve this this patch adds the commit_count chart as a separate tab
next to the start_time chart
(From OE-Core rev: b263edd33f6c895238d81ef148c0445fcd0aa268)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As well as commit counts, it is helpful to know when metadata dates from. Store
the unix timestamp for commits in a commit_time field alongside the commit count.
This is useful for performance graph analysis and saves having to recompute the
data.
(From OE-Core rev: 56d1bc3f8f45d2f9c8ca0319c429cec562a16384)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The commit 4ccc3bc8266c ("classes/recipes: Switch virtual/XXX-gcc to
virtual/cross-cc (and c++/binutils)") in OE-Core changes the
virtual/XXX-gcc to virtual/cross-cc (and c++/binutils) syntax. Add it to
the migration manual.
(From yocto-docs rev: 6eda443c7fcfeecebd6b44b96a1587c4bb093a34)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After commit 0fa0d8d764bb ("cooker/cache: Drop mc 'default' string
value") in Bitbake, the default value of BB_CURRENT_MC was changed from
"default" to an empty string. Document it.
(From yocto-docs rev: efbd8fa30a5cc42d5243aa87e00e2d92cb265adb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch describes how to use overrides for grub-efi-cfg because that
is otherwise only clear after reading the .bbclass file. It also adds
a description for GRUB_TITLE.
(From yocto-docs rev: b9ec7d124c9cbaf6c05415277fa028a39ce9e02f)
Signed-off-by: "Simon A. Eugster" <simon.eu@gmail.com>
Reviewed-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There were leftover references to the extensible SDK after moving the
devtool documentation from the Extensible SDK document to its own
devtool document.
This patch follows the bulk move to make it clear what was modified in
the document.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
(From yocto-docs rev: 032d2f3297ff4b5ee4e000b3dd0748a58b5f32e0)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #13417]
devtool is not directly tied to the Extensible SDK anymore, and
instructions in there can be split and added to the development manual.
This patch is a simple bulk move, except for the following:
- Intro added to the devtool.rst document (mostly copy-pasted from the
devtool quick reference in the ref-manual).
- Figures renamed to remove "sdk-" from filenames.
- References to sdk-manual/extensible replaced by dev-manual/devtool.
Reported-By: Paul Eggleton <bluelightning@bluelightning.org>
(From yocto-docs rev: 044d3185b858fce1febcfe3a6834b883f9a598fa)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 0d3901b768.
We've still having CDN issues so go back to the double attempt to
see if this improves things.
(From OE-Core rev: 136f0edb75d9601a0ae56e025419d3cddfb90219)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
b4[1] is a very nice tool for mail-based contribution. A config[2] file
exists to set up a few defaults. We can use it to provide the Cc and To
recipient list for the series.
This uses the b4-wrapper-poky.py script for checking that each patch in
the series is only for one project. Indeed, poky is actually a
"collection" of multiple repositories, namely BitBake, OpenEmbedded-Core
and the Yocto Docs. One patch should therefore not make changes in
multiple of those projects otherwise it cannot be merged.
Additionally, a check is added to make sure that a series only touches
files from one project to avoid having to figure out which patch is to
be merged by which maintainer in which project repo.
Moreover, it is not uncommon to have people develop patches for those
projects from within poky. This wrapper figures out which mailing lists
to send patches to based on the files that are modified in the series.
Considering that patches to the bitbake/doc/ directory need to be sent
to both the bitbake and yocto-docs mailing list (To recipient for the
former, Cc recipient for the latter) this wrapper handles that.
A limitation of the script (lsdiff actually) is that it doesn't know how
to handle empty files, but those should be of rather rare occurrences.
Note that this script requires hardcoding of paths that are handled by
different projects to map files to projects. Anything not mapped is
assumed part of OE-Core.
[1] https://pypi.org/project/b4/
[2] https://b4.docs.kernel.org/en/latest/config.html
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
poky is a combo-layer containing BitBake, OpenEmbedded-Core and Yocto
Documentation source code into one big repo. It is not uncommon to have
people develop patches for either of those projects from a poky git
repo.
However, it is unlikely those patches are to be sent to the poky mailing
list as very few files contained in the poky git repo actually are
poky-specific. So we need a way to identify to which mailing list a
patch is destined to be sent.
Additionally, because the source code in openembedded-core is
merged/imported at the root of the git repo of poky, its .b4-config
introduced in the previous commit will be used if not overridden (which
will be done in a separate commit specific to the poky git repo). We
need to provide a different .b4-config in poky.
Therefore, this wrapper is used to identify automatically which mailing
list a patch series needs to be sent to (via b4 prep --auto-to-cc) and
does some additional checks (via b4 prep --check) such as making sure a
patch doesn't modify two different projects at the same time or that
multiple projects are modified by different patches in the same patch
series.
This wrapper script is meant to be used by poky's .b4-config. Ideally
the b4 prep --check part could be offloaded to `patchtest` once it
supports running on source different from OE-Core.
Note that b4 makes sure that an address doesn't appear twice in the
recipient list. There's also no priority in the type of recipient list,
so if the address appears first in Cc and then in To, only the Cc will
be added. The opposite is true as well.
(From OE-Core rev: a1d629a0823cf724bda607ef8d88ee4f722c3a08)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
b4[1] is a very nice tool for mail-based contribution. A config[2] file
exists to set up a few defaults. We can use it to set the To recipients
to always add, in our case the mailing list.
This also adds a wrapper script that is called by b4 to figure out which
addresses to put as Cc recipients. Considering that patches to the doc/
directory also need to be sent to the yocto-docs mailing list, this
wrapper handles that. A limitation of the script (lsdiff actually) is
that it doesn't know how to handle empty files, but those should be
of rather rare occurrences.
Because we currently do not have anything to check for patch validity,
remove requirement for b4 prep --check to be run before sending a patch
series, via disable-needs-checking in prep-pre-flight-checks.
[1] https://pypi.org/project/b4/
[2] https://b4.docs.kernel.org/en/latest/config.html
(Bitbake rev: 8843860010c97cc10ff69205d209634639b6c5cd)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When testing a Yocto SDK installer on Alpine 3.21, we recently ended up with a
broken SDK. One of the commands the relocation script calls in a piped
multi-command chain failed (see [0]), but the installer did not realize that -
since it doesn't use 'set -o pipefail'. Thus, the error was never reported to
the user and the installer claimed to have set up the SDK correctly - which
wasn't the case.
Given that the SDK installer is a POSIX-compliant shell script and that the
'pipefail' option used to be missing from the standard, it's not surprising that
it isn't used. Thankfully however, in June of 2024, a new version of POSIX
(POSIX.1-2024) was released - and that one finally includes the 'pipefail'
option (see [1]). A number of shells already support it, so let's enable it if
available to make the SDK installer more robust.
The change has been tested locally using SDK installers for internal projects,
based on both Kirkstone and Scarthgap.
[0]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/16797
[1]: https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/utilities/V3_chap02.html#set
(From OE-Core rev: 1cb4b41c7faf77fcc347b1276d86d4288968c926)
Signed-off-by: Moritz Haase <Moritz.Haase@bmw.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changelog:
- Update the syscall table for Linux v6.13
- Add support for new arches: SuperH little and big endian, LoongArch, and
32-bit Motorola 68000
- Add multiplexed syscall support for more arches: MIPS, SuperH, and PPC
- Consolidate and simplify handling of multiplexed syscalls
- Add support for the SECCOMP_FILTER_FLAG_WAIT_KILLABLE_RECV flag
- Add support for transactions with the seccomp_transaction_start(),
seccomp_transaction_commit(), and seccomp_transaction_reject() APIs
- Add a seccomp_precompute() API to generate the seccomp BPF filter prior to
seccomp_load() or seccomp_export_bpf_mem()
- Add support for binary tree filters without syscalls
- Add support for the kernel’s implementation change of
SECCOMP_IOCTL_NOTIF_ID_VALID
- Add Python binding support for retrieving the notification file descriptor
- Improved tooling to help track syscall table updates in the Linux kernel
- Handle EINVAL error from the kernel when the WAIT_KILLABLE_RECV flag is
erroneously provided to the kernel
- Fix a seccomp userspace notification issue where the file descriptor was
being requested more than once
- Fix a bug where the internal filter state could be corrupted when a filter
rule addition fails
- Fix potential memory leak in the internal management of filter snapshots
- Utilize Cython rather than distutils in the Python bindings, due to
distutils’ deprecation
- Many test and CI improvements and fixes
- Many documentation improvements and updates
(From OE-Core rev: 549a477660bd6ccda842b4ed34814b53470d08d8)
Signed-off-by: Simone Weiß <simone.p.weiss@posteo.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The original reproducibility fix was problematic for a couple reasons:
- disabling both lto and parallel builds had an unfortunate effect of nearly
doubling rust-native and rust build times (which are slow to begin with).
Disabling lto hurts runtime performance too.
- both of these things were done for the *entire build*, while the only
problematic item is the librustdoc crate.
- lto=off option in config.toml has an effect only on building rustc
(the compiler itself), and doesn't help with rustdoc reproducibility.
Actual fix is the codegen-units setting, which indirectly disables
lto via giving llvm only one unit to work with at a time.
After some digging, here's a more targeted fix for the problem.
Why librustdoc is non-reproducible, but not anything else
remains a mystery, hidden deep in rust-llvm's lto optimization code.
(From OE-Core rev: a1977407a88a2004c3a6d2dba1d5bfe1aa1664b2)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
