linux/poky.git/meta/classes/externalsrc.bbclass, branch nanbield

externalsrc: fix task dependency for do_populate_lic

2024-02-22T14:34:14+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: bc02b59ca6506d727450512ac2490b8861de59ca) Signed-off-by: Julien Stephan Signed-off-by: Richard Purdie (cherry picked from commit ea6a0cccdd274534809df62a0a196bf83489a1e5) Signed-off-by: Steve Sakoman

externalsrc.bbclass: Support specifying patterns in CONFIGURE_FILES

2023-10-06T10:51:11+00:00

This allows, e.g., *.cmake to be added to CONFIGURE_FILES to make the do_configure task depend on changes to any cmake file. (From OE-Core rev: 09873b3fb24a00cfbd73282d29e4c5821774f579) Signed-off-by: Peter Kjellerstedt Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

recipes/classes/scripts: Drop SRCPV usage in OE-Core

2023-08-24T15:50:24+00:00

Now that SRCPV isn't needed we can simplify things in a few places... (From OE-Core rev: 843f82a246a535c353e08072f252d1dc78217872) Signed-off-by: Richard Purdie

base/package: Move source revision information from PV to PKGV

2023-08-24T15:50:24+00:00

Source control information being present in PV used to be a hard requirement for bitbake to operate correctly. Now that hashes are a required part of task stamps, this requirement no longer exists. This means we can defer the hash pieces to PKGV and simplify PV. Use new bitbake fetcher API to inject the source revisions directly into the hash allowing removal of some horrible code from base.bbclass and avoiding any hardcoding about how SRCREV may or may not be used. Use that API to object the string to append to PKGV and append that directly. The user visible effect of this change is that PV will no longer have revision information in it and this will now be appended to PV through PKGV when the packages are written. Since PV is used in STAMP and WORKDIR, users will see small directory naming and stamp naming changes. This will mean that sstate reuse through hash equivalence where the source revision changes but the output does not will become possible as the sstate naming will become less specific and no longer contain the revision. The SRCPV variable will no longer be needed in PV and is effectively now just a null operation. Usage can be removed over time. (From OE-Core rev: a8e7b0f932b9ea69b3a218fca18041676c65aba0) Signed-off-by: Richard Purdie

externalsrc: fix dependency chain issues

2023-08-11T08:36:05+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: ee4667a24ccdd8c9d547e73aecf661e6a1283890) Signed-off-by: Peter Suti Signed-off-by: Richard Purdie

devtool: add support for multiple git url inside a cargo based recipe

2023-04-01T10:36:26+00:00

Without that, the possible git urls that are in SRC_URI of a recipe are removed from SRC_URI during devtool process and so the cargo_common_do_patch_paths in cargo_common.bbclass cannot patch these packages to fetch them locally. I use a generic type name because I foresee this change will be useful for recipe that used a package manager (cargo but also npm) see https://bugzilla.yoctoproject.org/show_bug.cgi?id=11015 (From OE-Core rev: 474658a3681c343385c359a21c3693401217298d) Signed-off-by: Frederic Martinsons Signed-off-by: Richard Purdie

devtool: fix devtool finish when gitmodules file is empty

2023-01-18T16:42:28+00:00

When a .gitmodules file exists but is empty then devtool finish fails. Add an additional check for this. [YOCTO #14999] (From OE-Core rev: b4f0f7c4934bade9e4d4a1086f9d8b29d8e9ad45) Signed-off-by: Thomas Roos Signed-off-by: Luca Ceresoli Signed-off-by: Richard Purdie

externalsrc: fix lookup for .gitmodules

2022-12-08T10:48:36+00:00

Commit 0533edac277080e1bd130c14df0cbac61ba01a0c broke bitbake parsing when bitbake is executed from directory with existing .gitmodules and the recipe in externalsrc does not have .gitmodules The check needs to search for .gitmodules in sources path, not cwd. iParsing recipes...ERROR: ExpansionError during parsing ... bb.data_smart.ExpansionError: Failure expanding variable do_compile[file-checksums], expression was ${@srctree_hash_files(d)} which triggered exception CalledProcessError: Command '['git', 'config', '--file', '.gitmodules', '--get-regexp', 'path']' returned non-zero exit status 1. (From OE-Core rev: 66ff3d1f65cd2e7f5319e98fa41f47a59b714c72) Signed-off-by: Peter Marko Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

externalsrc.bbclass: Remove a trailing slash from ${B}

2022-10-26T11:28:39+00:00

The trailing slash in ${B} caused -fdebug-prefix-map=${B}=... to not match as intended, resulting in ${TMPDIR} ending up in files in ${PN}-dbg when externalsrc was in use, which in turn triggered buildpath QA warnings. (From OE-Core rev: 9b5031ed5a0d102905fa75acc418246c23df6eef) Signed-off-by: Peter Kjellerstedt Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

externalsrc.bbclass: fix git repo detection

2022-10-26T11:28:39+00:00

* fix issue introduced in: https://git.openembedded.org/openembedded-core/commit/?id=95fbac8dcad6c93f4c9737e9fe13e92ab6befa09 * it added check for s_dir + git-dir (typically '.git') isn't the same as ${TOPDIR} + git-dir, but due to copy-paste issue it was just comparing it with s_dir + git-dir again, resulting in most external repos (where git-dir is '.git') to be processed as regular directory (not taking advantage of git write-tree). * normally this wouldn't be an issue, but for big repo with a lot of files this added a lot of checksums in: d.setVarFlag('do_compile', 'file-checksums', '${@srctree_hash_files(d)}') and I mean *a lot, e.g. in chromium build it was 380227 paths which still wouldn't that bad, but the checksum processing in siggen.py isn't trivial and just looping through all these checksums takes very long time (over 1000sec on fast NVME drive with warm cache) and then https://git.openembedded.org/bitbake/commit/?id=b4975d2ecf615ac4c240808fbc5a3f879a93846b made the processing a bit more complicated and the loop in get_taskhash() function took 6448sec and to make things worse there was no output from bitbake during that time, so even with -DDD it looks like this: DEBUG: virtual/libgles2 resolved to: mesa (langdale/oe-core/meta/recipes-graphics/mesa/mesa_22.2.0.bb) Bitbake still alive (no events for 600s). Active tasks: Bitbake still alive (no events for 1200s). Active tasks: Bitbake still alive (no events for 1800s). Active tasks: Bitbake still alive (no events for 2400s). Active tasks: Bitbake still alive (no events for 3000s). Active tasks: Bitbake still alive (no events for 3600s). Active tasks: Bitbake still alive (no events for 4200s). Active tasks: Bitbake still alive (no events for 4800s). Active tasks: Bitbake still alive (no events for 5400s). Active tasks: Bitbake still alive (no events for 6000s). Active tasks: DEBUG: Starting bitbake-worker without -DDD it will get stuck for almost 2 hours in: "Initialising tasks..." before it finally writes sstate summary like: "Sstate summary: Wanted 3102 Local 0 Mirrors 0 Missed 3102 Current 1483 (0% match, 32% complete)" * fix the copy&paste typo to use git work-tree in most cases, but be aware that this issue still exists for huge local source trees not in git [YOCTO #14942] (From OE-Core rev: 9102e5a94b8146cb1da27afbe41d3db999a914ff) Signed-off-by: Martin Jansa Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie