linux/poky.git/meta/classes, branch kirkstone-4.0.14

package_rpm: Allow compression mode override

2023-11-01T15:01:26+00:00

Commit 4a4d5f78a6962dda5f63e9891825c80a8a87bf66 ("package_rpm: use zstd instead of xz") changed the rpm package compressor from 'xz' to 'zstd' which results in decompression failure with BusyBox-provided 'rpm2cpio' applet and 'rpm' applet when given the '-i' (Install package) option: rpm2cpio: no gzip/bzip2/xz magic Introduce a variable which makes it possible to use a different compression mode, making it possible to override the default value for example like RPMBUILD_COMPMODE = "${@'w6T%d.xzdio' % int(d.getVar('XZ_THREADS'))}" to enable rpm decompression without including the full rpm package in the resulting root filesystem. (From OE-Core rev: a40d9258148e28cbee2168c93179cd4c1232fb62) (From OE-Core rev: ad4ea9f225b0dd6396088cc70b34f886c5fa62b4) Signed-off-by: Niko Mauno Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

uboot-extlinux-config.bbclass: fix missed override syntax migration

2023-10-21T15:21:36+00:00

uboot-extlinux-config allows to specify multiple "labels" (entries in a menu, à-la grub) and each of them have their own values for some fields. Each "base" variable, e.g. UBOOT_EXTLINUX_FDT can be overridden for each label. This is done via the OVERRIDES mechanism based on the label name, e.g. UBOOT_EXTLINUX_FDT:linux if linux is a label. However, OVERRIDES doesn't contain the label globally because it's only necessary in one task. Therefore, the OVERRIDES itself is modified within the task. This means that the sigdata will not be told the dependency on UBOOT_EXTLINUX_FDT:linux, because it cannot know about it. For this reason, we need to explicitly specify which variables this task depends on via vardeps varflag for the task. This was done in the past, but we missed updating it during the override syntax migration so the cache wouldn't get invalidated if someone modifies UBOOT_EXTLINUX_FDT:linux from a configuration file or a bbappend for example. Let's fix this by migrating it to the new syntax. (From OE-Core rev: 5570e49791b770271f176a4deeb5f6f1a028cb4a) Signed-off-by: Quentin Schulz Signed-off-by: Richard Purdie (cherry picked from commit b4dd9d873508128adbbf5ff6cf0a3df3d2ffbcf6) Signed-off-by: Steve Sakoman

fontcache.bbclass: avoid native recipes depending on target fontconfig

2023-10-06T01:48:49+00:00

* 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 Signed-off-by: Steve Sakoman

kernel.bbclass: Add force flag to rm calls

2023-09-30T19:43:59+00:00

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 Signed-off-by: Richard Purdie Signed-off-by: Alexander Sverdlin Signed-off-by: Steve Sakoman

cml1: Fix KCONFIG_CONFIG_COMMAND not conveyed fully in do_menuconfig

2023-09-30T19:43:59+00:00

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 Signed-off-by: Richard Purdie (cherry picked from commit d4664d2b7974354e73d891762ebb2c8a12d62438) Backported: File was renamed between kirkstone and master. Signed-off-by: Yoann Congal Signed-off-by: Steve Sakoman

cargo.bbclass: set up cargo environment in common do_compile

2023-09-23T15:26:16+00:00

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 Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit 9f4ff643a028d7f5670d80861f2ce19ca2d90faa) Signed-off-by: Steve Sakoman

externalsrc: fix dependency chain issues

2023-09-23T15:26:15+00:00

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 Signed-off-by: Richard Purdie (cherry picked from commit ee4667a24ccdd8c9d547e73aecf661e6a1283890) Signed-off-by: Steve Sakoman

kernel: Fix path comparison in kernel staging dir symlinking

2023-08-26T14:24:02+00:00

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 Signed-off-by: Alexandre Belloni (cherry picked from commit afd2038ef8a66a5e6433be31a14e1eb0d9f9a1d3) Signed-off-by: Steve Sakoman

npm.bbclass: avoid DeprecationWarning with new python

2023-08-19T15:56:59+00:00

meta/classes-recipe/npm.bbclass:85: DeprecationWarning: invalid escape sequence '\.' '--transform', 's,^\./,package/,', (From OE-Core rev: a7078ff976ba720f25e94ddeddd3f82900b483be) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

meson.bbclass: Point to llvm-config from native sysroot

2023-08-02T14:47:13+00:00

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 Signed-off-by: Richard Purdie (cherry picked from commit cc73360b9728812ed6123e30559b77d8e89cc21c) Signed-off-by: Steve Sakoman