* this caused liberation-font-native to depend on TUNE_PKGARCH target fontconfig
because ${MLPREFIX}fontconfig-utils is added to RDEPENDS in anonymous python
* the dependency tree for liberation-font-native got much shorter
(just quilt-native and liberation-font-native itself):
2 after/pn-buildlist
78 before/pn-buildlist
* fixes graphviz-native signature issue as well as detected with sstate-diff-machines.sh
$ bitbake-diffsigs \
sstate-after/mako/x86_64-linux/graphviz-native/8.1.0.do_populate_sysroot.sigdata.184d4fd355f1e7a2d7d929ef4b5f62b94e2071df9dd674b2067ec21bfc7bcc1b \
sstate-after/qemux86-64/x86_64-linux/graphviz-native/8.1.0.do_populate_sysroot.sigdata.35da674d2dbc275bac02869dfce4165466315023910bdef65a6026e2cb942a46
Hash for task dependency liberation-fonts-native:do_populate_sysroot changed from 310d3da04ad9abf8ee99997e53d1ffa71c2b7d9d60fb0e8de85171a9ab6a77d3 to 048420ad1410c2b8d95498fc3c11681207335a2c722836f1f3e683cc449814da
(From OE-Core rev: 098d4ca85c2bc77949843f117c6e336d5b77271d)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The latest 6.5 kernels do not appear to create the source file in
${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
recipe errors out when trying to remove it. Simple fix is to add the
-f (force) flag to the call.
(From OE-Core rev: 2e669bf797b15d803e7d6a700e449bdc467a4bcc)
(From OE-Core rev: 7e177848f97eb9958619c28b5e5dadee12f67507)
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Variable overrides in KCONFIG_CONFIG_COMMAND do not work as expected due
to double quote mismatches. The issue is reproducible in an environment
where gold is the default linker. Below is an example snippet of
run.do_terminal generated by do_menuconfig.
do_terminal() {
exec sh -c "make menuconfig CC="aarch64-webos-linux-gcc ..."
LD="aarch64-webos-linux-ld.bfd ..."
...
}
Although LD override is set to bfd correctly, it is not passed to make
and make menuconfig ends up with messages like:
| gold linker is not supported as it is not capable of linking the kernel proper.
| scripts/Kconfig.include:56: Sorry, this linker is not supported.
(From OE-Core rev: 9c483765db762dbe8020423c8778518612b7e5f7)
(From OE-Core rev: 536c477838fb1a318c5b283475de7f0eac99c872)
Signed-off-by: Jaeyoon Jung <jaeyoon.jung@lge.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit d4664d2b79)
Backported: File was renamed between kirkstone and master.
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
cargo_do_compile runs only if the recipe is built using cargo
as the top level tool. Some recipes hide usage of cargo inside setuptools
(or autoconf) and use do_compile definitions specific to those,
and so the environment isn't properly set up.
This was exposed by latest versions of python3-cryptography.
(From OE-Core rev: a3f566fcbfc02e0a3b3f6a676d6dde88a5b50506)
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 9f4ff643a028d7f5670d80861f2ce19ca2d90faa)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Instead of deleting setscene tasks, now SSTATE_SKIP_CREATION is set instead.
This seems to fix the compile issues where the populate_sysroot task was
not run when an externalsrc recipe was built as a dependency.
[YOCTO #15164]
[RP addition: The deltask was added by me in 2012 when the class was created.
The trouble is bitbake assumes 'sstate' tasks have a setscene task and by deleting
the setscene task, bitbake stops thinking the task can be accelerated. There is other
code in the sysroot code which assumes some tasks are always sstate tasks.
We cannot delete the task without changes to the way bitbake learns about 'setscene'
tasks so the patch is correct, avoiding creating files is the better approach given
the way the world works now.
There would be concerns about exisitng sstate reuse however this shouldn't occur
since SRC_URI changes and that will change the underlying hashes. Hash equivalency
could potentially cause issues by joining hashes together again however if the output
matches, that shouldn't in theory cause any issue.]
(From OE-Core rev: f6bb8438a18dfa2a520ad6fa65662d908f4ef0ed)
Signed-off-by: Peter Suti <peter.suti@streamunlimited.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit ee4667a24ccdd8c9d547e73aecf661e6a1283890)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Due to an oversight in the do_symlink_kernsrc function, the path
comparison between "S" and "STAGING_KERNEL_DIR" is broken. The code
obtains both variables, but modifies the local copy of "S" before
comparing them, causing the comparison to always return false.
This can cause the build to fail when the EXTERNALSRC flag is enabled,
since the code will try to create a symlink even if one already exists.
This patch resolves the issue by comparing the variables before they are
modified.
(From OE-Core rev: cf2267f80ec44b24c627347df7efbd492a07dcfa)
Signed-off-by: Staffan Rydén <staffan.ryden@axis.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit afd2038ef8a66a5e6433be31a14e1eb0d9f9a1d3)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Default search in meson would grok /usr/bin for llvm-config and if found
will use it, which might add wrong paths into cflags/ldflags, since we
depend on llvm-native when building gallium support ( thats when
llvm-config is effective), its better to point llvm-config into native
sysroot so it can add correct paths into compiler/linker cmdline
(From OE-Core rev: 8e6b616066ba0f7f452f929dc7c412e620da9101)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit cc73360b9728812ed6123e30559b77d8e89cc21c)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The comment specifies how to use the variables but uses the older and
now unsupported override syntax. Let's update to match the newer syntax.
Cc: Quentin Schulz <foss+yocto@0leil.net>
(From OE-Core rev: 0a381eea4d50ff1c6e7c7d0d4df62eb581454b48)
(From OE-Core rev: 0e9a70ee3c8f78db746d3cb627c6b212e1b4e4e4)
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit bb64f3fed29b9532e6ddc9a2ba0283d373622d87)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Since explicit debug package creation via ${KERNEL_PACKAGE_NAME}-dbg has
been added to kernel, it has to cover all PACKAGE_DEBUG_SPLIT_STYLE
options. For ex. when the variable "debug-file-directory" package search
path has to be set explicitly, otherwise it will not find any files.
(From OE-Core rev: 9adbda8450c57f49edf85e3b3433304e8ac8267e)
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 9c39da147683dcaaa244b3ddc4531c4408ad5c9e)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Currently, the latest version abseil-cpp contains a new library named "absl_log_internal_format", it's
basic package config(.pc file) as below:
prefix=/usr
exec_prefix=${prefix}
......
Requires: absl_config = 20230125, absl_core_headers = 20230125, absl_log_internal_append_truncated = 20230125,
absl_log_internal_config = 20230125, absl_log_internal_globals = 20230125, absl_log_severity = 20230125,
absl_strings = 20230125, absl_str_format = 20230125, absl_time = 20230125, absl_span = 20230125
......
Normally, the process_pkgconfig() would process variable data before field data in a .pc file, but in the
absl_log_internal_format, the field data in "Requires" section contains "xxxx = xxxx" format, the
process_pkgconfig() treats them as normal variable and using the setVar() in bitbake's data_smart.py
try to process. The absl_log_internal_format field data contains "_append_", this hit the setVar() checking
and finally bitbake stop building and reporting an error as below:
"Variable xxx contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake."
This patch move the field data process before variable process to avoid the process_pkgconfig() treat the field
data as variable.
(From OE-Core rev: e7d3e02a624f7ce23d012bb11ad1df2049066b37)
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
(cherry picked from commit a73e269d3e591a10bb397b94b82e3fb960112d33)
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
In order to build erofs filesystems, wic must have the erofs-utils package installed into its sysroot.
(From OE-Core rev: c349c7fcb299b123824da9a13ee58222a6cbf9ec)
Signed-off-by: Heiko Thole <heiko.thole@entwicklung.eq-3.de>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Current error message is difficult to read:
ERROR: Nothing PROVIDES 'image'
trs-image was skipped: image - image: normal username test does not have a static ID defined. Add test to one of these files
It's not clear that first "image" is recipe name, second "image" is
binary package name and that "test" is the user account which does not
have a static ID defined. Improve the error message so that these are
more explicit. Now the error message looks like:
image was skipped: Recipe image, package image: normal username "test" does not have a static ID defined.
(From OE-Core rev: 572c507736b2fcc31f7f13cb3da0d5be361838f5)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 07898218f3908a83e07178b6530dfa48d55d4ec2)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
I've encountered issues reproducing initramfs and UKI image builds,
which will be fixed with this patch.
1. initramfs
There's a symbolic link to /sbin/init, which is appended to the cpio archive after creation.
The links timestamp needs to be static and the cpio append command needs the '--reproducible' flag to produce deterministic outcomes.
2. Unified Kernel Image
'--preserve-dates' is required for a static 'Time/Date' entry.
I've added '--enable-deterministic-archives' although in my case this
didn't change anything.
(From OE-Core rev: 0d8890f7c1fbea5036acefa3031dcd442b316725)
Signed-off-by: Frieder Paape <frieder@konvera.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit fd027729bafb4e085ba0949e38e724f3a8cad102)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When running prepare_recipe_sysroot task, the extend_recipe_sysroot
is run twice.
What prepare_recipe_sysroot does is executing extend_recipe_sysroot,
there's no need to add extend_recipe_sysroot to its prefuncs.
(From OE-Core rev: dad053c4b99d4aefebe40459500ad53a2b458fa0)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit bf7584a2ac16ee46ff5b41536b06bb46d0cbada7)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
If a specific kernel provider or configuration wants to enable BTF
and pahole analysis, it isn't currently possible due to the explicit
definition to false in the base kernel build arguments.
pahole is now detected by the kernel built itself, so unless
pahole-native is enabled, the result is the same.
If a kernel does require an explicit disable of pahole, it is better
to carry PAHOLE=false in those specific recipes.
(From OE-Core rev: 44b75c7442b05a2fedcc0d73982566c2bef84357)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit b1e4851a36ed47ce6ba880a49264b9a57c78cf4f)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Add new fetcher for the NVD database using the 2.0 API [1].
The implementation changes as little as possible, keeping the current
database format (but using a different database file for the transition
period), with a notable exception of not using the META table.
Minor changes that could be visible:
- the database starts in 1999 instead of 2002
- the complete fetch is longer (30 minutes typically)
[1] https://nvd.nist.gov/developers/vulnerabilities
(From OE-Core rev: b8ae26aabe825c1bc8d84fd7e0ee197695f1dee7)
Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit fb62c4c3dbca4e58f7ce6cf29d4b630a06411a97)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Upstream's dtb directory structure has no real standard. They just tend
to idle around the 2/3 directory depth. Recursively search for the
dtb/dtbo files instead of assuming anything.
Fixes: 04ab57d200 (kernel-devicetree: allow specification of dtb
directory, 2023-05-02)
(From OE-Core rev: 717b9f18a51e9c9fd5a471238aa2ea4de439ef17)
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Use the notation suggested by Martin Jansa to avoid a bashism. Also
switch KERNEL_DTBVENDORED to the more common 0/1 notation instead of
true/false.
Fixes: 04ab57d200 (kernel-devicetree: allow specification of dtb
directory, 2023-05-02)
(From OE-Core rev: b7d6fc07462e6fca09d0db7f43a62920250ef053)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Fedora/Redhat and Arch are somewhat standardized on their dtb directory
structure. Let's add some flags to configure yocto to mimic that
behavior.
Add the following variables to the kernel class:
- KERNEL_DTBDEST (controls the destination directory for dtbs)
- KERNEL_DTBVENDORED (controls if vendor subdirectories are to
be respected)
Currently KERNEL_DTBDEST is expected to be a subdir of KERNEL_IMAGEDEST
and KERNEL_DTBVENDORED is expected to be "true"/"false". This only
applies to the package directory structure. The deploydir structure is
purposely left untouched for compatibility with existing recipes.
By default this is configured to behave the same as the current recipe
and produce a flat dtb directory at KERNEL_IMAGEDEST.
(From OE-Core rev: 77d6118e20751f68ad7104edec8f14dbb5ba6ec1)
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Function 'gen_updatealternativesvardeps' still used old override
syntax when fetching variable flags. Update to use ':' instead to match
recipe meta data. This was found by review and no real issue encountered
but it is a bug that affects variable dependencies and can affect rebuilds
as task hashes might not be accurate.
(From OE-Core rev: d5fd577c066fa2fddbd16c286f2dde2883cc7828)
Signed-off-by: Peter Bergin <peter.bergin@windriver.com>
Signed-off-by: Peter Bergin <peter@berginkonsult.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5691f554b2cd50f256a8cbb1d96781e9eb6b930e)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This is a partial fix for bugzilla 15059 [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15059]
It has been noted by several people that when an initramfs is bundled:
- a lot of the kernel is rebuilt
- it takes a really long time
When looking at the logs, the second kernel compilation (that performs
the bundle) is not using the parallel make settings, and builds with
-j1.
We are already explicitly passing PARALLEL_MAKE when building kernel
modules, and by extending that explicit use to the main kernel
compilation, we ensure that we always get a parallel build.
Build times chnaged from more than 30 minutes for the bundle, to
3 minutes in local testing.
The question of whether or not too much is rebuilding during the
bundle step is still an open question, but with this tweak, at least
the build time is back in the realm of acceptable.
(From OE-Core rev: a2a889b760785474dbc04e3ec11521f6da90161d)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
(cherry picked from commit 88fd394ecf0f2174b792075d409d87046896426b)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
* otherwise it ends '<unknown>' inside esdk, because of parsing order:
# $METADATA_REVISION [3 operations]
# set /OE/build/test-D/conf/local.conf:43
# "f2da54ef432eac89b0f18eaad68e602b6990b5de"
# immediate /OE/build/test-D/layers/poky/meta/classes/metadata_scm.bbclass:9
# "${@oe.buildcfg.detect_revision(d)}"
# set /OE/build/test-D/layers/poky/meta/classes/metadata_scm.bbclass:10
# [vardepvalue] "${METADATA_REVISION}"
# pre-expansion value:
# "<unknown>"
METADATA_REVISION="<unknown>"
* This causes base-files.do_install and following tasks to have different
signatures between esdk and the build directory where this esdk was created:
bitbake-diffsigs {test-D,poky/build-uninative-disabled}/tmp/stamps/qemux86_64-poky-linux/base-files/*do_install*sigdata*
NOTE: Starting bitbake server...
basehash changed from 5b6981cf58bfd57d416b0e31611b73a26baae635dd1ac31c08d46f95064c3ffc to dbdce042da4d7813d632b6d1cc87a16f728ad20e55fecbc392830e6acf72babd
Variable METADATA_REVISION value changed from '<unknown>' to 'f2da54ef432eac89b0f18eaad68e602b6990b5de'
and an warning from "python3 /OE/build/test-D/ext-sdk-prepare.py" when eSDK is being prepared for use:
WARNING: The base-files:do_install sig is computed to be 83b9c9a6ef1145baac5a1e0d08814b9156af239c58fc42df95c25a9cd8a7f201,
but the sig is locked to 3dc22233059075978e5503691e98e79e7cc60db94259dfcd886bca2291c0add7 in SIGGEN_LOCKEDSIGS_t-qemux86-64
[RP: Add commit about why we need the override for future reference]
(From OE-Core rev: da6f6340f97e80cb1b21f6083ef5d0a9a856eef5)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
(cherry picked from commit 675ea7281c17f77bf5dea17cfd4d9da0928382a0)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Add SDK_ZIP_OPTIONS to remove symbolic link creation in zip archive or add options, e.g. for encryption of the zip archive.
(From OE-Core rev: 04b62f9459b401c276255f166d0738b6f902a576)
(From OE-Core rev: 4f5bf144bfe4f34adfc22d86783d6ce29e9f6e15)
Signed-off-by: Christoph Lauer <christoph.lauer@xtronic.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This already got fixed in the toolchain file that is used during development
in cb42802f2f
The toolchain file generated by the cmake.bbclass however does not set
CMAKE_SYSROOT. Under certain circumstances this also leads to the error:
`"stdlib.h: No such file or directory #include_next <stdlib.h>"`
during the build of a recipe.
An example where this accured was during the upgrade of the Apache Thrift
recipe in meta-openembedded to 0.11.0. With this change the build works out of
the box.
CMAKE_SYSROOT must only be set when crosscompiling, otherwise it will interfere
with the native compiler headers.
(From OE-Core rev: 1105c67d554bcd155e8247cb16efc8d6a642444f)
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
(from http://lists.openembedded.org/pipermail/openembedded-core/2018-August/154791.html )
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Poonam Jadhav <poonam.jadhav@kpit.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Newly introduced kirkstone-only commit
https://git.openembedded.org/openembedded-core/commit/?h=kirkstone&id=80839835ec9fcb63069289225a3c1af257ffdef7
broke builds with externalsrc in Gitlab-CI.
This is yocto-4.0.9 regression.
It checks if directory starts with "build" instead of
if checking if it equals to "build".
Gitlab-CI uses directory "/builds" which matches the check
but directory /build does not exist, only /builds.
After successful check it tries to move this non-existent
directory which does not exists and thus do_package fails.
(From OE-Core rev: b67e714b367a08fdeeeff68c2d9495ec9bc07304)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
NVD DB store version and update in the same value, separated by '_'.
The proposed patch check if the version from NVD DB contains a "_",
ie 9.2.0_p1 is convert to 9.2.0p1 before version comparison.
[YOCTO #14127]
Reviewed-by: Yoann CONGAL <yoann.congal@smile.fr>
(From OE-Core rev: f331c80df6c447d3073ebe3f00102c78ced242f3)
Signed-off-by: Geoffrey GIRY <geoffrey.giry@smile.fr>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 7d00f6ec578084a0a0e5caf36241d53036d996c4)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make sure to expand all MKUBIFS_ARGS_<label> and UBINIZE_ARGS_<label> vars
in 'do_image_multiubi' task to use them to init the local 'mkubifs_args'
and 'ubinize_args' vars.
See [YOCTO #15065]
(From OE-Core rev: 0fce158e59918172b9e42558fc63342384edf657)
Signed-off-by: Romuald JEANNE <romuald.jeanne@st.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 09d05215cf61981c7bc828cc0ff64c2fd5edc43c)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some packages like lirc places its unit files into $systemd_user_unitdir
and also uses them in SYSTEMD_SERVICE list in recipe. This fails in
do_package
ERROR: Didn't find service unit 'lircmd.service', specified in SYSTEMD_SERVICE:lirc.
here lircmd.service is installed in /usr/lib/systemd/system/lircmd.service
(From OE-Core rev: 7582421fc3a711e5ed23add75ed49207e699c422)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 12808a4159835b67d8d53d32bc9135811701a779)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The script generated by the sdk_ext_postinst function was not quoting
the user existing PATH when updating it causing the export command to
fail.
Add necessary double quotes around $PATH.
(From OE-Core rev: d2800e00bb4a1d169e0a91b758d3fb2ec5e35f74)
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 00e96bf250eaaded839caf465dbc0af5b604aed7)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The environment-setup script generated by the recipe was not quoting the
user existing PATH when updating it causing the export command to fail.
Add necessary double quotes around $PATH.
(From OE-Core rev: 64dd672193b43b1364acc73918a54abaa93645e4)
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 42177ff2d45ee70ad00917bb6fbabca49dae4f59)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous fix wasn't enough to address all the possible ways the
manifests might be ordered. Rework the previous fix so it is tied
to the multilib cross-canadian code which is causing the problem.
RECIPE_SYSROOT_MANIFEST_SUBDIR is not documented as I'd hope nobody
ever needs to use this outside the core multilib code.
(From OE-Core rev: 0aa703c06bf101114836ac701bbb524302c0753a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit beab42e00713880cd95a04729c892f8662fbcbed)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"""
require conf/multilib.conf
MACHINE = "qemuarm64"
MULTILIBS = "multilib:lib32"
DEFAULTTUNE:virtclass-multilib-lib32 = "armv7athf-neon"
bitbake gcc-cross-canadian-arm
"""
and then inspecting the lib32* manifest files under recipe-sysroot-native shows
them referencing lib32-recipe-sysroot instead of recipe-sysroot as used by
gcc-cross-canadian recipes.
To fix this separate out the manifest by multilib. It is caching mechanism to
optimise disk usage so this doesn't break anything, just separated out some files.
(From OE-Core rev: 29f7390add28d3a6fb6854bc750d1db3d969f027)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 891d3faa3ed3d1cc231da58e5fa1325f05d5ade5)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pkgconfig is being required to find dependencies for building kernel
native tools, move "inherit pkgconfig" to kernel.bbclass so BSP kernel
recipes can also benefit from it.
(From OE-Core rev: e09c50e01d0f5cf45b9622ab0ed33df12bdeb7ee)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 8a84bd98e3fbc16c782f83064801e469d086911e)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is needed when the SDK or eSDK is installed in a /build top level
directory as it conflicts with the build directory within the existing
/usr/src/debug/build (which is really a link). Rename it and then do the
copy, this is not an issue with master currently due to some other
changes that occurred in master.
Fixes: [YOCTO #15026]
(From OE-Core rev: 80839835ec9fcb63069289225a3c1af257ffdef7)
Signed-off-by: Saul Wold <saul.wold@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The use of scripts/git-intercept was introduced in commit 3266c327df
(install/devshell: Introduce git intercept script due to fakeroot
issues) and later reverted in commit af27c81eaf (scripts: Make git
intercept global).
(From OE-Core rev: 70ee5f9d50bec6e708cd2006c11ef3d0bd7cab42)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
(cherry picked from commit f6c260c8e2a33e282a35afc99de4ef8cc1791b08)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For the QA checks in `image.bbclass`, all exceptions
other than `oe.utils.ImageQAFailed` always print the
following generic message:
"Image QA function func_name failed"
This can be very misleading, as it may hide
python syntax errors and other kind of issues that are
hard to detect without more explicit error messages.
This change makes sure that the error message of all
exceptions are displayed.
Before this change:
"Image QA function func_name failed"
After this change:
"Image QA function func_name failed: f-string: empty expression not allowed (<string>, line 13)"
(From OE-Core rev: 6c53d8d8c88fb06b19fbf5bdd754960b21531074)
Signed-off-by: Mauro Queiros <maurofrqueiros@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 3d85b30d8704d38b86f5b006748cebc74bd2a4fa)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If on target locale generation is used, it fails at first boot showing
errors about a missing directory. Ensure the directory exists.
(From OE-Core rev: 258115c2a7d78f0416f952122c9448a805dab08f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f2844c9f1bbb729562063d96a3d1cc9d44dafa0a)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
older scons do not support MAXLINELENGTH and some packages still may be
using older scons, these recipes can clear SCONS_MAXLINELENGTH in them
and get going. Set
SCONS_MAXLINELENGTH = ""
in such recipes.
(From OE-Core rev: b4eaa248077305b75c551acb94223dbc524fc7a3)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 34de57d12c0a752f66c962d29e5335c1035db066)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps in overcoming a problem when using scons with ccache enabled.
When commands get longer, then it resorts to using response files to do
the operations e.g. @/tmp/tmp96j6icra.lnk when this response file is
inboked by compiler it works ok, however, this does not when ccache is
used to invoke the complilation. We see errors e.g.
ccache @/tmp/tmppsyij_0v.lnk
ccache: error: execute_noreturn of @/tmp/tmppsyij_0v.lnk failed: No such file or directory
Using MAXLINELENGTH setting ensures that we can use ARG_MAX to extend
the length of commandline and hence avoid using response files. This
issue is also reported in mongodb [1]
[1] https://jira.mongodb.org/browse/SERVER-38389
(From OE-Core rev: b0e7777a911e236bda76e90258098057ed355953)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 29558f6218f4676b459f2c78f82d245339d51c8c)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default return value from subprocess.check_output is an encoded byte.
The applied fix will decode the value to a string.
(From OE-Core rev: ffa1de16fa82fbe7dfbed4c5ae0fc4e6d51e7ff3)
Signed-off-by: Pawel Zalewski <pzalewski@thegoodpenguin.co.uk>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 046769fa952a511865c416b80d10af6287147fb7)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
