Move helper functions out of class scope so they can be used in other tests
(From OE-Core rev: 439a5a575b8ca27910431c71f01bf310122ff7ab)
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This class provides an image feature that mounts /etc as an overlayfs
file system. This is an extension for existing overlayfs class, which
doesn't support /etc
(From OE-Core rev: 610ea808c8b5edb2826bda1f1c42a811bd4ba758)
Signed-off-by: Alfred Schapansky <alfred.schapansky@avantys.de>
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A template init script for overlayfs-etc class
(From OE-Core rev: c0173002f3f2118f72307b7e60515287a1b56bda)
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds a PACKAGECONFIG option to use libsoup2 instead of libsoup3.
Including libsoup2 and libsoup3 in the same process can cause strange
runtime failures, and the latest release of each major version will
cause the process to exit if both are detected on startup.
The default is changed from libsoup3 back to libsoup2 to follow
webkitgtk.
(From OE-Core rev: 430ae4f95a2eb36311338c5c8bdba7331958556a)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds a PACKAGECONFIG option to use libsoup2 instead of libsoup3.
Including libsoup2 and libsoup3 in the same process can cause strange
runtime failures, and the latest release of each major version will
cause the process to exit if both are detected on startup.
The default is changed from libsoup3 back to libsoup2. Most GNOME
packages are still using libsoup2, and a large number of these pull in
webkitgtk either directly or indirectly. If webkitgtk uses libsoup3,
this causes all of these packages to fail at startup. It appears that
most GNOME packages will have to switch to libsoup3 when they transition
to GTK4.
(From OE-Core rev: deedca6bee5c90e35a7814b04bc5de03de9f9b1d)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PACKAGE_SNAP_LIB_SYMLINKS renames libraries based on their SONAME so
that they can be found directly rather than going via symlinks that
would be created by ldconfig. For example, without
PACKAGE_SNAP_LIB_SYMLINKS in ${libdir} we have:
libharfbuzz.so.0 -> libharfbuzz.so.0.20600.4
libharfbuzz.so.0.20600.4
but with PACKAGE_SNAP_LIB_SYMLINKS="1" we have just:
libharfbuzz.so.0
Unfortunately, this renaming is done based on the SONAME which breaks
packages like mesa which install a single library with multiple hard
links:
-rwxr-xr-x root/root 13593488 2021-12-07 12:26 ./usr/lib/dri/i915_dri.so
-rwxr-xr-x root/root 13137328 2021-12-07 12:26 ./usr/lib/dri/i965_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/iris_dri.so link to ./usr/lib/dri/i915_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/kms_swrast_dri.so link to ./usr/lib/dri/i915_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/nouveau_vieux_dri.so link to ./usr/lib/dri/i965_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/r200_dri.so link to ./usr/lib/dri/i965_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/radeon_dri.so link to ./usr/lib/dri/i965_dri.so
hrwxr-xr-x root/root 0 2021-12-07 12:26 ./usr/lib/dri/swrast_dri.so link to ./usr/lib/dri/i915_dri.so
The SONAME for i915_dri.so (and therefore all the other names that link
to the same file) is libgallium_dri.so. This means that
PACKAGE_SNAP_LIB_SYMLINKS causes do_package to successfully rename the
first name found to libgallium_dri.so. A similar thing happens to
i965_dri.so with its SONAME of libmesa_dri_drivers.so. The order is not
deterministic, so this means that although every build will be missing
one name, it's not always the same one.
-rwxr-xr-x root/root 13593488 2021-11-30 15:17 ./usr/lib/dri/i915_dri.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/kms_swrast_dri.so link to ./usr/lib/dri/i915_dri.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/libgallium_dri.so link to ./usr/lib/dri/i915_dri.so
-rwxr-xr-x root/root 13137328 2021-11-30 15:17 ./usr/lib/dri/libmesa_dri_drivers.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/nouveau_vieux_dri.so link to ./usr/lib/dri/libmesa_dri_drivers.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/r200_dri.so link to ./usr/lib/dri/libmesa_dri_drivers.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/radeon_dri.so link to ./usr/lib/dri/libmesa_dri_drivers.so
hrwxr-xr-x root/root 0 2021-11-30 15:17 ./usr/lib/dri/swrast_dri.so link to ./usr/lib/dri/i915_dri.so
This renaming means that the library cannot be found at runtime.
The simplest way to avoid this renaming is to only snap libraries that
would be processed by ldconfig.
(From OE-Core rev: 8571182ece1602ce8e030c98aef17cdc5718a037)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Phil Blundell <pb@pbcl.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This upgrade include a bug fix:
Refer:
https://gitlab.kitware.com/cmake/cmake/-/issues/22963643fc46bdc
(From OE-Core rev: 63bf94e26443b3790648c393f36203e9954b85de)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After the commit(8157ecc Separate public and private enums) introduced,
there comes a race as below:
| In file included from ../git/src/hdy-settings.c:11:
| ../git/src/hdy-settings-private.h:16:10: fatal error: hdy-enums-private.h: No such file or directory
| 16 | #include "hdy-enums-private.h"
So also add private headers like private sources did now to libhandy_sources
to fix the issue.
(From OE-Core rev: de57b4624e3d2d66268c33c4bf86dcb25abcab32)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport a patch to check whether files exist.
Before the patch:
# ./run-xtests.sh . tst-pam_access1
mv: cannot stat '/etc/security/opasswd': No such file or directory
PASS: tst-pam_access1
mv: cannot stat '/etc/security/opasswd-pam-xtests': No such file or directory
==================
1 tests passed
0 tests not run
==================
After the patch:
# ./run-xtests.sh . tst-pam_access1
PASS: tst-pam_access1
==================
1 tests passed
0 tests not run
==================
(From OE-Core rev: 4903fdbace057df2e39c10aaef3440f89748eed2)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kernel has dropped this as of 5.16 and we don't want to carry such patches
without active maintainers for such targets.
It isn't clear who would even have such hardware and it isn't something we can
support. It would be best maintained as a separate layer by those who can test
it if needed.
(From OE-Core rev: 5cd5075412639c0be9506cf1101737b12894fc5f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the changes to binutils, perf's direct calls to ld break for mips n64.
We already have tweaks for n32 so match those with the ones for n64.
(From OE-Core rev: 33828620872b80e1c745612e025215666ba755c8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similarly to the recent gcc change, we make gcc default to the 64 bit target
through configuration now so we don't need to patch this.
(From OE-Core rev: 259bcfdac3ad87d269dd18617c784fe14c50b0ad)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds useful detail from the orginal commit.
(From OE-Core rev: 3dea562e9d615384cc5e786eff46ac1f8f41e18e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As mentioned in a followup to the patch upstream:
https://sourceware.org/legacy-ml/binutils/2016-08/msg00215.html
"With 2.16.1, --enable-gold is just ignored when building on mips"
so we don't need the patch since 2.16.1.
(From OE-Core rev: 3c230c70f28aef21ae986679d783551832b4e3fa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes an error in libva-initial build if 'systemd' is in DISTRO_FEATURES
and libdrm is set to be built with udev support.
| Run-time dependency xfixes found: NO (tried pkgconfig and cmake)
| Run-time dependency wayland-client found: YES 1.19.0
| Program wayland-scanner /usr/bin/wayland-scanner found: NO
|
| ../libva-2.13.0/meson.build:107:4: ERROR: Program 'wayland-scanner /usr/bin/wayland-scanner' not found
|
| A full log can be found at /home/flk/build/poky/build-rock/tmp/work/cortexa72-cortexa53-crypto-poky-linux/libva-initial/2.13.0-r0/build/meson-logs/meson-log.txt
| ERROR: meson failed
| WARNING: exit code 1 from a shell command.
(From OE-Core rev: cb9923f4e62339192c0d8e3d2852f1e71c1963b9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some BSPs, especially those of meta-freescale and meta-ti allow to build U-Boot
binaries using different configuration for a given target, for example:
- UBOOT_CONFIG ??= "tfa-secure-boot tfa"
- UBOOT_CONFIG ??= "nand sdcard spi nor"
When this is the case the public key wasn't concatenated to all U-Boot binaries
built.
(From OE-Core rev: dfd71ae3d102f3010c6117d774e9739a322930f6)
Signed-off-by: Thomas Perrot <thomas.perrot@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In 526bdd88ccd758204452579333ba188e29270bde the imageType loop in
kernel_do_deploy was changed to use KERNEL_IMAGETYPE_FOR_MAKE rather
than KERNEL_IMAGETYPES. This broke the special handling for fitImage
immediately below because KERNEL_IMAGETYPE_FOR_MAKE never contains
fitImage.
It has always been my understanding that KERNEL_IMAGETYPE_FOR_MAKE
controlled what was passed to make, but KERNEL_IMAGETYPE controlled what
was installed/deployed. When the two are different then it's the
responsibility of whoever set KERNEL_IMAGETYPE_FOR_MAKE to ensure that
whatever comes out of the kernel build system has been transformed in to
the requested form by the time of installation. This is what happens for
kernel.bbclass's own support for vmlinux.gz.
I think this means that for KERNEL_IMAGETYPE vmlinux.gz, kernel.bbclass
is responsible for generating vmlinux.gz.initramfs[1] so that
kernel_do_deploy can deploy it. This means that the change in
526bdd88ccd758204452579333ba188e29270bde can be reverted, fixing
KERNEL_IMAGETYPE = "fitImage".
In addition, it ought to be possible for recipes and other classes that
use kernel.bbclass to hook into this mechanism by setting
KERNEL_IMAGETYPE_FOR_MAKE and performing their own transformations.
do_bundle_initramfs calls kernel_do_compile and we don't want it to
transform vmlinux to vmlinux.gz at that point, since it will fight
against the careful renaming and preserving that do_bundle_initramfs
does. Let's separate the transformation out of kernel_do_compile to a
new do_transform_kernel task that can be run at the right time. This
means that it's also logical to perform the equivalent translation for
the kernel with the initramfs in a separate
do_transform_bundled_initramfs task too.
This leaves two clear customisation points for recipes and other classes
to hook into the process and perform their transformations:
do_transform_kernel and do_transform_bundled_initramfs.
(I care about this because our recipes that use kernel.bbclass also set
KERNEL_IMAGETYPE_FOR_MAKE and transform vmlinux into a form suitable for
our bootloader after do_compile and do_bundle_initramfs into the format
matching KERNEL_IMAGETYPE. I'm unable to successfully bundle an
initramfs after 526bdd88ccd758204452579333ba188e29270bde, but I didn't
want to just revert that change to reintroduce the bug that it was
fixing.)
I can't say that I'm entirely happy with this change, but I'm unsure
what to do to improve it. I find the way that both the bare kernel and
the one with the initramfs both get deployed to be confusing, and a
waste of build time. I would like to not actually generate a publishable
kernel image at all during do_compile when an initramfs is in use, but I
suspect that this would affect valid use cases that I'm not aware of.
(From OE-Core rev: 10a4a132e87e835726bf5da81a60f6f509b90765)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
[1] It could be argued that this should be vmlinux.initramfs.gz, but
that would require another special case in kernel_do_deploy and the
filename is only visible within this class and the recipes that use it
anyway.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We should not redirect stderr to stdout if we need to get separated
stdout and stderr contents from Popen.communicate() later.
(Bitbake rev: 1ecc1d9424877df89fcda2f23c306998998a65ff)
Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the console output for signature dumps e.g. with bitbake-dumpsig
isn't deterministic. Add some sorting to improve that.
(Bitbake rev: a663440b1623f97c9c169df5566e429fbc932a53)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are no consumers in oe-core; years ago it used to be gstreamer.
(From OE-Core rev: 4bacb37e9fd55d8bf8ead8d6879e95b31e1dfb55)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License-Update: GPL2 license for cli tool moved to a separate file
(From OE-Core rev: 706ed171c0b761a01f01baac92a2f2ad9ba8240b)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
