linux/poky.git/meta/classes, branch halstead/hashclient

cve-check: Log if CVE_STATUS set but not reported for component

2024-02-24T16:10:23+00:00

Log if the CVE_STATUS is set for a CVE, but the cve is not reported for a component. This should hopefully help to clean up not needed CVE_STATUS settings. (From OE-Core rev: 013d531a84fa08b6ae8a47bdf3ba1fa8f18ba270) Signed-off-by: Simone Weiß Signed-off-by: Richard Purdie

useradd.bbclass: Fix order of postinst-useradd-*

2024-02-24T16:10:22+00:00

postinst-useradd-* haven't been running in order of dependency. This patch is reworked from Piotr Łobacz's patch and fixes: https://bugzilla.yoctoproject.org/show_bug.cgi?id=15084 https://bugzilla.yoctoproject.org/show_bug.cgi?id=13904 basepasswd_sysroot_postinst in base-passwd can install postinst-useradd-* scripts with any order. Sometimes this means, for example a useradd postinst will attempt to run without the corresponding group postinst causing errors. This patch ensures that we first run groupadd, then useradd and then group membership. [RP: Tweaked to avoid removing previous fixes and for whitespace/style issues Also ensure the scripts are changed to execute with -e to highlight errors] (From OE-Core rev: 322ef726132a47d977d2c6ee41de5358f1e85994) Signed-off-by: Eilís 'pidge' Ní Fhlannagáin Signed-off-by: Piotr Łobacz Signed-off-by: Jan Górski Signed-off-by: Richard Purdie

useradd.bbclass: Fix missing space when appending vardeps.

2024-02-19T11:34:33+00:00

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

multilib_global.bbclass: fix parsing error with no kernel module split

2024-02-06T10:32:19+00:00

The problem could be reproduced with the following settings: MACHINE = "qemux86-64" KERNEL_SPLIT_MODULES = "0" require conf/multilib.conf MULTILIBS ?= "multilib:lib32" DEFAULTTUNE:virtclass-multilib-lib32 ?= "core2-32" The error message is as below: bb.data_smart.ExpansionError: Failure expanding variable KERNEL_VERSION_PKG_NAME, expression was ${@legitimize_package_name(d.getVar('KERNEL_VERSION'))} which triggered exception TypeError: expected string or bytes-like object The variable dependency chain for the failure is: KERNEL_VERSION_PKG_NAME -> RPROVIDES:kernel-modules This is because multilib_virtclass_handler_global function in multilib_global.bbclass deletes KERNEL_VERSION. So we need to handle such situation. We'll also need to delete KERNEL_VERSION_PKG_NAME to avoid this parsing error. (From OE-Core rev: 43dd497bc161ac44faecfdff052db03679dbb4f8) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

classes/multilib: expand PACKAGE_WRITE_DEPS in addition to DEPENDS

2024-01-27T08:20:02+00:00

Otherwise, PACKAGE_WRITE_DEPS would contain non-multilib variants of dependencies even when building multilib items, resulting in sysroots being populated with entirely wrong versions of them. This hasn't been noticed until now through sheer (bad) luck, I think, except in the cpio recipe, but the previous commit shows that the issues did occur, quietly. Every other recipe in oe-core and meta-oe does not prepend the multilib prefix. (From OE-Core rev: 234965cb88ccfa9c3a357928f7155b119044e8fc) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

sysroot user management postinsts: run with /bin/sh -e to report errors when they happen

2024-01-27T08:20:02+00:00

