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

sstatesig: Only apply group/other permissions to pseudo files

2021-10-08T15:43:59+00:00

We hardlink some files into the build, such as licence files in do_populate_lic tasks. Depending on the umask that the source tree was checked out with, the group permissions would vary. This results in inconsistent task outhashes. Avoid this by ignoring the group/other bits unless we're under pseudo context. Bump the ABI numbers to ensure we don't see cache corruption from earlier builds. (From OE-Core rev: 2bd9c806de7e5197168360e3bd1d223a04a92291) Signed-off-by: Richard Purdie

sstatesig: Add processing for full build paths in sysroot files

2021-10-04T14:03:53+00:00

Some files in the populate_sysroot tasks have hardcoded paths in them, particularly if they are postinst-useradd- files or crossscripts. Add some filtering logic to remove these paths. This means that the hashequiv "outhash" matches correcting in more cases allowing for better build artefact reuse. To make this work a new variable is added SSTATE_HASHEQUIV_FILEMAP which maps file globbing to replacement patterns (paths or regex) on a per sstate task basis. It is hoped this shouldn't be needed in many cases. We are in the process to developing QA tests which will better detect issues in this area to allow optimal sstate reuse. (From OE-Core rev: d9852ffbbe728dac33dc081538a08af98f52fd4a) Signed-off-by: Richard Purdie

sstatesig: Revert "Test cross/native hashserv method extension"

2021-10-02T22:09:22+00:00

This reverts commit 2a76082363d189880613765ad339718e3614049d. We have an issue where x86 host builds are not matching hashes with aarch64 host builds. We'd expect that for a given target, the target artefacts should work regardless of the host architecture, compiler version etc. but this isn't happening and the hashes are differing. This is due to issues from hash equivalence. I believe the commit being reverted was added as a test and there were other fixes at the time which resolved these issues. As illustration of that, different gcc versions are not cauing issues with hash equivalence. That should be similar to the aarch64 case vs. x86-64 and hence if we're not seeing gcc verison issues, we also don't need this special case. As such, revert it as we don't need it and it is in fact breaking sstate reuse cross platform. [YOCTO #14578] (From OE-Core rev: be67dc551ca15a6f19855e8e99848aab2a33800d) Signed-off-by: Richard Purdie

sstatesig: Allow exclusion of the root directory for do_package

2021-09-16T08:50:34+00:00

The package task references WORKDIR at it's top level and we can't easily make the timestamp for that determnistic due to writes to files there and in other subdirs. We could try and force it to a specific value but it is easier to just remove it from the package task, we don't need it there or care about it in this case. (From OE-Core rev: 9cceeb906527f90d8dd3aad75aa3a8805e2a1df5) Signed-off-by: Richard Purdie

meta: Manual override fixes

2021-08-02T14:44:10+00:00

The automated conversion of OE-Core to use the new override sytax isn't perfect. This patches some mis-converted lines and some lines which were missed by the automation. (From OE-Core rev: 4e9a06b64b43131b731fb59a0305f78a98e27fbd) Signed-off-by: Richard Purdie

Convert to new override syntax

2021-08-02T14:44:10+00:00

This is the result of automated script conversion: scripts/contrib/convert-overrides.py converting the metadata to use ":" as the override character instead of "_". (From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae) Signed-off-by: Richard Purdie

classes/buildhistory: Add option to strip path prefix

2021-06-03T22:09:41+00:00

Adds an option to strip a prefix from the paths reported in buildhistory. This makes it easier to compare task signatures in the build history when the builds were done from different directories. (From OE-Core rev: 194e7a29212c4a29222730f47d3133dfe92447c1) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

sstatesig.py: make it fatal error when sstate manifest isn't found

2021-05-21T14:18:23+00:00

* all known issues in this area were fixed, make it fatal that it cannot be overlooked if someone triggers this issue again (From OE-Core rev: 64b89f3c8fc31842256c482a3039d90d3f12c1cc) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

sstatesig.py: show an error instead of warning when sstate manifest isn't found

2021-02-26T15:21:20+00:00

* not sure if there are some valid use-cases for missing manifest, but recently I'm seeing increasing number of build failures where something from native recipe is missing (seen it with pseudo, autoconf, nodejs recently) and the only indication that something is wrong (before showing sometimes misleading error like: recipe-sysroot-native/usr/bin/node: No such file or directory is this warning: NOTE: Running task 7844 of 12431 (/meta-oe/meta-oe/recipes-devtools/nodejs/nodejs_12.20.2.bb:do_prepare_recipe_sysroot) NOTE: recipe nodejs-12.20.2-r0: task do_prepare_recipe_sysroot: Started WARNING: nodejs-12.20.2-r0 do_prepare_recipe_sysroot: Manifest /BUILD/sstate-control/manifest-x86_64_ubuntu-18.04-nodejs-native.populate_sysroot not found in x86_64 x86_64_ubuntu-18.04 (variant '')? NOTE: Running task 7845 of 12431 (/meta-oe/meta-oe/recipes-devtools/nodejs/nodejs_12.20.2.bb:do_unpack) NOTE: recipe nodejs-12.20.2-r0: task do_unpack: Started WARNING: nodejs-12.20.2-r0 do_prepare_recipe_sysroot: Manifest /BUILD/sstate-control/manifest-x86_64_ubuntu-18.04-nodejs-native.populate_sysroot not found in x86_64 x86_64_ubuntu-18.04 (variant '')? NOTE: recipe nodejs-12.20.2-r0: task do_prepare_recipe_sysroot: Succeeded if I rebuild that native dependency, then it gets fixed and I don't see these failures in clean builds (as without sstate and with empty TMPDIR), only in incremental builds * but if there isn't valid reason for missing manifest file, then I think it would be better to error early (or even bb.fatal()) (From OE-Core rev: 95607a26854d873399d2b9d7e5fcbffc0cbdba4c) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

sstatesig: Add descriptive error message to getpwuid/getgrgid "uid/gid not found" KeyError

2021-02-03T21:45:49+00:00

If path is not owned by any user installed on target it gives insufficient error "getpwuid(): uid not found" which may be misleading. This exception occurs if uid/gid of path was not found in PSEUDO_PASSWD files, which simply means the path is owned by host user and there is host user contamination. Add more information to the exception message to make it easier for user to debug. [YOCTO #14031] (From OE-Core rev: 38540b59ed4ec8632e30a5fd6364b010d9da8470) Signed-off-by: Tomasz Dziendzielski Signed-off-by: Richard Purdie