linux/poky.git/meta/lib/oe/sstatesig.py, branch 5.0_M1

sstatesig/find_siginfo: special-case gcc-source when looking in sstate caches

2023-12-09T19:17:11+00:00

This is already done for local stamps just above, and will allow enabling the full selftest that compares gcc-source signatures via printdiff (that is, both local stamp and sstate variants). (From OE-Core rev: 29775b5ecfc8d811293962f050fcfc3b3ad7efde) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

lib/oe/sstatesig.py: dump locked.sigs.inc only when explicitly asked via -S lockedsigs

2023-10-27T09:53:43+00:00

This was writing out locked-sigs.inc into cwd with every 'bitbake -S' invocation. When the intent is only to to get task stamps (-S none), or print the difference between them (-S printdiff), the file is unnecessary clutter. A couple of selftests/scripts were however relying on this, so they're adjusted to explicitly request the file. eSDK code calls dump_lockedsigs() separately via oe.copy_buildsystem.generate_locked_sigs() and so isn't affected. (From OE-Core rev: ad57c3cac2a8d3e60222e3cca0685f582dcea135) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

sstatesig: be more precise and show the full path in exceptions

2023-10-19T12:38:56+00:00

Also remove the warning than doesn't make sense as the code will generate an exception and bitbake will abort. Before: | WARNING: core-image-minimal-initramfs-1.0-r0 do_image_complete: KeyError in . | Exception: Exception: KeyError: 'getpwuid(): uid not found: xxxxx' | Path . is owned by uid xxxxx, gid yyy, which doesn't match any user/group on target. This may be due to host contamination. After: | Exception: Exception: KeyError: 'getpwuid(): uid not found: xxxxx' | Path /build/tmp/work/intel_corei7_64-lmp-linux/core-image-minimal-initramfs/1.0-r0/sstate-build-image_complete is owned by uid xxxxx, gid yyy, which doesn't match any user/group on target. This may be due to host contamination. (From OE-Core rev: 90f84e345950a02bf91f823cc9c6d893e7cd1100) Signed-off-by: Jose Quaresma Signed-off-by: Luca Ceresoli Signed-off-by: Richard Purdie

sstatesig: add a new info level for SIGGEN_LOCKEDSIGS_TASKSIG_CHECK

2023-10-09T14:58:47+00:00

as of now, SIGGEN_LOCKEDSIGS_TASKSIG_CHECK can take 2 values: "warn" and "error", displaying respectively a warning or a fatal error message only when a task is locked and the task signature is different from the locked one. The "info" level is introduced to add a "note" message to remind the user that a recipe is locked even if the signature is equivalent to the locked one. The "warn" and "error" level display the warn/error message for each task having a mismatch of the signature. Doing this with the "info" level would result in very verbose output if there are several tasks locked, so the info level will only print once the list of recipes that have locked signature. (From OE-Core rev: 840402181d36ca3f60119984478979afb5bb3bbf) Signed-off-by: Julien Stephan Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

sstatesig: Update to match bitbake changes to runtaskdeps

2023-08-09T12:23:33+00:00

Bitbake has changes to runtaskdeps in siginfo files to fix bugs in being able to locate them for sstate and hash debugging purposes. This patch updates to match the changes to the format. (From OE-Core rev: 4f1148eeab2500022d7e17feadf80027a01a51f1) Signed-off-by: Richard Purdie

sstatesig: Drop SPDX special casing

2023-06-06T22:41:13+00:00

Other changes in create-spdx code mean we shouldn't need to do this now. We need the various exclusions to allow the task hashes to behave correctly for the SPDX tasks too. (From OE-Core rev: 5e645ff3d02decba4ed7d082a0e41a2655862039) Signed-off-by: Richard Purdie

sstatesig: Improve output hash calculation

2023-02-15T10:21:34+00:00

