OpenCL is an important part of the GPU-related world. It makes sense to
be able to provide headless environment (without OpenGL and Vulkan), but
having just OpenCL as a GPU user. Currently it is not possible since
mesa requires either of those to be enabled for the DISTRO.
Add new 'opencl' DISTRO_FEATURE, controlling enablement of OpenCL.
Note: Mesa, if built with the libclc packageconfig (which is required
for OpenCL driver) depends on the mesa-clc tool from the mesa-native
package. It is required to propagate opencl DISTRO_FEATURE to the native
set in order to be able to fulfill mesa -> mesa-native dependency as
otherwise mesa-native package will be skipped.
(From OE-Core rev: 3061d6061e74a545b7a190fd13b52ac181994dd1)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
GPE_MIRROR is not used by any recipes. Beside this it looks like
the url (http://gpe.linuxtogo.org/download/source) is unavailable,
and the main url (linuxtogo.org) is using an invalid certificate
(issued for another website).
It looks this mirror isn't useful nor valid anymore - so drop it.
(From OE-Core rev: 458833061e83c842e9d92dd822d17b914d71ca63)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Switch our default qemu images to use .zst compressed images by default
since this is the output format we release during the release process
and is the one that users would prefer to download. This makes the release
process use the actual generated output from the system and avoids post
processing.
(From OE-Core rev: aa5f60d1fcb716a2b2174dffcaf35442bff1f1fb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The uninative tarball requires xz to decompress:
WARNING: Disabling uninative as unable to install uninative tarball:
WARNING: tar (child): xz: Cannot exec: No such file or directory
(From OE-Core rev: 9c0bc6edf5e6706597563924f62bbab6fdd38ac2)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since OE-Core rev: cc83e45484656a6b577ff84817131735023daad4
the STAMP value and STAMPCLEAN glob have been mismatched. The
issue is present since the PR part was removed from the STAMP variable
in that comit.
An example use case that I found was broken due to this:
1. Have recipes foo_A.bb and foo_B.bb
2. Build foo-native with PREFERRED_VERSION_foo-native = "A"
3. ${COMPONENTS_DIR}/x86_64-linux/foo-native has version A
4. Build foo-native with PREFERRED_VERSION_foo-native = "B"
5. ${COMPONENTS_DIR}/x86_64-linux/foo-native has version B
6. Build foo-native with PREFERRED_VERSION_foo-native = "A"
7. ${COMPONENTS_DIR}/x86_64-linux/foo-native still has version B
In my case the PREFERRED_VERSION comes from different machines.
The issue showed itself when a bar-native compiled against foo-native
version A was pulled from sstate-cache and foo-native in version B was
kept in ${COMPONENTS_DIR} after previous build for a different machine.
The two variables should be in sync and this patch corrects that.
[RP: Tweak commit message]
(From OE-Core rev: 932be19f48735d72a72de2771911119433956f4f)
Signed-off-by: Michal Sieron <michalwsieron@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this fix:
devtool deploy-target cmake-example qemu1 --strip
...
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped/usr/lib/libcmake-example-lib.so.1.0.0': Operation not permitted
cp: failed to preserve ownership for ...cmake-example/1.0/devtool-deploy-target-stripped/usr/lib/libcmake-example-lib.so.1: Operation not permitted
cp: failed to preserve ownership for ...cmake-example/1.0/devtool-deploy-target-stripped/usr/lib/libcmake-example-lib.so: Operation not permitted
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped/usr/lib': Operation not permitted
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped/usr/bin/cmake-example': Operation not permitted
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped/usr/bin/test-cmake-example': Operation not permitted
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped/usr/bin': Operation not permitted
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped/usr': Operation not permitted
cp: failed to preserve ownership for '.../cmake-example/1.0/devtool-deploy-target-stripped': Operation not permitted
tar: ./usr/lib/libcmake-example-lib.so.1.0.0: time stamp 2025-07-06 16:46:06 is 0.527890738 s in the future
tar: ./usr/lib/libcmake-example-lib.so.1: time stamp 2025-07-06 16:46:06 is 0.527462566 s in the future
tar: ./usr/lib/libcmake-example-lib.so: time stamp 2025-07-06 16:46:06 is 0.526732779 s in the future
tar: ./usr/lib: time stamp 2025-07-06 16:46:06 is 0.526415655 s in the future
tar: ./usr/bin/cmake-example: time stamp 2025-07-06 16:46:06 is 0.52568721 s in the future
tar: ./usr/bin/test-cmake-example: time stamp 2025-07-06 16:46:06 is 0.525054415 s in the future
tar: ./usr/bin: time stamp 2025-07-06 16:46:06 is 0.524821739 s in the future
INFO: Successfully deployed .../cmake-example/1.0/devtool-deploy-target-stripped
With this fix:
devtool deploy-target cmake-example qemu1 --strip
...
INFO: Successfully deployed .../cmake-example/1.0/devtool-deploy-target-stripped
This is most probably related to the commit:
2502da81709f25de499277b28d33c915638c45f6
bitbake.conf/pseudo: Switch from exclusion list to inclusion list
(From OE-Core rev: 8b42b698ea13e1951f7bac4ddd89e13c9b0cb3a6)
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>
Currently, the "shared" directory permissions of sstate are hardcoded. Since
multiple areas of the code reference this, separate it out to a variable to
allow the behaviour to be configurable. Initially this applies to SSTATE_DIR.
(From OE-Core rev: ce32daa9843bcb5f6daf3560c64ca9e5144adcb0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This transitions most of the recipes to have their sources
in UNPACKDIR, which over time will allow more simple and logical
source code handling in various pieces of the Yocto project.
(From OE-Core rev: 50439f56b2d94769de928c70eebdfd4b47794fb4)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is shorter and doesn't include the unnecessary task name, just the
result of it: source trees and files.
(From OE-Core rev: f19ea21c8ebf8ce211b14e69b27c82faf080185a)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Removing all the S = ${WORKDIR}/git assignments works because BB_GIT_DEFAULT_DESTSUFFIX
is set to match S from bitbake.conf (which itself is set to match typical tarball
releases).
A few recipes are setting S to a sub-directory of the git tree and need
to be adjusted accordingly.
bzip2 recipe is fetching a tarball and separately cloning tests;
adjust the recipe to put the latter into 'bzip2-tests', instead of 'git'.
devupstream.bbclass no longer needs to rewrite S, and is adjusted accordingly.
Adjust scripts/lib/recipetool/append.py to not hardcode 'git' as unpack
destination.
Adjust kernel-yocto.bbclass to use the git unpack variable instead
of hardcoding 'git' (there's also removal of repetition of
string constants and a correction of workdir/unpackdir mismatch in
one of the if-else branches).
Ensure build-appliance-image recipe does not use 'git' as checkout directory for
poky repo, but rather explicitly name it 'poky'.
Ensure reproducible.py code that looks for git repositories does not
hardcode 'git' but uses the destination set by BB_GIT_DEFAULT_DESTSUFFIX.
Ensure recipetool does not write out unneeded S settings into newly
created recipes that fetch from git.
Adjust selftest to not hardcode 'git' as unpack directory.
(From OE-Core rev: f80c07019ddadaf9c5fb890faabfda7920ecd15e)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Please see the patch for bitbake for rationale. With this
setting in place, it's possible to set
OE_FRAGMENTS += "distro/poky machine/qemuarm"
and bitbake will interpret that as
DISTRO = "poky"
MACHINE = "qemuarm"
(From OE-Core rev: e959f916b4d2bb8af2e6a04116de9430bbde0c9f)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This change implements a toolchain selection mechanism. Selection is
made using a set of variables, primarily PREFERRED_TOOLCHAIN_TARGET which
defaults to gcc.
It uses the familiar name for toolchain e.g. "gcc" which selects GNU
compiler + binutils as default C/C++ toolchain or "clang" which will
use LLVM/Clang Compiler. Layers an add their own toolchain definitions
too.
There are also PREFERRED_TOOLCHAIN_NATIVE and PREFERRED_TOOLCHAIN_SDK
which will ulitmately allow selection of the toolchain used for the
native/cross and nativesdk/crosssdk compilers. This currently isn't
functional but is essential to the patch to ensure things are set
to the existing gcc support in those cases.
Users would most commonly want to set:
PREFERRED_TOOLCHAIN_TARGET ?= "clang"
in local.conf or other distro specific global configuration metadata.
It is also selectable at recipe scope, since not all packages are
buildable with either clang or gcc, a recipe can explicitly require
a given toolchain using the TOOLCAHIN variable, e.g. glibc can not
be built with clang therefore glibc recipe sets:
TOOLCHAIN = "gcc"
The TOOLCHAIN variable is distinct from the user preference so recipes
with specific requirements can be identified. This also allows different
polcies to be be specified for native/SDK cases in the future.
(From OE-Core rev: 45bdedd213aff8df3214b95ef2a8551c0abd93a0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now we have decorators that can do this, move the variable dependencies
exclusions alongside the code that needs them for maintainability.
(From OE-Core rev: e522169c5f95de6fc74b43672573700d8eb8e082)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The source information used during packaging can be use from other tasks to
have more detailed information on the files used during the compilation and
improve SPDX accuracy.
Source files used during compilation are store as compressed zstd json in
pkgdata/debugsources/$PN-debugsources.json.zstd
Format:
{ binary1: [src1, src2, ...], binary2: [src1, src2, ...] }
I checked the sstate size, and it slightly increases using core-image-full-cmdline:
without patch: 2456792 KB sstate-cache/
with patch: 2460028 KB sstate-cache/
(4236 KB or 0.17%)
CC: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: c507dcb8a8780a42bfe68b1ebaff0909b4236e6b)
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
TCOVERRIDE is defined to toolchain-<TOOLCHAIN> and its added to OVERRIDES
that a recipe can see and it can use "toolchain-gcc" or "toolchain-clang"
to set specific metadata based upon global distro toolchain policy.
(From OE-Core rev: 6010f47124d9067609bbe5d9ff16193c8bf79acf)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As far as I can tell, we don't have anything using lz4 in our key
build dependencies. It isn't in ASSUME_PROVIDED and our code automatically
adds lz4-native dependencies where needed. Even then, it is very rarely
needed, mainly for some kinds of SRC_URI (none in OE-Core) and some
filesystems/images.
As such, drop this from HOSTTOOLS and rely on lz4-native, which is what
was already happening anyway. This simplies host setup slightly.
(From OE-Core rev: b13654a4fc2fe6397f1802c14b2c6ad44b59a45b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ftp.gnu.org is the main server of the GNU project, however download speed
can vary greatly based on one's location.
Using ftpmirror.gnu.org should redirect the request to the closest up-to-date mirror,
which should result sometimes in significantly faster download speed, depending
on one's location. This should also distribute the traffic more across the mirrors.
This information was sourced from https://www.gnu.org/prep/ftp.html .
(From OE-Core rev: d8c6f01d7467e018aa0ed27a87850d9e4434a47a)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, pseudo tracks all files referenced within its presence unless
they're listed in an exclusion list. The exclusion list has grown to be
fairly unwieldy.
This patch swaps PSEUDO_IGNORE_PATHS for PSEUDO_INCLUDE_PATHS which in
theory should be easier and more explicit to maintain.
This change does drop many directories from pseudo coverage including
/home and /tmp. There may be adapatations needed for recipes/classes
using pseudo in specific ways.
(From OE-Core rev: 2502da81709f25de499277b28d33c915638c45f6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-ffile-prefix map is more comprehensive when it comes to reproducible
builds and its superset of all prefix-mapping options in compilers
This makes is cleaner and workable across gcc and clang, clang does not
support -fcanon-prefix-map and it has to be explicitly omitted when using
clang.
There are lambdas generated in templates by clang which still get the
absolute paths despite -fdebug-prefix-map, this helps with that as well.
nasm is an outlier and we have fixed it by adding -fdebug-prefix-map option
luckily we do not pass DEBUG_PREFIX_MAP to nasm, in all recipes which use
nasm either pass -fdebug-prefix-map explicitly to nasm or they rewrite it
to use nasm flags syntax.
We have discussed this in past [1]
[1] https://patchwork.yoctoproject.org/project/oe-core/patch/20230428032030.2047920-1-raj.khem@gmail.com/#10281
(From OE-Core rev: ff73fa7ef7666a6dbe34f15515bc3ab6e574c5b0)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Jacob Kroon <jacob.kroon@gmail.com>
Cc: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change DEBIAN_MIRROR to point at the canonical server, deb.debian.org.
This is a CDN-backed server using network magic to load balance across
the planet so there's no need to set a slew of regional mirrors.
Also add a more recent snapshot.debian.org from the beginning of 2025.
(From OE-Core rev: 3d95d45836accd29916dd8cb9bfe624d63d6c202)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To be able to switch toolchains, we need to separate out the gcc definitions
into seperate include files. This patch starts that process. Whilst the
include is still hardcoded for now, it allows developers to start experimenting
with this locally more easily and stops people reinventing this patch. A
sample clang configuruation is also included which I was using for experimentation.
(From OE-Core rev: be063d58c0985a2c43c16302efb44706fbf3f1b3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bitbake is about to change the default value of this from "default" to "". The
original reason for this was to make this kind of include file usage easier.
Instead we were going to complicate bitbake code having to map one value into
the other.
Instead, stop using "default" and put a slightly horrible bit of code in bitbake.conf
as an alternative.
This means a "default.conf" in the multiconfig directory will stop working but this
was never something anyone was expected to use.
The eSDK code also needs updating for this change.
(From OE-Core rev: ff469ab2e865063bbc529031bbfd76cba5040073)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"packaged staging" is obsolete and now we have sstate. Multimachine is just
the norm now, I doubt people remember how things used to be!
Drop the comment as it is misleading and obsolete.
(From OE-Core rev: 808d2a526e3dd6d77c524d8faa0af3e78cf0bed6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixing native class extension code highlighted this was missing, we do assume
the system has a working libstdc++ compiler/runtime.
(From OE-Core rev: a9ae7001adeecf420d9a95654ce27d7e7b8f82a5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With some native dependency handling fixes under discussion,
bash-completiion-native makes it into the dependency chain. Add this
to ASSUME_PROVIDED since we don't want to build it rather than trying
to remove all references in the native case (it comes from
glib-2.0-native).
(From OE-Core rev: 401706ed6d51917d76726098a767932970990805)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was a report that the existing addfragments statement comes in too late,
specifically after the DISTRO/MACHINE includes have already been handled. The goal
for fragments content is to behave exactly like the settings in local.conf would
and so we need to handle the fragments just after that file.
(From OE-Core rev: e820fa96d078478ea3510164373989090e8c9419)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Please see the patch to bitbake for syntax and implementation details.
The path prefix to fragments is in its own variable so it doesn't have
to be hardcoded into tools.
(From OE-Core rev: 5bdbabd7b5d244a44c33065b04dd76dad76888a8)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows using it where only a number is needed, such as rpm compression
setting.
(From OE-Core rev: 9c284b4c661566855f15ba3f4508982c2a60b147)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Following bitbake "cooker: Drop support for BB_DANGLINGAPPENDS_WARNONLY",
show warnings for use of the variable.
(From OE-Core rev: ab0f6898a0f3892a9c4536919adaa1d8d847bb7c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I was surprised to realise our buildtools doesn't support IPv6 which breaks
usage in our own autobuilder, let alone anywhere else.
Enable ipv6 in our SDKs and enable acl/xattr as well before we have the same
kind of issues with those, these features are now common on most linux systems
and we should be defaulting to including them.
(From OE-Core rev: e86686cbdbaf5368fae0a490d52a043f8ed4fa0f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We may as well define the dll output for mingw alongside the darwin dylib
definitions. There are some recipes which output .so files even on mingw
but those can be handled specifically in mingw.
(From OE-Core rev: bb3101fffceacfa4c021c33affb7c785da8d859f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In oe-core ebcd355 TCLIBCAPPEND (a string that is appended to TMPDIR) was
removed entirely. Warn if this is being set by the distro as it will no
longer have any effect.
(From OE-Core rev: 992ba784c168710328749fd61a0e2869df519dea)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* the default STAGING_DIR_NATIVE starts with STAGING_DIR_HOST and the
only difference is '-native' suffix at the end
* this can lead into replacing STAGING_DIR_NATIVE path with just "-native"
in FILE macros
* I've noticed this by accident in python3-matplotlib where buildpaths
QA warning was triggered only for lib32-python3-matplotlib and it was
because pybind11 path to STAGING_DIR_NATIVE was mapped to only
'-native/<path>' in python3-matplotlib build (which doesn't trigger
buildpaths QA and lib32-python3-matplotlib the macro path wasn't
replaced at all, because of 'lib32-' prefix in:
-fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/lib32-recipe-sysroot= \
-fmacro-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/lib32-recipe-sysroot= \
-fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/recipe-sysroot-native= \
* more details in meta-python fix for lib32-python3-matplotlib:
https://lists.openembedded.org/g/openembedded-devel/message/112074
* the order of *-prefix-map options still seems to be that the last
one matching wins and this works with gcc and clang, see:
https://reviews.llvm.org/D148975?id=516863https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591
* some components might sometimes be built with -coverage and could use
-fcoverage-prefix-map:
https://reviews.llvm.org/D148757
or -fprofile-prefix-map:
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fprofile-prefix-map
but will leave that to recipes which actually use -coverage for now
(From OE-Core rev: 90dea34cb624af744a7d5deabdd5cbfb3c10db87)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Drop VOLATILE_TMP_DIR, use FILESYSTEM_PERMS_TABLES instead. By default,
FILESYSTEM_PERMS_TABLES ?= "files/fs-perms.txt \
files/fs-perms-volatile-log.txt \
files/fs-perms-volatile-tmp.txt"
it contains 'files/fs-perms-volatile-tmp.txt', which means volatile tmp
is enabled. User can disable volatile tmp by remove
'files/fs-perms-volatile-tmp.txt' from FILESYSTEM_PERMS_TABLES.
* If volatile tmp is disabled, both /tmp and /var/tmp are persistent
(From OE-Core rev: 8d1ae67b89c45f78162e070228086c7ef88c3264)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop VOLATILE_LOG_DIR, use FILESYSTEM_PERMS_TABLES instead. By default,
it contains 'files/fs-perms-volatile-log.txt', which means volatile log
is enabled. User can disable volatile log by remove
'files/fs-perms-volatile-log.txt' from FILESYSTEM_PERMS_TABLES.
(From OE-Core rev: 91128c6517066715f2afe6b46aa3206c7cf3653e)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It makes sense for the distro to be able to override "policy" from cve-check-map
which is intented to provide defaults. Tweak the ordering to allow for this,
ensuring it is included before the distro includes.
(From OE-Core rev: fb22a7e7ee38a0e923e86a68d0e9b86d479f264d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some wic images need this command. Since it is part of coreutils, it doesn't really
cost anything to have in HOSTTOOLS and it avoids signifiant build dependencies on
coreutils-native.
[YOCTO #15571]
(From OE-Core rev: 522000ce5c4f0201cbe42d7826b6a8489ed10117)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move the -pipe option out of the optimization flags and directly into
the flags variables since we always use it now.
Also move the debug prefix mapping there to match the nativesdk case
which already does this.
Fix the documentation and two recipe usages to match the change.
(From OE-Core rev: 9badf68d78d995f7d5d4cf27e045f029fc6d4044)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
eliminate-unused-debug-types is a compiler default so we no longer
need to specify this. Drop the option. Also drop an obsolete comment
about another debug flag.
(From OE-Core rev: 1d5162689fbfeddb10fa60e4150ca87f1fa2243e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now S and B can't be set to WORKDIR, add to PSEUDO_IGNORE_PATHS unconditionally
and simplify the code.
(From OE-Core rev: 26cd2d56261827ad8d07e2145e95f82422accac2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change do_unpack to unpack files to a subdirectory of WORKDIR instead of WORKDIR
itself. There are several good reasons for this but it is mainly about being able
to isolate the output of the unpack task and tell the files apart from other things
which are created in workdir (logs, sysroots, temp dirs and more).
This means that when the do_unpack task reruns, we can clean UNPACKDIR and know
we have a standard point to start builds from.
It also makes code in tools like devtool and recipetool easier.
To reduce the impact to users, if a subdirectory under UNPACKDIR matches
the first subdirectory under WORKDIR of S, that directory is moved into position
inside WORKDIR. This preserves the behaviour of S = "${WORKDIR}/git",
S = "${WORKDIR}/${BPN}" and other commonly used source directory setups.
The directory is moved since sadly many autotools based projects can't cope with
symlinks in their paths.
The patch also updates reproducible and SOURCE_DATE_EPOCH handling to
match the new potential source locations. We can get rid of the horrible
list of hardcoded directories in WORKDIR to ignore from that code.
(From OE-Core rev: b84eec5c4cbf4b39d6712800dd0d2fe5337721cb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having the unpack directory hardcoded to WORKDIR makes it really hard to
make any changes to the unpack process to try and allow for cleanup for example.
As a first step toward unraveling the intertwined location usages, add a
variable, UNPACKDIR which is where the fetcher is asked to unpack fetched
sources. It defaults to the existing value of WORKDIR at this point.
(From OE-Core rev: e022d62ba917790af2121da57646271ef17c03fa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oldincludedir was removed by 506c91cbc6a604a84e37e53ccff430436369802e
(From OE-Core rev: 0228ab43e9b659771f4f59944897aec6879f8209)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* The tarfile module doesn't support xz options or environment varible
XZ_DEFAULTS, this makes do_ar_patched incrediblely slow when the file is
large, for example, chromium-x11 is about 3GB:
- "bitbake chromium-x11 -car_patched" hasn't been done after 3 hours on my
host, I checked the partial tar.xz file is only 1.5GB, so maybe more than 6
hours is required to complete the task.
- Now only less than 4 minutes is needed on the same host.
* Need add xz to HOSTTOOLS when archiver.bbclass is enabled and compression is xz.
(From OE-Core rev: 6548354f049b173e8d443bc547d35c9d9fc05259)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is actually a use for nativesdk MACHINE_FEATURES; for example
qemu-usermode being supported, as this is needed to build profile-guided
optimised code.
We shouldn't use the target MACHINE_FEATURES for this because the target
and the SDK can be entirely different, so instead set the
MACHINE_FEATURES in nativesdk.bbclass to SDK_MACHINE_FEATURES (which
defaults to "") and let the conf/machine-sdk/*.conf files set that as
appropriate.
(From OE-Core rev: 14571764b7e046507f81bbe589a9f42c5b16665a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Link: https://lore.kernel.org/r/20231221170159.1995650-2-ross.burton@arm.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
