linux/poky.git/meta/classes-global, branch 5.2_M2

classes/recipes: Switch virtual/XXX-gcc to virtual/cross-cc (and c++/binutils)

2025-01-21T23:09:33+00:00

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

kernel-yocto: make kernel commits reproducible

2025-01-21T13:26:07+00:00

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 (From OE-Core rev: aab4517b4649917abd519ea85a20fd9d51bf3d99) Signed-off-by: Enrico Jörns Signed-off-by: Richard Purdie

classes/logging: Added the bbverbnote command to the logging set

2025-01-20T13:38:59+00:00

Fixes [YOCTO #15688] Reviewed-by: Yoann Congal (From OE-Core rev: 48e4b8c06e503868404b99bf45a46a52794baa5a) Signed-off-by: Bastien JAUNY Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

sstate: Ensure errors cause task failure

2025-01-08T12:37:20+00:00

(From OE-Core rev: c1491ef7afc8722927c568b0ac0ddbbc84837ca3) Signed-off-by: Richard Purdie

package_rpm: set a timestamp handling policy with the new macro %build_mtime_policy

2025-01-04T12:34:04+00:00

There is the following warning when the do_package_write_rpm task is executed when bitbake linux-yocto: warning: %clamp_mtime_to_source_date_epoch is deprecated, please use %build_mtime_policy After RPM is upgraded to 4.20.0, the %clamp_mtime_to_source_date_epoch macro is now deprecated in favor of %build_mtime_policy set to clamp_to_source_date_epoch. (From OE-Core rev: fa9b9e599bbf3ac73c7a9b1d15ccb0e0bbbe4c11) Signed-off-by: Bin Lan Signed-off-by: Richard Purdie

sanity.bbclass: Lower the length of TMPDIR limit to 400

2025-01-03T11:05:03+00:00

When TMPDIR has length 410, bitbake uninative-tarball will fail at do_populate_sdk with error: Failed to open backup database: "TMPDIR/work/x86_64-nativesdk-pokysdk-linux/uninative-tarball/1.0/sdk/image/var/lib/dnf/history.sqlite" sqlite3 has a hardcode max pathname limit 512, refer [1], and there is a check, refer [2], pathname + 8 > max path name limit(512) is not allowed. So the pathname length need to <= 504. While, length of "TMPDIR/work/x86_64-nativesdk-pokysdk-linux/uninative-tarball/1.0/sdk/image/var/lib/dnf/history.sqlite" is 505, so error happened. We had met similar issue [3], and refer the comments, upstream reject the change of the hardcode length, see [4][5]. This patch try to improve and workaround this issue by lower max TMPDIR length to 400, at least for distro name length <=13, the build can success. [1] https://github.com/sqlite/sqlite/blob/master/src/os_unix.c#L180 [2] https://github.com/sqlite/sqlite/blob/master/src/pager.c#L4777 [3] https://bugzilla.yoctoproject.org/show_bug.cgi?id=12374 [4] https://sqlite.org/cgi/src/tktview/c060923a5422590b3734 [5] https://sqlite.org/forum/forumpost/0b1b8b5116 (From OE-Core rev: da1c0998bdaf5def7ae94f44a33b9a505edc99c1) Signed-off-by: Changqing Li Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

base/features_check: Make PARSE_ALL_RECIPES and SOURCE_MIRROR_FETCH boolean

2024-12-23T11:41:38+00:00

So that value "0" can turn them off. (From OE-Core rev: 1a2afcd0773c5ec5946d1dfc27bde585c52a5724) Signed-off-by: Robert Yang Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

classes/utility-tasks: port do_listtasks to use bb.build.listtasks

2024-12-12T13:31:27+00:00

Instead of iterating every datastore value by hand to find tasks, use the new bb.build.listtasks() function (bitbake 185c4b) (From OE-Core rev: 466c3ed0d01bc70caa29d5eb8bb99f7d0e6e710c) Signed-off-by: Ross Burton Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

rpm: update 4.19.1.1 -> 4.20.0

2024-12-12T13:22:08+00:00

With this release, as expected, deprecated openpgp support has been fully removed and replaced with sequoia: https://github.com/rpm-software-management/rpm-sequoia/ Alas, it's written in rust, and has no recipe, so for now signing rpm packages has to be disabled. Remove package name parameter to %prep in source archiving, as it's been dropped in the new rpm, and wasn't needed to begin with. Drop 0001-perl-disable-auto-reqs.patch (files removed upstream). (From OE-Core rev: 8c15b4577d5e554cc2dd5adfb88b816894b05a9a) Signed-off-by: Alexander Kanavin Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

base.bbclass: fix RRECOMMENDS extend issue for multilib

2024-12-12T12:59:35+00:00

During handle PACKAGECONFIG, DEPENDS/RDEPENDS/RRECOMMENDS is appended by calling function appendVar according to the PACKAGECONFIG setting: PACKAGECONFIG[f1] = "\ --with-f1, \ --without-f1, \ build-deps-for-f1, \ runtime-deps-for-f1, \ runtime-recommends-for-f1, \ packageconfig-conflicts-for-f1" [snip of base.bbclass] pkgconfigflags = d.getVarFlags("PACKAGECONFIG") or {} if pkgconfigflags: ... appendVar('DEPENDS', extradeps) appendVar('RDEPENDS:${PN}', extrardeps) appendVar('RRECOMMENDS:${PN}', extrarrecs) ... [snip of base.bbclass] After following commit in meta-oe, [fe3ba7ac5c cryptsetup: demote udev runtime dependency to recommendation] 'udev lvm2' changed from RDEPENDS to RRECOMMENDS, but RRECOMMENDS is not handled in this process, and causes following error: $bitbake lib32-cryptsetup ERROR: QA Issue: lib32-cryptsetup package lib32-cryptsetup - suspicious values 'udev lvm2' in RRECOMMENDS [multilib] In layer openembedded-core, we do have very few recipes that have runtime-recommends-for-f1 in PACKAGECONFIG setting, but f1 is not enabled in PACKAGECONFIGS, so not report error when multilib is enabled. (From OE-Core rev: 2f539a1318a80d3ad5d0d43a9ba4070465e402af) Signed-off-by: Changqing Li Signed-off-by: Richard Purdie