Symbolic links to the files are included during the output hash calculation but symlinks to the directories are missed. So if the new symlink to a directory was the only change made, then the output hash won't change, and the Hash Equivalence server may change unihash. In the next run bitbake may use an older package from sstate-cache. To fix this followlinks=True flag could be set for os.walk but it can lead to infinite recursion if link points to a parent directory of itself. Also, all files from a directory to which symlink points would be included in depsig file. Therefore another solution was applied, I added code that will loop through directories and process those that are symlinks. (From OE-Core rev: ee729163f31f26b1462a47e1e53f7a0f9de9b464) Signed-off-by: Mateusz Marciniec Signed-off-by: Tomasz Dziendzielski Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

lib/sstatesig: Drop OEBasic siggen

2022-12-11T23:20:14+00:00

We're now used to using hashes as part of the task hashes and the sstate code relies on this. The older OEBasic hash approach therefore wouldn't work and can be removed. (From OE-Core rev: 3667e589ba16eb261cfd72c2b11429f482c239f6) Signed-off-by: Richard Purdie

sstatesig: emit more helpful error message when not finding sstate manifest

2022-11-20T08:29:07+00:00

Since oe-core commit 64b89f3c8fc31842256c482a3039d90d3f12c1cc ("sstatesig.py: make it fatal error when sstate manifest isn't found") errors like: | Manifest [..]/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-dbus.populate_sysroot not found in imx8mm_dummy cortexa53-mx8mm cortexa53 armv8a-crc armv8a aarch64 allarch x86_64_x86_64-nativesdk (variant '')? are fatal now and cannot be ignored but must be debugged. Unfortunately, the currently emitted error message is a bit imprecise with telling the reader what has actually gone wrong. This commit: * adds the word 'sstate' to the error message to clarify the scope we are dealing with ('sstate manifests', since there are other manifests, too) * does not randomly print the last manifest file searched for as THE manifest file that could not be found Instead, we print the name of the task the sstate was searched for * adds the word 'multilib' to variant to make clear which variant we are talking about * adds a separate line noting the searched pkgarchs and adds explicitly mentions this word ('pkgarchs') * prints a list of ALL manifest file locations attempted * removes the '?' at the end of the message since such errors indeed leave the question of what is the cause but the error message itself is more like a statement. The result for the exact same issue as noted above then looks as follows: | The sstate manifest for task 'dbus:populate_sysroot' (multilib variant '') could not be found. | The pkgarchs considered were: imx8mm_dummy, cortexa53-mx8mm, cortexa53, armv8a-crc, armv8a, aarch64, allarch, x86_64_x86_64-nativesdk. | But none of these manifests exists: | [..]/tmp/sstate-control/manifest-imx8mm_dummy-dbus.populate_sysroot | [..]/tmp/sstate-control/manifest-cortexa53-mx8mm-dbus.populate_sysroot | [..]/tmp/sstate-control/manifest-cortexa53-dbus.populate_sysroot | [..]/tmp/sstate-control/manifest-armv8a-crc-dbus.populate_sysroot | [..]/tmp/sstate-control/manifest-armv8a-dbus.populate_sysroot | [..]/tmp/sstate-control/manifest-aarch64-dbus.populate_sysroot | [..]/tmp/sstate-control/manifest-allarch-dbus.populate_sysroot | [..]/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-dbus.populate_sysroot (From OE-Core rev: 735ec126ec219c7cb89cb05b0e433201bb7f59eb) Signed-off-by: Enrico Jorns Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

sstatesig: skip the rm_work task signature

2022-11-14T16:19:43+00:00

We can skip the rm_work task signature to avoid running the task when we remove some tasks from the dependencie chain. The inject_rm_work handler on the rm_work bbclass triggers the rm_work task running for any signature change in the dependencie chain of the task do_build of each recipe. i.e INHERIT:remove = "create-spdx" will trigger the do_rm_work when we collect the sstate cache with INHERIT = "create-spdx" (From OE-Core rev: 292305700e39d0ebd64763f5032c39ace5005fad) Signed-off-by: Jose Quaresma Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie