summaryrefslogtreecommitdiffstats
path: root/meta/classes-recipe
Commit message (Collapse)AuthorAgeFilesLines
* lib/classes/recipes: refactor qemu.bbclass functions into library functionsChen Qi7 hours6-58/+18
| | | | | | | | | | | | | | | | | | | | Move the functions in qemu.bbclass to meta/lib/oe/qemu.py as they are generally useful. Add a deprecation notice in qemu.bbclass so that we can remove it in the future. The re-definition of qemu_wrapper_cmdline in allarch.bbclass is replaced by re-definition of the write_qemuwrapper function. We need to do this because we need to have the same signature across different machines for recipes inheriting both allarch and meson. Note that we cannot use vardepsexclude on oe.qemu.qemu_xxx functions conditionally in allarch.bbclass because python module functions currently do not support per-recipe vardepsexclude handling. (From OE-Core rev: ff11f77655b493fe8dfae36b484d516e630b89b5) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* image/populate_sdk.bbclass: drop qemuwrapper-cross from DEPENDSChen Qi7 hours2-2/+2
| | | | | | | | | | | | | | | | For packages that need qemuwrapper-cross, they should have it in PAKAGE_WRITE_DEPS. Now that we've used 'qemuwrapper-cross' to replace 'qemu-native' for recipes that need qemu-native for their postinsts, and we've now mapped PACKAGE_WRITE_DEPS for nativesdk recipes, these qemuwrapper-cross dependencies can be dropped from image.bbclass and populate_sdk.bbclass. (From OE-Core rev: 0bd6105628ccdcb8280b6701c276471f102ea4eb) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* nativesdk.bbclass: handle PACKAGE_WRITE_DEPSChen Qi7 hours1-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | We want nativesdk packages to depend on correct recipes introduced by PACKAGE_WRITE_DEPS, so do the same mapping just as we do for DEPENDS. Before this change: nativesdk-glib-2.0 -> qemuwrapper-cross After this change: nativesdk-glib-2.0 -> nativesdk-qemuwrapper-cross This can fix do_populate_sdk failure complaining missing of nativesdk-qemuwrapper. Error message is like below: NOTE: > Executing update_gio_module_cache-nativesdk intercept ... NOTE: Exit code 127. Output: /xxx/lib32-core-image-sato/1.0/intercept_scripts-xxxx/ update_gio_module_cache-nativesdk: 13: nativesdk-qemuwrapper: not found (From OE-Core rev: 0b87ad3d26a8ba585ffd460bc14ec1c793957c5c) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/recipes: remove unnecessary qemu inherit and use qemuwrapper-crossChen Qi7 hours5-12/+5
| | | | | | | | | | | | | | | These classes/recipes inherit qemu.bbclass but do not use anything from it. What they use is qemuwrapper-cross, which is needed at do_rootfs time and needs to be pulled-in by PACKAGE_WRITE_DEPS. Also, in meta/conf/layer.conf, exclude qemuwrapper-cross deps for all arch recipes that depend on it. This it ensure allarch recipes have the same signature across different machines. (From OE-Core rev: 2cfe34597dd49421e50a9157ac3b7d5456b3fb1e) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toolchain-scripts: Export meson settings for SDK buildsTom Hochstein7 hours1-1/+9
| | | | | | | | | | | | | | | | | | | Create a new set of exports for the Meson `host_machine` cross settings. This allows the target cross file to be created correctly from meson.cross.template and aligns with meson.bbclass. Note, one might think that HOST_OS and HOST_ARCH would be appropriate as inputs here, aligning nicely with the Meson naming. That turns out to be incorrect since the script is generated in a native/nativesdk build with HOST_OS and HOST_ARCH set for the "build machine", not the "host machine", using the Meson terminology. See https://mesonbuild.com/Cross-compilation.html. Fixes: [YOCTO #15485] (From OE-Core rev: aed3855aedce0e98ad07db78ec55c491c6153f30) Signed-off-by: Tom Hochstein <tom.hochstein@oss.nxp.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toolchain-scripts: Add Meson settings for Yocto build SDKTom Hochstein7 hours1-0/+2
| | | | | | | | | | The Meson settings for the standalone SDK also need to be available for the Yocto build SDK, a.k.a. meta-ide-support. (From OE-Core rev: 1647952e1691236eeb1145f2f78a966e860937e5) Signed-off-by: Tom Hochstein <tom.hochstein@oss.nxp.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uki.bbclass: drop serial console from kernel command lineMikko Rapeli4 days1-1/+1
| | | | | | | | | | | | | The kernel will continue using console from firmware which is much better on HW when we may not know at build time which console HW and drivers are available, e.g. like on genericarm64 machine. (From OE-Core rev: cf2ed52a94f5fa57cc6d93418dfb49b30e2240cc) Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes-recipe: npm: Complain immediately if npm-shrinkwrap.json is too oldMike Crowe11 days1-0/+3
| | | | | | | | | | | | | | | | | | | | | | Rather than emitting: Exception: KeyError: 'packages' and a stack trace, let's fail immediately if lockfileVersion implies that the npm-shrinkwrap.json file isn't compatible. The documentation[1] doesn't make it clear which lockfileVersions are guaranteed to contain "packages". I have lockfileVersion 1 files without. Running npm 7.5.2 generates npm-shrinkwrap.json files with lockfileVersion 2 and "packages", so I've set the minimum to be 2. [1] https://docs.npmjs.com/cli/v7/configuring-npm/package-lock-json (From OE-Core rev: 4d3cbd11bc9cc0bf5a8571ecd3ce6e5e5c6ef6eb) Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* rust: Upgrade 1.84.1->1.85.0Yash Shinde2025-04-011-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rust stable version updated to 1.85.0 https://blog.rust-lang.org/2025/02/20/Rust-1.85.0.html Some of the major updates: - Update LIC_FILES_CHKSUM in libstd-rs and rust recipes. License-Update: Unicode license text is updated to Unicode-3.0 License. https://github.com/rust-lang/rust/commit/6d2a3e9786ec43a0e0af20386e7046328296ac86 [RP: Update LICENSE to reference Unicode-3.0] - Pass '-Zforce-unstable-if-unmarked' to RUSTFLAGS in libstd-rs.bb Fix: https://github.com/rust-lang/rust/issues/133857#issuecomment-2526341227 - Downgrade bootstrap cc version causing bootstrap to fail on custom targets. (Backported from v1.85.1) Fix: https://github.com/rust-lang/rust/pull/137460/commits/e4ca11f87ffca8c63aa56d45b46e62b6acc58bd7 - Explicitly set float ABI for all ARM 32 bits targets. Fix: https://github.com/rust-lang/rust/commit/a51fefcaab835b310e2e26005b50982d0049d905 - Rust v1.85.0 tarball doesn't ship gcc tree. Drop "remove_gcc_directory" postfunc which removed it and prevented the bloat. Fix: https://github.com/rust-lang/rust/commit/13c3f9b9498013837782b46120085ea19ca75518 Adapted the patch changes with v1.85.0: repro-issue-fix-with-cc-crate-hashmap.patch revert-link-std-statically-in-rustc_driver-feature.patch rust-oe-selftest.patch rv32-cargo-rustix-0.38.40-fix.patch Dropped patches: fix-tidy-check-failure.patch since it's merged with v1.85.0. (From OE-Core rev: 3130069fdebb92f20b962fa8074564a27c3fb6b9) Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cargo.bbclass: show PACKAGECONFIG_CONFARGS in bbnoteMartin Jansa2025-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | * PACKAGECONFIG_CONFARGS was added in: https://git.openembedded.org/openembedded-core/commit/?id=16745b20452de60ae2474433cc1a2fb1ed9f6a64 but it wasn't added in bbnote above which might lead to confusing errors like I got now: NOTE: cargo build -v --frozen --target aarch64-webos-linux-gnu --release --manifest-path=.../git//Cargo.toml error: unexpected argument '--cfg' found Usage: cargo build --verbose... --frozen --target [<TRIPLE>] --release --manifest-path <PATH> and was wondering where --cfg came from. * it was from recipe where we already use: RUSTFLAGS:append = " ${PACKAGECONFIG_CONFARGS}" it will be difficult to use PACKAGECONFIG for RUSTFLAGS and prevent them to be used here for cargo as well, what about the recipes which need them to explicitly append them to CARGO_BUILD_FLAGS ? (From OE-Core rev: 38d953b2ffd4e0cee9e77f97988e44be105023c6) Signed-off-by: Martin Jansa <martin.jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cargo: pass PACKAGECONFIG_CONFARGS to cargo buildJean-Pierre Geslin2025-03-201-1/+1
| | | | | | | | | | | | In order to allow rust packages to define PACKAGECONFIG options, append the contents of PACKAGECONFIG_CONFARGS to the build command. This patch was already submitted by Bartosz Golaszewski on older version but was never merged. It will be really usefull for Rust recipes. (From OE-Core rev: 16745b20452de60ae2474433cc1a2fb1ed9f6a64) Signed-off-by: Jean-Pierre Geslin <jarsoper@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* autotools: require that a configure script existsRoss Burton2025-03-181-5/+2
| | | | | | | | | | There's no point inheriting autotools if you're not actually going to run a configure script, so make a missing configure script fatal. (From OE-Core rev: 6d327a39befae44a88a812bdf4acde800dcee57b) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* native: Drop export statements that aren't neededRichard Purdie2025-03-181-14/+14
| | | | | | | | These are already exported by bitbake.conf, no need to export them again. (From OE-Core rev: 92e52f5afac4877366c1ee2e6c6f0d1f5df84410) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* native: follow BUILD_* definitions for OBJCOPY, OBJDUMP and READELFAntonin Godard2025-03-181-0/+3
| | | | | | | | | | | | | | Set the host OBJCOPY, OBJDUMP, and READELF variables to be derived from their corresponding BUILD_* definitions. This makes the native class match the build-gcc.inc file 1 to 1, as these were the only missing. Currently these variables get their definitions from gcc.inc, which uses HOST_PREFIX, and that works because the native class sets HOST_PREFIX to BUILD_PREFIX, but this doesn't seem correct. (From OE-Core rev: 87a6ffe21b706e6aeeeb77891565cbd7730ca163) Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uboot, kernel: use hex address for UBOOT_ENTRYPOINTAdrian Freihofer2025-03-112-2/+2
| | | | | | | | | | | | | | | | | | Compiling a FIT image with this default values and dump it with dumpimage shows decimal converted values. For example the default value 20008000 looks like this: Image 0 (kernel-1) ... Load Address: 0x01314c40 Entry Point: 0x01314c40 With this change the expected value is printed by dumpimage. (From OE-Core rev: e6f2ca9135ef7da8f8b5925957532734c06e55cc) Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-fitimage: sign setup sectionsAdrian Freihofer2025-03-111-0/+13
| | | | | | | | | | | | | | | | | | If FIT_SIGN_INDIVIDUAL is set to “1”, a signature section is added to all screen sections, but not to the setup section. To match the setup section with all other sections, the signature is also added. This also helps to implement the associated tests generically. This change is intended to make the code more consistent. However, it is not intended to make the FIT_SIGN_INDIVIDUAL function more popular. Technically, it would be better to remove the signature from all other image sections and discard the FIT_SIGN_INDIVIDUAL function, the use of which is no longer recommended anyway. (From OE-Core rev: 8bf6a9c07cdde8fc8bbd4bb61a4886ccc02a570f) Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes-recipe: Consolidate machine-id handlingVyacheslav Yurkov2025-03-092-15/+19
| | | | | | | | | | | | Whenever Systemd is used as an init manager, it requires a machine-id file to be present / initialized / or have the RW rootfs. This change does not introduce a new functionality, but rather merges everything we do with machine-id in one place. (From OE-Core rev: 890b81cdfadc427189eff4bbd2c24e32eb286126) Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: remove whitespaceVictor J. Hansen2025-03-081-1/+1
| | | | | | | (From OE-Core rev: 219c7c4954c649a1a0c284bb5f35eee533db41c3) Signed-off-by: Victor J. Hansen <victor.hansen@remarkable.no> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-arch: add macro-prefix-map in KERNEL_CCStefan Mueller-Klieser2025-03-081-1/+7
| | | | | | | | | | | | | | | When building external modules, macros can include absolute names of kernel headers. The macro-prefix-map for the STAGING_KERNEL_DIR is currently missing. Add it in the same way as its done in bitbake.conf. This fixes reproducible builds and following build error: ERROR: cryptodev-module-1.14-r0 do_package_qa: QA Issue: File <..> cryptodev.ko <..> contains reference to TMPDIR [buildpaths] (From OE-Core rev: a741e11751bfb8f52be58cf51abeddca4559e5e9) Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* go: Check if GO_IMPORT is set in recipe and error if notChristos Gavros2025-03-031-0/+3
| | | | | | | | | | | | | | | | | | | | Check if the variable GO_IMPORT is set in the recipe. If not generate an error. Test building go-helloworld when GO_IMPORT assigned Test building go-helloworld when GO_IMPORT is not assigned, generate error about GO_IMPORT Test building any other recipe(e.g bash) when GO_IMPORT is not assigned, generate error about GO_IMPORT Test creating a GO recipe with recipetool (not affected) Test selftest test_recipetool_create_go (not affected) Test selftest test_recipetool_create_go_replace_modules (not affected) [YOCTO #15763] CC: Yoann Congal <yoann.congal@smile.fr> CC: Randy MacLeod <randy.macleod@windriver.com> (From OE-Core rev: 374a91204bdaf44067f6b0ae89ed60934751efaa) Signed-off-by: Christos Gavros <gavrosc@yahoo.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* go: remove support for GOROOT_FINALHongxu Jia2025-03-031-1/+0
| | | | | | | | | | | | | | | | | After upstream go applied commit [cmd: remove support for GOROOT_FINAL][1], GOROOT_FINAL variable is dropped and use option -trimpath to instead [2] The option -trimpath has already been added to GOBUILDFLAGS in go.bbclass [1] https://github.com/golang/go/commit/507d1b22f4b58ac68841582d0c2c0ab6b20e5a98 [2] https://github.com/golang/go/issues/62047 (From OE-Core rev: 791ab77ac05f658ecd61525a3d9b1afaf8ac6e06) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cml1.bbclass: use consistent make flags for menuconfigEnrico Jörns2025-03-032-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The class called 'make menuconfig' without any of the make variables and options set in EXTRA_OEMAKE, resulting in a quite different build environment than actually intended. For the kernel.bbclass this was fixed in commit 8c616bc0 ("kernel: Use consistent make flags for menuconfig") by appending ${EXTRA_OEMAKE} to KCONFIG_CONFIG_COMMAND. Instead of fixing this individually for additional recipes, we simply include ${EXTRA_OEMAKE} in KCONFIG_CONFIG_COMMAND by default. For most class users, this change is directly visible in the generated .config file: * For barebox and u-boot, the CONFIG_GCC_VERSION erroneously reflected the host GCC version before where it now correctly reflects the target toolchain's GCC. * For u-boot, also the "Compiler: " line at the beginning of the .config now prints the target toolchain instead of the host ones. * The kernel had this already set. * busybox did not produce any difference. Note that these projects might base some compile-time decisions on e.g. the actual compiler version used. Having the wrong one in the menuconfig-generated .config affects at least the visibility and consistency. Reported-by: Ulrich Ölmann <u.oelmann@pengutronix.de> (From OE-Core rev: 1b6ddd452837e67b500a84455a234f5edc8250a9) Signed-off-by: Enrico Jörns <ejo@pengutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uboot-sign: support to add users specific image tree sourceJamin Lin2025-02-271-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, uboot-sign.bbclass only supports to create Image Tree Source(ITS) for "u-boot" and "flat_dt". However, users may want to add their private images into u-boot FIT image for specific application and purpose. To make this bbclass more flexible and support to add users specific snippet ITS, creates a new "UBOOT_FIT_USER_SETTINGS" variable. Users can add their specific snippet ITS into this variable. Example: ``` UBOOT_FIT_MY_ITS = '\ myfw {\n\ description = \"MY Firmware\";\n\ data = /incbin/(\"myfw.bin\");\n\ type = \"mytype\";\n\ arch = \"myarch\";\n\ os = \"myos\";\n\ load = <0xb2000000>;\n\ entry = <0xb2000000>;\n\ compression = \"none\";\n\ };\n\ ' UBOOT_FIT_USER_SETTINGS = "${UBOOT_FIT_MY_ITS}" ``` The generated ITS ``` myfw { description = "My Firmware"; data = /incbin/("myfw.bin"); type = "mytype"; arch = "myarch"; os = "myos"; load = <0xb2000000>; entry = <0xb2000000>; compression = "none"; }; ``` Add a variable "UBOOT_FIT_CONF_USER_LOADABLES" to load users specific images and it is an empty by default. (From OE-Core rev: c12e013453689697a8680f1c7de3e625a0ff28ec) Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uboot-sign: support to create TEE and ATF image tree sourceJamin Lin2025-02-271-1/+79
| | | | | | | | | | | | | | | | | | | | | | | Currently, uboot-sign.bbclass only supports to create Image Tree Source(ITS) for "u-boot" and "flat_dt". However, users may want to support multiple images such as ARM Trusted Firmware(ATF), Trusted Execution Environment(TEE) and users private images for specific application and purpose. To make this bbclass more flexible and support ATF and TEE, creates new functions which are "uboot_fitimage_atf" and "uboot_fitimage_tee" for ATF and TEE ITS file creation, respectively. Add a variable "UBOOT_FIT_ARM_TRUSTED_FIRMWARE" to enable ATF ITS generation and it is disable by default. Add a variable "UBOOT_FIT_TEE" to enable TEE ITS generation and it is disable by default. (From OE-Core rev: c14641a964b5b802e995e574a599c5b4937fb488) Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cml1.bbclass: do not escape the exit valueSven Kalmbach2025-02-271-1/+1
| | | | | | | | | | | Remove incorrectly escaped exit value, which causes error handling logic not to run. [YOCTO #15731] (From OE-Core rev: 5c44a9154f0cd4252d4840d836e6936393b5d3a3) Signed-off-by: Sven Kalmbach <Sven.Kalmbach@loewensteinmedical.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* autotools: don't try and find in-tree macrosRoss Burton2025-02-271-12/+2
| | | | | | | | | | | | | | | | | | | | autotools has improved a lot since this class was written, and there's now no need to search the source tree for m4 files and add them to the include path. If packages have macros in subdirectories the idiom is to tell aclocal via an assignment in Makefile.am: ACLOCAL_AMFLAGS = -I gl/m4 -I m4 If, for example, a package isn't autoreconfable out of the box (because it has a non-trivial autogen.sh or similar, say) then the required -I statements can be added to EXTRA_AUTORECONF. (From OE-Core rev: e718d1be2c4fb54cf363c23f929358e1be68c724) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* u-boot: kernel-fitimage: Restore FIT_SIGN_INDIVIDUAL="1" behaviorMarek Vasut2025-02-251-9/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | OE FIT_SIGN_INDIVIDUAL is implemented in an unusual manner, where the resulting signed fitImage contains both signed images and signed configurations, possibly using different keys. This kind of signing of images is redundant, but so is the behavior of FIT_SIGN_INDIVIDUAL="1" and that is here to stay. Adjust the process of public key insertion into u-boot.dtb such that if FIT_SIGN_INDIVIDUAL==1, the image signing key is inserted into u-boot.dtb first, and in any case the configuration signing key is inserted into u-boot.dtb last. The verification of the keys inserted into u-boot.dtb against unused.itb is performed only for FIT_SIGN_INDIVIDUAL!=1 due to mkimage limitation, which does not allow mkimage -f auto-conf to update the generated unused.itb, and instead rewrites it. Fixes: 259bfa86f384 ("u-boot: kernel-fitimage: Fix dependency loop if UBOOT_SIGN_ENABLE and UBOOT_ENV enabled") (From OE-Core rev: 0106e5efab99c8016836a2ab71e2327ce58a9a9d) Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cargo_common: use 'config.toml' instead of plain 'config'Enrico Scholz2025-02-251-10/+10
| | | | | | | | | | | | | | | | | | | cargo configuration has been renamed from plain 'config' to 'config.toml' in rust-1.38. Using the old name is still supported but creates warnings like | $ cargo | warning: `/sdk.../home/cargo/config` is deprecated in favor of `config.toml` | note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml` Use the new name. (From OE-Core rev: 94b7d1a6cdb44949f8a96213ff2e45fafd759442) Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: Handle possible multiconfig.Sebastian Zenker2025-02-251-1/+1
| | | | | | | | | | | When specifying the dependencies of do_bundle_initramfs the current multiconfig might not be the default. This fixes the dependencies between the multiconfigs if the current differs to default. (From OE-Core rev: 2e40466af83a3c66aef878e3f08a891405199ebe) Signed-off-by: Mueller, Daniel <daniel.mueller@karlstorz.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* setuptools3-base.bbclass: override default subprocess timeoutHongxu Jia2025-02-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The environment variable SETUPTOOLS_SCM_SUBPROCESS_TIMEOUT allows to override the subprocess timeout. The default is 40 seconds and should work for most needs.[1] However, it was not enough while using git shallow tarball and starting multiple Yocto world builds in one host. |   File "tmp/work/x86_64-linux/python3-scancode-native/32.1.0/recipe-sysroot- native/usr/lib/python3.13/subprocess.py", line 1263, in _check_timeout |     raise TimeoutExpired( |     ...<2 lines>... |             stderr=b''.join(stderr_seq) if stderr_seq else None) | subprocess.TimeoutExpired: Command '['git', '--git-dir', 'tmp/work/x86_64- linux/python3-scancode-native/32.1.0/git/.git', 'status', '--porcelain', '--untracked-files=no']' timed out after 40 seconds Explicitly set variable SETUPTOOLS_SCM_SUBPROCESS_TIMEOUT to 600s in bbclass, and we could override it in local.conf [1] https://github.com/pypa/setuptools-scm/blob/main/docs/overrides.md (From OE-Core rev: a3a2edbf7139b7f8c665c2b0b13e094a334e4441) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meson.bbclass: Add an option to specify install tagsVyacheslav Yurkov2025-02-111-1/+7
| | | | | | | | | | The feature is available since meson 0.60.0. You can specify comma-separated list of install tags (not targets). (From OE-Core rev: a61ec67cb6f240c7593c9dd1b9a1ef5fff87c855) Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-fitImage: Remove dependeny on initramfs image when bundled.Weisser, Pascal.ext2025-02-111-1/+1
| | | | | | | | | | | | In case the initramfs image is bundled into the kernel there's no need to specify a dependeny on the do_image_complete task of the initramfs image from the do_assemble_fitimage_initramfs task since the task won't access the image. (From OE-Core rev: af6cde746f72be761550ee28b017719fba26ea65) Signed-off-by: Weisser, Pascal <pascal.weisser.ext@karlstorz.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-fitImage: Take possible multiconfig into account.Weisser, Pascal.ext2025-02-111-2/+6
| | | | | | | | | | | | | | When specifying the dependencies of do_assemble_fitimage_initramfs the initramfs image might be built with another multiconfig. This needs to be taken into account. The path of the initramfs image also needs to be adapted to handle the case when it's built with another multiconfig. (From OE-Core rev: 891d58e9dc00e52f17ddecd4f12fc81c8a3c1bce) Signed-off-by: Weisser, Pascal <pascal.weisser.ext@karlstorz.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-fitimage.bbclass: do not use the UBOOT_ENV variableAdrian Freihofer2025-02-111-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel-fitimage.bbclass evaluates the UBOOT_ENV variable from the u-boot recipe. Based on this variable an u-boot script might be added to the fitImage. However, the UBOOT_ENV variable is also used to install the script as an old u-boot image, usually named boot.scr into the /boot directory of the target device. This dual usage of one variable leads to several strange side effects. Some examples: - If UBOOT_ENV_SUFFIX is set to the default value scr, the boot.cmd script gets added as a legacy uImage to the fitImage. That does not look useful. - If the UBOOT_ENV_SUFFIX is set to e.g. txt the script is not converted into a legacy uImage and a usable plain text script gets added to the fitImage. But the same script ends up redundant in /boot. Another strange detail is that the UBOOT_ENV_BINARY gets set to e.g. boot.txt for this configuration. - Appending the script to the u-boot recipe and then hand it over to the kernel recipe via the staged /boot directory looks like over complicated. Such kind of over complications and u-boot kernel inter-dependencies lead to an almost unmaintainable kernel-fitimage.bbclass. - A single variable does not allow you to add a text file to the fitImage and at the same time place boot.scr file in the /boot directory of the target device. - It is not documented or obvious how the UBOOT_ENV variable should be used together with the kernel-fitimage.bbclass. The commit which introduced this feature (among other features...) is: https://git.yoctoproject.org/poky/commit/?id=8a2f4e143b52109fbd0ee8d792e327d460b8c1e6 This commit is going to remove the u-boot script part of it. The removal of this function requires a note in the migration guide. The migration should be straightforward: If UBOOT_ENV and the kernel-fitimage.bbclass are used, the u-boot script must now be appended to the kernel recipe and the new FIT_UBOOT_ENV variable must be used. (From OE-Core rev: ab7f0b5e3d3612c43f9aab9ea2b7bd554d02859d) 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>
* kernel-fitimage.bbclass: introduce FIT_UBOOT_ENVAdrian Freihofer2025-02-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new variable FIT_UBOOT_ENV, which allows to add a u-boot script as a text file to the fitImage. Such a script can be sourced from the u-boot shell, as documented here: https://docs.u-boot.org/en/latest/usage/cmd/source.html#fit-image The kernel-fitimage.bbclass also evaluates the existing UBOOT_ENV variable and adds the corresponding script to the fitImage. However, the UBOOT_ENV variable is also used to install the script as an old u-boot image, usually named boot.scr into the /boot directory of the target device. These are different use cases which should be handled independently. Appending the script to the u-boot recipe and then hand it over to the kernel recipe via the staged /boot directory leads to complicated task dependencies. Decoupling the two use cases will also allow to simplify the implementation by dropping the evaluation of the UBOOT_ENV variable in the kernel-fitimage.bbclass. But this commit is supposed to be backward compatible. (From OE-Core rev: 269605ed053fd8dc7bcbcc04a46c308188115f66) 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>
* cmake: apply parallel build settings to ptest tasksPeter Marko2025-02-101-0/+2
| | | | | | | | | | | | | | | ptest compile and install tasks do not have parallel build settings for cmake. On powerful build machines this can cause overload situations and oomkills. Observed when building qtgrpc with ptest generally enabled in distro. Having this in ptest class is suboptimal, but creating ptest-cmake class just for these two variables is probably overkill. (From OE-Core rev: 3c311fbf0c2090268e9b83123d762b05b61b4074) Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uki.bbclass: remove duplicate d.getVar('DEPLOY_DIR_IMAGE')Koen Kooi2025-02-101-2/+0
| | | | | | | | | | | This class calls d.getVar('DEPLOY_DIR_IMAGE') twice within the same method, but DEPLOY_DIR_IMAGE variable won't change during the run of this class, so only retrieve it once. (From OE-Core rev: 6866da9f3a273ed7217e9edfca299fc2e68b2f75) Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uki.bbclass: capture ukify command stdout and stderrMikko Rapeli2025-02-101-1/+2
| | | | | | | | | | ukify tool can show important warnings and even errors if it fails so capture the logs. (From OE-Core rev: 6ac326a4f9d19fa154c9ce172a264f55ebe5b1ef) Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uboot-config: Fix devtool modifyTom Hochstein2025-02-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a problem with `devtool modify` as suggested by Marcus Flyckt on the mailing list: ``` I encountered an issue with `do_config` when using `devtool modify` on `u-boot-imx`. ``` [...] | cp: cannot stat '[...]/u-boot-imx/2024.04/build/imx8mp_wl400s_defconfig/.config': No such file or directory | WARNING: exit code 1 from a shell command. ERROR: Task ([...]/sources/poky/../meta-freescale/recipes-bsp/u-boot/u-boot-imx_2024.04.bb:do_configure) failed with exit code '1' NOTE: Tasks Summary: Attempted 963 tasks of which 962 didn't need to be rerun and 1 failed. Summary: 1 task failed: [...]/sources/poky/../meta-freescale/recipes-bsp/u-boot/u-boot-imx_2024.04.bb:do_configure Summary: There was 1 ERROR message, returning a non-zero exit code ``` The issue seems to originate from the following lines in `workspace/appends/u-boot-imx_2024.04.bbappend`: ``` do_configure:append() { if [ ${@oe.types.boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG"))} = True ]; then cp ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.baseline ln -sfT ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.new fi } ``` For some reason `KCONFIG_CONFIG_ROOTDIR` does not point to the correct directory. It gets its value in `uboot-config.bbclass`: ``` if len(ubootconfig) == 1: d.setVar('KCONFIG_CONFIG_ROOTDIR', os.path.join(d.getVar("B"), d.getVar("UBOOT_MACHINE").strip())) ``` So the main issue is that B gets expanded in this expression, and then later B gets changed by `externalsrc.bbclass`. `d.getVar("B", False)` does not solve the issue, however the proposed change does. ``` - https://lists.yoctoproject.org/g/yocto/topic/109254298#msg64152] Fixes [YOCTO #15603] Suggested-by: Marcus Flyckt <marcus.flyckt@gmail.com> (From OE-Core rev: 57b21065a25100c31515b32fd7c77bde3355d684) Signed-off-by: Tom Hochstein <tom.hochstein@oss.nxp.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes: switch p7zip to 7zipPeter Marko2025-02-102-2/+2
| | | | | | | | | | | | meta-oe has switched from p7zip to 7zip. p7zip recipe does not exist anymore and p7zip is provided and rprovided by 7zip recipe. Use real provider instead of replaced one. (From OE-Core rev: 5aa516bfa295d5be919459dfe45f452cdec45e81) Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* testimage.bbclass: fix logDetails() call on error pathMikko Rapeli2025-02-051-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This happens when testimage task runs and bitbake is interupted twice with ctrl-c/SIGINT: QMP Available for connection at /home/builder/src/base/repo/meta-arm/build/tmp/.xjik9srq QMP connected to QEMU at 01/31/25 10:36:19 and took 0.55 seconds QMP released QEMU at 01/31/25 10:36:19 and took 0.07 seconds from connect Keyboard Interrupt, closing down... Second Keyboard Interrupt, stopping... WARNING: Exiting due to interrupt. NOTE: Sending SIGTERM to remaining 1 tasks ERROR: core-image-base-1.0-r0 do_testimage: testimage interrupted, shutting down... Output from runqemu: runqemu - INFO - Received signal: 15 runqemu - INFO - Cleaning up runqemu - INFO - Host uptime: 6230788.40 tput: No value for $TERM and no -T specified ERROR: core-image-base-1.0-r0 do_testimage: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: <module> 0001: *** 0002:do_testimage(d) 0003: File: '/home/builder/src/base/repo/meta-arm/build/../poky/meta/classes-recipe/testimage.bbclass', lineno: 122, function: do_testimage 0118: dump-guest-memory {"paging":false,"protocol":"file:%s.img"} 0119:} 0120: 0121:python do_testimage() { *** 0122: testimage_main(d) 0123:} 0124: 0125:addtask testimage 0126:do_testimage[nostamp] = "1" File: '/home/builder/src/base/repo/meta-arm/build/../poky/meta/classes-recipe/testimage.bbclass', lineno: 389, function: testimage_main 0385: 0386: # Show results (if we have them) 0387: if results: 0388: configuration = get_testimage_configuration(d, 'runtime', machine) *** 0389: results.logDetails(get_json_result_dir(d), 0390: configuration, 0391: get_testimage_result_id(configuration), 0392: dump_streams=d.getVar('TESTREPORT_FULLLOGS')) 0393: results.logSummary(pn) Exception: AttributeError: 'TestResult' object has no attribute 'logDetails' ERROR: Logfile of failure stored in: /home/builder/src/base/repo/meta-arm/build/tmp/work/qemuarm64_secureboot-poky-linux/core-image-base/1.0/temp/log.do_testimage.2771735 Summary: 1 task failed: /home/builder/src/base/repo/meta-arm/build/../poky/meta/recipes-core/images/core-image-base.bb:do_testimage (From OE-Core rev: c0d864a7007adbdf332da62e89c73630b3e01639) Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta/meta-selftest: Fix variable assignment whitespaceRichard Purdie2025-02-0110-21/+21
| | | | | | | | | | Recipes are much more readable with whitespace around the assignment operators. Fix various assignments in OE-Core to show this is definitely the preferred formatting. (From OE-Core rev: 30ea609d3357fb3de911f2f6a5e6856c151b976a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* rust-common.bbclass: soft assignment for RUSTLIB pathPedro Ferreira2025-02-011-1/+1
| | | | | | | | | | | | | | | | | | | | | As a user i want to override `RUSTLIB` path on a bbclass, lets call it `XYZ.bbclass`. If a certain recipe inherits `cargo.bbclass` and `XYZ.bbclass` the value of `RUSTLIB` is dependent on the order of the inherit. If `cargo.bbclass` is inherit before `XYZ.bbclass` this will reflect the desired value of `RUSTLIB`, on the oposite, if the `XYZ.bbclass` is inherit before `cargo.bbclass` then the `RUSTLIB` defined on `rust-common.bbclass` will prevail. Changed definition of `RUSTLIB` to soft assignment to make it overridable. (From OE-Core rev: 6eeb832f73ffb48f5f05dc47191f60e4599e640f) Signed-off-by: Pedro Silva Ferreira <Pedro.Silva.Ferreira@criticaltechworks.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-yocto: move the cp of ${KBUILD_DEFCONFIG} file outside if bodySlawomir Stepien2025-01-271-7/+1
| | | | | | | | | | | | In both true/false cases, we will cp the file, so move the invocation after the if body. In addition, misleading comment has been removed. (From OE-Core rev: fdd7fec29314b3cd07a98943bbbf6996877e90f4) Signed-off-by: Slawomir Stepien <sst@poczta.fm> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Handle empty BB_CURRENT_MCRichard Purdie2025-01-251-1/+1
| | | | | | | | | | | | | | | | | | | 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>
* rust-common: add LDFLAGS to 'build-rust-cc' wrapperEnrico Scholz2025-01-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although rust differs between compiling (--> 'rust-cc' wrapper) and linking (--> 'rust-ccld' wrapper), some core crates are using only the 'rust-cc' wrapper to check for available compiler options [1] and libraries [2]. Not having LDFLAGS can break the build in subtle ways. E.g. 'cargo-native' can fail to build with | = note: .../hosttools/ld: .../liblibz_sys-....rlib(deflate.o): | relocation R_X86_64_32S against hidden symbol `_length_code' can not be used when making a PIE object because it does not find '-lz' (added by "DEPENDS = zlib") and builds a static libz.a with missing PIC flags. Add LDFLAGS to the 'build-rust-cc' wrapper as it is done already for the target one. [1] https://github.com/rust-lang/cc-rs/pull/1322 [2] https://github.com/rust-lang/libz-sys/blob/12a32798c6bd18986cb5cd603359b03c96f0eb4c/build.rs#L228-L234 (From OE-Core rev: 49b37575b548f0ab082c700f91fdd856740dc829) Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Ross Burton <ross.burton@arm.com>
* u-boot: kernel-fitimage: Fix dependency loop if UBOOT_SIGN_ENABLE and ↵Marek Vasut2025-01-222-64/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | UBOOT_ENV enabled 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 Fixes: 5e12dc911d0c ("u-boot: Rework signing to remove interdependencies") Reviewed-by: Adrian Freihofer <adrian.freihofer@siemens.com> (From OE-Core rev: 259bfa86f384206f0d0a96a5b84887186c5f689e) Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/recipes: Switch virtual/XXX-gcc to virtual/cross-cc (and c++/binutils)Richard Purdie2025-01-214-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The idea of the base class dependency is to say "yes, I need a C cross compiler" and this was never meant to be gcc specific. Looking at the codebase, whilst we code triplets into this, it does overcomplicate things as there are only ever limited, "target", "sdk" and the class extended versions like mutlilib. After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc. This lets us remove the "gcc" specific element as well as removing the over complicated triplet usage. At the same time, change the much less widely used "g++" variant to "c++" for similar reasons and remove the triplet from virtual/XXX-binutils too. Backwards compatibility mappings could be left but are just going to confuse things in future so we'll just require users to update. This simplification, whilst disruptive for any toolchain focused layers, will make improved toolchain selection in the future much easier. Since we no longer have overlapping variables, some code for that can just be removed. The class extension code does need to start remapping some variables but not the crosssdk target recipe names. This patch is in two pieces, this one handles the renaming with the functional changes separate in a second for easier review even if this breaks bisection. (From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-yocto: make kernel commits reproducibleEnrico Jörns2025-01-211-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The git commit hashes for the kernel checkout are not reproducible under certain conditions: - If the git repository is initialized on an archive (rather than a git), the initial git commit not only has the current user name set, it also uses the current system time as committer and author date. This will affect the initial git hash and thus all subsequent ones. - The patches applied by the kern-tools have a valid author and date. However, their committer again depends on the user building the BSP. This is an issue, for example, if one compiles a kernel with CONFIG_LOCALVERSION_AUTO enabled where the commit hash lands into the kernel and thus the package version. This not only makes the package version non-reproducible, but also leads to version mismatches between kernel modules built against a fresh kernel checkout and the kernel retrieved from the sstate cache. The class uses 'check_git_config' from utils.bbclass, but this only sets the git user and only if none existed before. Thus it doesn't really help here. Since in Git the committer information can be set only from the environment variables GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, and GIT_COMMITTER_DATE, we introduce a helper function to set those and apply the author settings in the same way. As values simply use PATCH_GIT_USER_NAME, PATCH_GIT_USER_EMAIL (from patch.bbclass) and SOURCE_DATE_EPOCH. For convenience, put the new helper 'reproducible_git_committer_author' into utils.bbclass next to 'check_git_config' so others can use it, too. Using this helper in kernel-yocto.bbclass makes the committer and author date/name/email for the initial commit reproducible, as well as the committer name/email for the patches applied with kern-tools. For debugging purpose, allow disabling the reproducibility features by setting KERNEL_DEBUG_TIMESTAMPS to "1". Suggested-by: Felix Klöckner <F.Kloeckner@weinmann-emt.de> (From OE-Core rev: aab4517b4649917abd519ea85a20fd9d51bf3d99) Signed-off-by: Enrico Jörns <ejo@pengutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* image.bbclass: enable systemd user servicesArtur Kowalski2025-01-211-0/+1
| | | | | | | | | | Run systemctl preset-all with --global flag so user unit's are enabled the same way system units are. (From OE-Core rev: cdc3b3028f6d71788b5fdd99436f69fbf18f613e) Signed-off-by: Artur Kowalski <arturkow2000@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2025-04-21 19:11:54 +0000