This exposes the following failure in a multilib setup, when everything up to do_package_write_rpm is in sstate, but do_package_write_rpm is not (there's a similar fail for lib64-man-db, and the failures themselves will be fixed separately in the next commit): Exception: subprocess.CalledProcessError: Command '/srv/storage/alex/yocto/build-multilib/tmp/work/x86_64-pokymllib64-linux/lib64-quilt/0.67/recipe-sysroot/usr/bin/postinst-base-passwd' returned non-zero exit status 1. Subprocess output: install: cannot stat '/srv/storage/alex/yocto/build-multilib/tmp/work/x86_64-pokymllib64-linux/lib64-quilt/0.67/lib64-recipe-sysroot/usr/share/base-passwd/passwd.master': No such file or directory (From OE-Core rev: 5ffa333db28bc5d8e440c983fdf95589d332461d) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

externalsrc: fix task dependency for do_populate_lic

2024-01-24T15:46:19+00:00

do_populate_lic dependencies are defined inside license.bbclass such as: addtask populate_lic after do_patch before do_build but externalsrc deletes the do_patch task, so the only dependency left for do_populate_lic is "before do_build" On a devtool context, when doing devtool modify, sources are extracted inside build/workspace/sources/${BPN}/ and local files inside build/workspace/sources/${BPN}/oe-local-files When building the recipe after a devtool modify, do_unpack is called again to unpack (possibly modified) local files from build/workspace/sources/${BPN}/oe-local-files into ${WORKDIR}. Since the only left dependency for do_populate_lic is do_build, the do_populate_lic can be called BEFORE do_unpack. Most of the time this is not a problem, because license files are generally located inside ${S}, which corresponds to build/workspace/sources/${BPN} (and is already unpacked), but this can lead to an issue if recipe sets LIC_FILES_CHKSUM to look for files in ${WORKDIR} (example from init-ifupdown_1.0.bb): LIC_FILES_CHKSUM = "file://${WORKDIR}/copyright;md5=3dd6192d306f582dee7687da3d8748ab" So devtool modify init-ifupdown && bitbake init-ifupdown gives the following error: WARNING: init-ifupdown-1.0-r0 do_populate_lic: Could not copy license file <...>/build/tmp/work/qemux86_64-poky-linux/init-ifupdown/1.0/copyright to <...>/build/tmp/work/qemux86_64-poky-linux/init-ifupdown/1.0/license-destdir/qemux86_64/init-ifupdown/copyright: [Errno 2] No such file or directory: '<...>/build/tmp/work/qemux86_64-poky-linux/init-ifupdown/1.0/copyright' ERROR: init-ifupdown-1.0-r0 do_populate_lic: QA Issue: init-ifupdown: LIC_FILES_CHKSUM points to an invalid file: <...>/build/tmp/work/qemux86_64-poky-linux/init-ifupdown/1.0/copyright [license-checksum] ERROR: init-ifupdown-1.0-r0 do_populate_lic: Fatal QA errors were found, failing task. ERROR: Logfile of failure stored in: <...>/build/tmp/work/qemux86_64-poky-linux/init-ifupdown/1.0/temp/log.do_populate_lic.838584 ERROR: Task (<...>/poky/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb:do_populate_lic) failed with exit code '1' Fix this by forcing the do_populate_lic task to run after do_unpack (From OE-Core rev: ea6a0cccdd274534809df62a0a196bf83489a1e5) Signed-off-by: Julien Stephan Signed-off-by: Richard Purdie

classes: go-vendor: Unlink vendor dir later

2024-01-19T12:21:22+00:00

Vendor directory might still be required during install stage, so defer the removal until later stage. (From OE-Core rev: f4538e3884a0cfa07e16e6a2c986271cc7322dd8) Signed-off-by: Vyacheslav Yurkov Signed-off-by: Richard Purdie

classes: go-vendor: Handle modules from the same repo

2024-01-19T12:21:22+00:00

Take into account module version when populating vendor directory, because a module with the same URL but with a different version tag could be used as an indirect dependency. (From OE-Core rev: 8f6320c0858941b2441e290ef3586b48c2700cd1) Signed-off-by: Vyacheslav Yurkov Signed-off-by: Richard Purdie

classes: go-vendor: Reference local modules

2024-01-19T12:21:22+00:00

Create symlinks for local modules, which are usually not referenced in the SRC_URI, but still expected to be found in the vendor directory during the build. (From OE-Core rev: 16da5d9ad448aafd8b5fd63480727bd1b09ec9f1) Signed-off-by: Vyacheslav Yurkov Signed-off-by: Richard Purdie