Changelog:
==========
* gpg,gpgv: New option --assert-pubkey-algo.
* gpg: Emit status lines for errors in the compression layer.
* gpg: Fix invocation with --trusted-keys and --no-options.
* gpgsm: Allow for a longer salt in PKCS#12 files.
* gpgtar: Make --status-fd=2 work on Windows.
* scd: Support for the ACR-122U NFC reader.
* scd: Suport D-TRUST ECC cards.
* scd: Allow auto detaching of kernel drivers; can be disabled with
the new compatibility-flag ccid-no-auto-detach.
* scd: Allow setting a PIN length of 6 also with a reset code for
openpgp cards.
* agent: Allow GET_PASSPHRASE in restricted mode.
* dirmngr: Trust system's root CAs for checking CRL issuers.
* dirmngr: Fix regression in 2.4.4 in fetching keys via hkps.
* gpg-wks-client: Make option --mirror work properly w/o specifying
domains.
* g13,gpg-wks-client: Allow command style options as in "g13 mount
foo".
* Allow tilde expansion for the foo-program options.
* Make the getswdb.sh tool usable outside the GnuPG tree.
(From OE-Core rev: a596d0e3802486dce9eeee2a9cbfdc6372a182d5)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Below commits on binutils-2.42 stable branch are updated.
758a2290dbd PR32387 ppc64 TLS optimization bug with -fno-plt code
ed489bf1574 s390: Add arch15 Concurrent-Functions Facility insns
64e8e16a906 s390: Add arch15 instruction names
Tested on qemux86_64.
There were no additional PASS or FAIL after the update
(From OE-Core rev: 6ce232df15834cae44f3eda0f786132086afb76e)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
[ YOCTO #14747 ]
Adding a initramfs is a common task, and the way oe-core offers to do so
is by using the initramfs-framework recipe and companion modules. There
was already documentation on adding an initramfs but the documentation
was lacking details on this framework. Add it before the multiconfig
section because it is a bit more important IMO.
Reported-by: Alejandro <alejandro@enedino.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
(From yocto-docs rev: e1aa69d00e20a5d3c948c430ed10eb01e7baa574)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
(cherry picked from commit caedbca4eced4cf5bc74aaae64e4ad2887c2fc65)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
We document how to add ptest support for a recipe by inheriting the
ptest class. We may as well tell the user to inherit a ptest class for a
common framework which does most of the job for you.
Suggested-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
(From yocto-docs rev: 96645900c93abb95419f81e1553d988f3f68dc6a)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
(cherry picked from commit 411b18e489a97ea4cde05613cdd4c86deb0cb8cb)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The devtool ide-sdk section is reformulated to be independent of the
eSDK installer. In fact, ide-sdk does not even support the execution
of an installer-based setup.
This reformulation is also a preparation for moving the devtool
documentation to a dedicated devtool section which is independent from
the eSDK documentation.
It should be clarified that devtool ide-sdk starts the SDK directly
from the bitbake environment. It is therefore an alternative to
bitbake -c populate_sdk_ext and installing an SDK installer.
A warning is added that explains some workarounds for some nasty
behavior of VSCode when running it in a bitbake environment.
(From yocto-docs rev: 87b37eabd1db05d9cb3f689cf43f1e6f4d649a97)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Reviewed-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
(cherry picked from commit 287817f33688d61f7a71c056bfa5c645edb4fc4e)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
How to reproduce:
- UBOOT_CONFIG must be used. With UBOOT_MACHINE it works fine.
A simple example based on oe-core is to modify the
beaglebone-yocto.conf file like this:
-UBOOT_MACHINE = "am335x_evm_defconfig"
+UBOOT_CONFIG = "foo"
+UBOOT_CONFIG[foo] = "am335x_evm_defconfig"
- A build configuration which inherits the kernel-fitimage.bbclass is
needed. For example:
MACHINE = "beaglebone-yocto"
KERNEL_IMAGETYPE = "Image"
KERNEL_IMAGETYPES += " fitImage "
KERNEL_CLASSES = " kernel-fitimage "
devtool modify linux-yocto
devtool build linux-yocto
...
| cp: cannot stat '.../linux-yocto-6.6.21+git/am335x_evm_defconfig/.config':
No such file or directory
| WARNING: .../linux-yocto/6.6.21+git/temp/run.do_configure.2081673:172 exit 1
from 'cp .../linux-yocto-6.6.21+git/am335x_evm_defconfig/.config
.../build/workspace/sources/linux-yocto/.config.baseline'
The reason for this problem is that the uboot-config.bbclass sets the
variable KCONFIG_CONFIG_ROOTDIR to a path that makes sense for u-boot,
but not for other recipes. However, the kernel-fitimage.bbclasse, for
example, inherits the uboot-config.bbclass, which brings the
u-boot-specific path into the kernel build context.
This change removes the uboot-specific KCONFIG_CONFIG_ROOTDIR path from
recipes other than u-boot itself.
(From OE-Core rev: 37835788d0772568f3551532eacbf810a4a6e47b)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from b23581a22619c52724c8e078f29e871e2ee74259)
Signed-off-by: Leonard Anderweit <l.anderweit@phytec.de>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The ide-sdk command bootstraps the SDK from the bitbake environment
before the IDE configuration is generated. In the case of the eSDK
installer, the bootstrapping is performed during the installation of
the eSDK installer. Running the ide-sdk plugin from an eSDK installer
based setup would require skipping the bootstrapping and probably taking
some other differences into account when generating the IDE
configurations.
This would be possible. But it will probably never be implemented, as
running devtool ide-sdk directly from the bitbake environment is much
more flexible.
Also, some of the recent improvements that have made it into the core
have the potential to make the eSDK installer obsolete at some point in
the future:
- bitbake-layers create-layers-setup replicates the layers
- bitbake-config-build replicates the build configuration
- The new sstate mirror features replicate the sstate
- bblock locks the sstate more flexible than the eSDK installer
- devtool ide-sdk bootstraps the SDK directly from the bitbake
environment. The same environment-setup... file is provided with
--mode=shared.
The devtool modify based workflow is supported since always by devtool
and also the default --mode of devtool ide-sdk.
These functions essentially cover what the eSDK installer does without
a need for the current implementation of the eSDK installer and the
populate_sdk_ext, which is hard to maintain and takes a lot of time to
build.
This means that instead of making the ide-sdk plugin compatible with the
eSDK installer, we should rather replace the current implementation of
the eSDK installer and populate_sdk_ext with an implementation that can
replicate a normal bitbake environment in a convenient way where the
ide-sdk plugin also just works without additional complexity.
(From OE-Core rev: f50306ea3e174b8db46b20b68a7ac4299a69f50d)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The debug_build_config function was never called. Compiling with debug
optimized compiler flags was not working. Even with the
--debug-build-config flag set, the build configuration from the recipe
was used.
The devtool ide-sdk --debug-build-config approach didn't work very well
anyway. The problem is that changing the bbappend file doesn't work
while bitbake uses the bbappend file. As a workaround, it would be
possible to parse the recipe, get DEBUG_BUILD and the path to the append
file, exit tinfoil, change the bbappend file, reopen tinfoil and do what
ide-sdk is supposed to do. Such an implementation would be complicated
and slow.
Therefore, the code that was originally supposed to implement this is
removed from ide-sdk and the new --debug-build function of devtool
modify is used instead. Additionally, a hint should be given on how to
manually add DEBUG_BUILD = '1' to bbappend.
This is compatible with the VSCode Bitbake plug-in, which does not
support this parameter anyway.
(From OE-Core rev: 23795962683c792347a17854fb0521734497d4a8)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Sort the keys of the generated CMakeUserPreset.json file to make it
easier to search and compare.
(From OE-Core rev: b12dbde1ea30dd0fc1dd9352de948b8377c347fa)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Add a new option --debug-builds to automatically add DEBUG_BUILD = “1”
to the bbappend file of this recipe. This is especially useful when
invoking devtool modify before invoking devtool ide-sdk to perform a
remote debugging session.
(From OE-Core rev: fa30d8dd71393e10aa678c6e938c23d486b336c6)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
In case both UBOOT_SIGN_ENABLE and UBOOT_ENV are enabled and
kernel-fitimage.bbclass is in use to generate signed kernel
fitImage, there is a circular dependency between uboot-sign
and kernel-fitimage bbclasses . The loop looks like this:
kernel-fitimage.bbclass:
- do_populate_sysroot depends on do_assemble_fitimage
- do_assemble_fitimage depends on virtual/bootloader:do_populate_sysroot
- virtual/bootloader:do_populate_sysroot depends on virtual/bootloader:do_install
=> The virtual/bootloader:do_install installs and the
virtual/bootloader:do_populate_sysroot places into
sysroot an U-Boot environment script embedded into
kernel fitImage during do_assemble_fitimage run .
uboot-sign.bbclass:
- DEPENDS on KERNEL_PN, which is really virtual/kernel. More accurately
- do_deploy depends on do_uboot_assemble_fitimage
- do_install depends on do_uboot_assemble_fitimage
- do_uboot_assemble_fitimage depends on virtual/kernel:do_populate_sysroot
=> do_install depends on virtual/kernel:do_populate_sysroot
=> virtual/bootloader:do_install depends on virtual/kernel:do_populate_sysroot
virtual/kernel:do_populate_sysroot depends on virtual/bootloader:do_install
Attempt to resolve the loop. Pull fitimage configuration options into separate
new configuration file image-fitimage.conf so these configuration options can
be shared by both uboot-sign.bbclass and kernel-fitimage.bbclass, and make use
of mkimage -f auto-conf / mkimage -f auto option to insert /signature node key-*
subnode into U-Boot control DT without depending on the layout of kernel fitImage
itself. This is perfectly valid to do, because the U-Boot /signature node key-*
subnodes 'required' property can contain either of two values, 'conf' or 'image'
to authenticate either selected configuration or all of images when booting the
fitImage.
For details of the U-Boot fitImage signing process, see:
https://docs.u-boot.org/en/latest/usage/fit/signature.html
For details of mkimage -f auto-conf and -f auto, see:
https://manpages.debian.org/experimental/u-boot-tools/mkimage.1.en.html#EXAMPLES
(From OE-Core rev: 259bfa86f384206f0d0a96a5b84887186c5f689e)
Fixes: 5e12dc911d0c ("u-boot: Rework signing to remove interdependencies")
Reviewed-by: Adrian Freihofer <adrian.freihofer@siemens.com>
(From OE-Core rev: d7bd9c6276611c8c8de0c2a24947783eae5d932a)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The update includes 156 commits. Full list of changes can be found on Github [1]
All patches were refreshed with devtool. One patch had to be manually
rebased to resolve a merge conflict introduced with 255.14 [2].
[1] https://github.com/systemd/systemd-stable/compare/v255.13...v255.17
[2] 0003-src-basic-missing.h-check-for-missing-strndupa.patch
(From OE-Core rev: 57ca5a2c912fcc4836f263ff2b98c9de2130f324)
Signed-off-by: Guðni Már Gilbert <gudni.m.g@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This does not seem to be used in regular builds, but is beneficial
in rust selftest, where it allows dropping a custom patch
that is unsuitable for upstream (and was rejected by them).
Also remove an obsolete comment that seems related to the code
but describes something that was resolved long time ago.
I have confirmed that the rust selftest continues to pass with just
this one commit on top of master (as the following changes do break
the selftest).
(From OE-Core rev: 9b23f995fbc1886c36f02b0c6e1ccaf2ee0f6daa)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit bf5732e2b235ce06fa1f24fe8f0dbcbc068500e3)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Otherwise, use rust-native and cargo-native binaries as that allows
our native tweaks in them to be used for target/nativesdk rust -
same as for everything else written in rust.
In particular, this allows building target rust with
cargo-native that includes important reproducibility tweaks.
Unfortunately, this also breaks rust selftest, and that
is partially addressed by the following commit.
[YOCTO #15185]
(From OE-Core rev: d592bc02b0846411796c1d481c09833559d1d29f)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 8f2230cb51fe22ef4711a56fecfab4858c04e35b)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A flaw was found in rsync. This vulnerability arises from a race condition during
rsync's handling of symbolic links. Rsync's default behavior when encountering
symbolic links is to skip them. If an attacker replaced a regular file with a
symbolic link at the right time, it was possible to bypass the default behavior
and traverse symbolic links. Depending on the privileges of the rsync process,
an attacker could leak sensitive information, potentially leading to privilege escalation.
(From OE-Core rev: e85beb88add5e94567d7221e00cabfb3d5010be7)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A flaw was found in rsync. When using the `--safe-links` option, rsync fails to
properly verify if a symbolic link destination contains another symbolic link within it.
This results in a path traversal vulnerability, which may lead to arbitrary file write
outside the desired directory.
(From OE-Core rev: dad4a83c011310872cce07fc4141e66a98439cb1)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A path traversal vulnerability exists in rsync. It stems from behavior enabled
by the `--inc-recursive` option, a default-enabled option for many client options
and can be enabled by the server even if not explicitly enabled by the client.
When using the `--inc-recursive` option, a lack of proper symlink verification
coupled with deduplication checks occurring on a per-file-list basis could allow
a server to write files outside of the client's intended destination directory.
A malicious server could write malicious files to arbitrary locations named after
valid directories/paths on the client.
(From OE-Core rev: c34cbef572e18c60bb7600fda370d6c46688c7b3)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A flaw was found in rsync. It could allow a server to enumerate the contents of an
arbitrary file from the client's machine. This issue occurs when files are being
copied from a client to a server. During this process, the rsync server will send
checksums of local data to the client to compare with in order to determine what
data needs to be sent to the server. By sending specially constructed checksum values
for arbitrary files, an attacker may be able to reconstruct the data of those files
byte-by-byte based on the responses from the client.
(From OE-Core rev: 19f4e7bd965c63f19cc756e6e2bf8f58d9e1dc8d)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A flaw was found in the rsync daemon which could be triggered when rsync compares
file checksums. This flaw allows an attacker to manipulate the checksum length
(s2length) to cause a comparison between a checksum and uninitialized memory and
leak one byte of uninitialized stack data at a time.
(From OE-Core rev: fb8439e856d5ea10d12180020a14442c3b101e56)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A heap-based buffer overflow flaw was found in the rsync daemon. This issue is due
to improper handling of attacker-controlled checksum lengths (s2length) in the code.
When MAX_DIGEST_LEN exceeds the fixed SUM_LENGTH (16 bytes), an attacker can write
out of bounds in the sum2 buffer.
(From OE-Core rev: ad0e13912b17ca19ffbd7ea6a366f7c968517fb2)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
>From git 2.48 release notes:
"""
When "git fetch $remote" notices that refs/remotes/$remote/HEAD is
missing and discovers what branch the other side points with its
HEAD, refs/remotes/$remote/HEAD is updated to point to it.
"""
This means with git 2.48 onwards, there is a mystery "HEAD" revision
appearing in some of our shallow clone tests. We can avoid this by
using the same canonicalization as used for the reference revisions.
This resolves autobuilder failures on the Fedora 40 workers.
(Bitbake rev: aa0e540fc31a1c26839efd2c7785a751ce24ebfb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit c83444d1210740e27b1744d3aa7c5cad4e28db2f)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
We don't run reproducible-builds on specific distros anymore, but on a
distro at random depending on what is available on the Autobuilder. Fix
the link to this builder and remove distro specific ones.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
(From yocto-docs rev: bb9e018adcc10c642f87d0b95432783b5eb8057b)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
(cherry picked from commit 8bd2bc3c00ca80f4c000a2a8d618a9f8ea3aa54b)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
We have moved to Valkyrie which is hosted on
https://autobuilder.yoctoproject.org/valkyrie. Update the URL in the
documentation.
Also, the YOCTO_AB_URL macro was used in a single location in the
documentation so replace it by the :yocto_ab: custom extlink and remove
the macro.
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
(From yocto-docs rev: b02e90b6eb32ce57a98e0e3720848e5cdfbb69d0)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
(cherry picked from commit 0b0ed55d909dd11cdc9b29b105473271627c025e)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The '-fdebug-prefix-map' options are used to map source files locations,
otherwise, DW_AT_comp_dir will contain buildpath.
The '-gno-record-gcc-switches' option is used to fix the buildpath introduced
by '-fintrinsic-modules-path' option, which is automatically added by fortran.
Here's some output from 'readelf --debug-dump libgfortran.so.5.0.0' when this
option is not added:
"""
<0><1a37d3>: Abbrev Number: 4 (DW_TAG_compile_unit)
<1a37d4> DW_AT_producer : (indirect string, offset: 0xd653): GNU Fortran2008 14.2.0 -m64
-march=core2 -mtune=core2 -msse3
-mfpmath=sse -mshstk -g -O2 -O2 -fstack-protector-strong -fimplicit-none
-fno-repack-arrays -fno-underscoring -fcf-protection=full
-fallow-leading-underscore -fbuilding-libgfortran -fPIC
-fintrinsic-modules-path /ala-lpggp72/qichen/Yocto/builds/build-poky/tmp/work/
core2-64-poky-linux/libgfortran/14.2.0/recipe-sysroot-native/usr/bin/x86_64-poky-linux
/../../lib/x86_64-poky-linux/gcc/x86_64-poky-linux/14.2.0/finclude
-fpre-include=../../../../recipe-sysroot/usr/include/finclude/math-vector-fortran.h
"""
See https://gcc.gnu.org/pipermail/fortran/2024-October/061204.html for more
detailed information.
(From OE-Core rev: 660e00469f9c99fe733cc8b37f67438a96ff2e97)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Since pulseaudio v16.99.1, the library needed is webrtc-audio-processing-1.
This fixes
Run-time dependency webrtc-audio-processing-1 found: NO (tried pkgconfig and cmake)
Looking for a fallback subproject for the dependency webrtc-audio-processing-1
../pulseaudio-17.0/meson.build:730:15: ERROR: Automatic wrap-based subproject downloading is disabled
The library is available in meta-openembedded/meta-multimedia.
(cherry picked from commit 4661c49eb4f0ed89a3d027d9a003c40744baaf38)
(From OE-Core rev: e80c3ca36f08a259e13fd94f1c87a7f5bf485a8b)
Signed-off-by: Esben Haabendal <esben@geanix.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Esben Haabendal <esben@geanix.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Using the package architecture to select the right qemu options to pass
to qemu-user is incorrect, and fails for recipes that set PACKAGE_ARCH
to MACHINE_ARCH (as the qemuppc workarounds suggest) because there are
not typically any options set for the machine name.
Solve this by using TUNE_PKGARCH instead: for the majority of recipes
this is the same value, but for machine-specific recipes it remains the
same instead of changing to the machine name.
This means we can remove the qemuppc workarounds, as they're obsolete.
Also update the gcc-testsuite recipe which uses the same pattern to use
TUNE_PKGARCH, and generalise the else codepath to avoid needing to
update the list of architectures.
[ YOCTO #15647 ]
(From OE-Core rev: 972ca555ff3aa41d32980477850c92915b6395ed)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 414b754a6cbb9cc354b1180efd5c3329568a2537)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The nativesdk class overrides PACKAGE_ARCH and unsets TUNE_FEATURES, but
as recipes might want to look at TUNE_PKGARCH too (for example, when
setting QEMU_EXTRAOPTIONS) we should also override that variable.
Otherwise, a nativesdk recipe will have the TUNE_PKGARCH of the target,
which leads to errors (eg passing mips arguments to an arm qemu).
(From OE-Core rev: 812cf123af5821c300c630cda35be8faed73b9d5)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 05322beb290e1db30bef49b4364f8a8e6e9f7408)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This reverts commit 49391fdcf71b32c5fd3c7b134c1d1c45cc1db388 which
introduced a bluetooth regression on systems with read-only rootfs.
When configuration files are missing, bluez tries to generate them which
fails on a read-only rootfs. As a result bluetooth service fails to
start and bluetooth is broken. Hence, configuration files need to be
installed in the rootfs in a way or another.
Bluez commit be0e79629 (build: ship all config files with --enable-datafiles,
2024-02-12) introduced configuration files installation in bluez version
5.73. However, scarthgap pulls in version 5.72, so it is responsible of the
installation of configuration files until bluez is upgraded. Scarthgap
commit 49391fdcf71b32c5fd3c7b134c1d1c45cc1db388 removed installation of
configuration files too early, hence the revert.
(From OE-Core rev: 54a7014a801ddbda2a7dfe1ab560a154064ad47e)
Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The ssh target is currently well tailored to easily retrieve textual output
from a command run on a remote target. It could also be used to retrieve
raw data from a command run onto a remote target (for example, to feed this
data directly to another program), but it currently suffers two minor
issues preventing such use case:
- stderr is piped to stdout, so any error log will be mixed in the program
output
- the final output is decoded as utf-8 and stripped
Allow to return the raw, unmodified output by adding an optional "raw"
parameter. Keep it to False by default to preserve the current behavior.
When enabled, do not return a string but the raw output as bytes.
(From OE-Core rev: 8d05dc6e2284b7ed7c32a8215b9c8bf6f7dabf00)
(From OE-Core rev: d09187db648053a763036a5209efd584b352cf31)
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Update to the 5.0.6 release of the 5.0 series for buildtools.
(From OE-Core rev: 6c0372a67b410b8f7ba9b43ffd17efd2f3b439aa)
Signed-off-by: Aleksandar Nikolic <aleksandar.nikolic@zeiss.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
