bitbake-dumpsig or bitbake-diffsig tools do not work on any of tasks
exposed by llvm-project-source recipe. This is due to it being a
shared-workdir recipe.
Fixes
bitbake-diffsigs -t llvm-project-source-20.1.2 do_preconfigure
NOTE: Starting bitbake server...
ERROR: No sigdata files found matching llvm-project-source-20.1.2 do_preconfigure
(From OE-Core rev: a6d46935939a94b8ea2b83c024aa86f05efbd7ce)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code was changing the timestamps of the files in the do_package output,
particularly the files added for debug sources. This was to do two things:
a) make do_package sstate more reproducible
b) ensure better hash equivalence matching
Unfortuately the debug source files are hardlinks into the source tree for
efficiency so touching these, touches a lot of files in ${B} and ${S}. This
causes unpredictable effects if compile is run again for example, or could
cause compiling in the install task.
The hash equivalence matching is of key importance but we can mimic that
using clamping of the file timestamps in the depsig output used to generate
the hashes.
This patch drops the global timestamp clamping, instead allowing the files
to retain their creation timestamps into sstate. This makes do_package sstate
slightly less reproducibile. We could clamp the sstate timestamps but that
would lead to two different sets of timestamps depending on whether the
data came from sstate or not. I'd prefer to have consistent code behaviour,
rather than differing behavhour depending on whether data came from sstate
or not.
If we wanted to have reproducibiliy and fix the "corruption" of S/B and have
consistent codepaths, the only other option would be two copies of the
sources, which could end up huge and seems the least desireable option.
This patch therefore drops the timestamp clamping in the sstate files
and tweaks the depsig data generation to clamp the timestamps for do_package
instead since this seems the best compromise.
I validated that rpm/deb/ipk files still generate correctly as before.
(From OE-Core rev: 475759fdab7200488b2a568b2ba1aa31a456d113)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's an ongoing issue with the autobuilder NFS:
https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/6463/steps/14/logs/stdio
The file entry exists, but os.stat returns a 'file not found; error. It's not
clear how and why such entries appear, but they do produce printdiff test failures
and should not be relevant in context of the printdiff.
[RP: Move wrapping to get_time() function to cover all cases and add comment]
(From OE-Core rev: b7e702752b6a2dfc8493639a8529cf1a16793f03)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Copying in the bb_unihashes cache file was at best a hack and creates a number of
challenges. One is staying in sync with bitbake since it may not have saved the
most recent version of the file. A second is a determinism problem since there may
be more entries in the file than the SDK should have had access to.
To improve the situation, add code to write the data into the locked-sigs.inc file
such that even when locked-sigs aren't used, the right hash mappings are injected
by the get_cached_unihash call.
The functions in copy_buildsystem need to be updated to preserve data they're not
editting.
(From OE-Core rev: 11373def3171e75b3b74ef694da213dd21f3064c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drops support for this variable since bitbake no longer supports
parallel queries to the hash equivalence server
(From OE-Core rev: b0769794ca858baa6e814e81b14cf542c33d3a09)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Looks like sometimes the e.filename and the e.lineno is not properly set by the netrc
and this can cause TypeError.
| File "/poky/meta/lib/oe/sstatesig.py", line 342, in init_rundepcheck
| bb.warn("Error parsing %s:%d: %s" % (e.filename, e.lineno, e.msg))
| ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| TypeError: %d format: a real number is required, not NoneType
(From OE-Core rev: 486ed69939f1b7572f121960c2dde246032686e7)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If there is an error parsing .netrc, warn the user
(From OE-Core rev: 47ea9418dfa31a87bc0014c482be5bfdc9df98e1)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allows the hash server credentials to be specified in bitbake variables.
If omitted, the users .netrc will be checked
(From OE-Core rev: ba391d39f2b888706e53028e9df3a37c5baedfc1)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Implements the new API required for querying unihashes in parallel
(From OE-Core rev: 0c66d07238d20dc1b34355e4c472aa7457d2e5fe)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we're changing the return values of the function, add a version so
bitbake can ensure it is using a compatible function.
(From OE-Core rev: 738bf3717002d124958a21a6925b0eca14fef131)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
find_siginfo() returns two different data structures depending
on whether its third argument (list of hashes to find) is empty or
not:
- a dict of timestamps keyed by path
- a dict of paths keyed by hash
This is not a good API design; it's much better to return
a dict of dicts that include both timestamp and path, keyed by
hash. Then the API consumer can decide how they want to use these
fields, particularly for additional diagnostics or informational
output.
I also took the opportunity to add a binary field that
tells if the match came from sstate or local stamps dir, which
will help prioritize local stamps when looking up most
recent task signatures.
(From OE-Core rev: 8721c52041e910bd4d8a9235b52f274f4f02c8a3)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <jose.quaresma@foundries.io>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <jstephan@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
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 <mateuszmar2@gmail.com>
Signed-off-by: Tomasz Dziendzielski <tomasz.dziendzielski@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
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 <ejo@pengutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <jose.quaresma@foundries.io>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Where there isn't a copyright statement, add one to make it explicit.
Also add license identifiers as MIT if there isn't one.
(From OE-Core rev: bb731d1f3d2a1d50ec0aed864dbca54cf795b040)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
SDPX generation involves looking through BB_TASKDEPDATA for
dependencies, then linking to the generated documents for those
dependencies. These document links use a checksum to validate the
document, which means that if a upstream document changes, all
downstream documents must be regenerated to get the new checksum,
otherwise the compendium of documents produced by the build will have
broken links; therefore all dependent task should be included in the
signature (even from "ABI safe" recipes).
(From OE-Core rev: 5fe543b9ceec971cf0297ff0ae3b0ccc4703cece)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sstate filename generation was changed a while ago and taskname has to be
passed into core functions for the correct filename to be generated. Update
find_siginfo to match those changes and pass in taskname via SSTATE_CURRTASK.
Thanks to Gregory Lumen <gregorylumen@microsoft.com> for spotting.
[YOCTO #14774]
(From OE-Core rev: 51d7310b6cf8ef9033d461868c07f686656070ba)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is redundant (target arch is already in PN), and breaks
compiling a cross-canadian toolchain, as that needs populating the
sysroot with two different native-hosted toolchains built from
cross recipes. Inserting TARGET_ARCH allows only one or the other.
(From OE-Core rev: 33fc1792cd782feb8dbb4285e3006bb588f7978f)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Native task outputs are directly run on the build system during the build
after being built. Even if the output of a native recipe doesn't change, a
change in one of its dependencies may cause a change in the output it
generates (e.g. rpm output depends on the output of its dependent zstd
library).
This can cause poor interactions with hash equivalence, since this
recipe's output-changing dependency is "hidden" and downstream tasks only
see that this recipe has the same outhash and therefore is equivalent.
This can result in different output in different cases and issues with
reproducible builds in parcular (e.g. rpm compression changes for the same
content).
To resolve this, unhide the output-changing dependency by adding it's
unihash to this tasks outhash calculation. Unfortunately, we don't know
specifically know which dependencies are output-changing, so we have to
add all of them.
[YOCTO #14685]
(From OE-Core rev: d6c7b9f4f0e61fa6546d3644e27abe3e96f597e2)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want things to be reproduicble and the variable doesn't really change
much any more. Drop the remaining uses and make those code paths always
active.
(From OE-Core rev: d15fb02c7ee7da50e322d74bc6a545234e20c7f3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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 <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* 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 <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <tomasz.dziendzielski@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pseudo-native is a bit special. It conditionally compiles in support for
xattr, statx and statvfs amongst other options. If a pseudo-native binary is
used on a system where these functions are present but it wasn't compiled in
we see hard to debug permissions problems.
An example is the devtool.DevtoolExtractTests.test_devtool_deploy_target
oe-selftest which shows a cryptic error:
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/meta/lib/oeqa/selftest/cases/devtool.py", line 1388, in test_devtool_deploy_target
self.assertEqual(filelist1, filelist2)
File "/usr/lib64/python3.9/unittest/case.py", line 831, in assertEqual
assertion_func(first, second, msg=msg)
File "/usr/lib64/python3.9/unittest/case.py", line 1037, in assertListEqual
self.assertSequenceEqual(list1, list2, msg, seq_type=list)
File "/usr/lib64/python3.9/unittest/case.py", line 1019, in assertSequenceEqual
self.fail(msg)
File "/usr/lib64/python3.9/unittest/case.py", line 670, in fail
raise self.failureException(msg)
AssertionError: Lists differ: ['-rwxr-xr-x 6000 6000 /etc/init.d/mdmonitor', '-rw-r-[10124 chars]n.8'] != ['-rwxr-xr-x root root /etc/init.d/mdmonitor', '-rw-r-[10124 chars]n.8']
First differing element 0:
'-rwxr-xr-x 6000 6000 /etc/init.d/mdmonitor'
'-rwxr-xr-x root root /etc/init.d/mdmonitor'
This is due to a version of pseudo without statx being used on a system where
ls uses statx, hence the files are displayed as 6000.6000 instead of root.root.
Avoid this by always building pseudo-native for the specific distro in question rather
than using a universal sstate feed.
This hopefully fixes one of the mysterious AB-INT issues.
(From OE-Core rev: 6e3785a3f1f3cf68f5fe101cd6bebe91db165973)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When trying to lock an individual signature, we see the checksum calculations
of dependent tasks failing. The fix is to remove a bad optimisation within
bitbake but with the removed, we need to remove some bogus code with
OE-Core's sstatesig code too.
(From OE-Core rev: 9923392539b1ce6d70f713527373d6bbc03f3021)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently if a task generates the same output with different timestamps,
hasequiv won't detect it but reproducibile builds will fail tests due
to the different timestamps.
Add do_package timestamps to the hash when reproducibile builds are enabled
to avoid this.
(From OE-Core rev: 11e8200ccec765ff6a4263e06512e5751eca261a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a pretty big change to the way pseudo operates when used in OpenEmbedded.
Normally, pseudo monitors and logs (adds to its database) any file created or
modified whilst in a fakeroot environment. There are large numbers of files
we simply don't care about the permissions of whilst in that fakeroot context,
for example ${S}, ${B}, ${T}, ${SSTATE_DIR}, the central sstate control
directories,
This change uses new functionality in pseudo to ignore these directory trees,
resulting in a cleaner database with less chance of "stray" mismatches if files
are modified outside pseudo context. It also should reduce some overhead from
pseudo as the interprocess round trip to the server is avoided.
There is a possible complication where some existing recipe may break, for
example, we found a recipe which was writing to "${B}/install" for
"make install" in do_install and since we listed ${B} as not to be tracked,
there were errors trying to chown root for files in this location.
This patch fixes a few corner cases in OE-Core when used with this new
ignore list:
* The archiver directory matched a "${WORKDIR}/deploy*" pattern so was renamed
to something else since that directory does need its root permissions
* The ${S} and ${B} ignoring is conditional on them being different to ${WORKDIR}
* package_write_* task output (the debs/rpms/ipks) are now owned by the build
user so we don't want the file ownership information in the hashequiv outhash
calculation even if they are built under pseudo.
* The fontcache postinstall intercept is run under qemu outside of pseudo context
so delete files it may delete up front where pseudo can see this.
* SSTATE_DIR is in PSEUDO_PATHS_IGNORE, which is in FAKEROOTENV which is cached
by bitbake. We therefore need to trigger reparsing if this changes, which means
SSTATE_DIR can be in BB_HASHBASE_WHITELIST but not BB_HASHCONFIG_WHITELIST.
Rework the variables to handle this. This otherwise breaks some of our sstate
tests in oe-selftest.
* Ignore the temp directory wic uses for rebuilding rootfs.
(From OE-Core rev: ad8f5532ffaead9a5ad13e1034fe9e5e1b7979f4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Bitbake now passes all the dataCaches to the taskhash API, so use this
to correctly filter mcdepends.
[YOCTO #13724]
(From OE-Core rev: 749731a420fb905b6af97ce2909f06b2bcd14fe2)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've found we need a way to cause a change in signatures and move
to a new hash 'namespace' with hashequiv. This introduces a variable
which allows us to do this.
(From OE-Core rev: 1c2d5aeae2fa2dfc16bc60b6cf0b310f826337fd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If getpwduid fails, we don't see which file it failed on which is key information
to aid debugging. Print this information when exceptions are raised.
(From OE-Core rev: 9d7a5219713af8117eda145052c6d9abdf577d8f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since get_unihash uses taskhash as a key internally, changing it means
different bebahour when locked sigs are active verses not active. Under
corner cases this leads to a signature mismatch.
Avoid this by by adding a wrapper for the place its externally exposed
and then not changing the internals.
(From OE-Core rev: 23b7484d326cf7fac013384598d7745a042eaa75)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
get_taskhash will call get_unihash internally in the parent class. We
need to disable our filter of it whilst this runs else incorrect hashes
can be calculated.
This is believed to be causing the locked signatures test to fail under
some circumstances (depending on whether earlier hashes are being
remapped).
[YOCTO #13605]
(From OE-Core rev: 523c093a882f6831ba75b5c4513837554d7e2414)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We can have one taskhash which represents multiple native/cross sstate objects
since they're stored by BUILD_ARCH or possibly host distro (or host gcc version).
We need to put these into separate namespaces on hashserv since their outhashes
will never match and we need deterministic lookups for the different namespaces.
Use this extramethod option to handle this. This fixes several problematic
failures on the autobuilder.
(From OE-Core rev: 2a76082363d189880613765ad339718e3614049d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Optimise the call into the parent function to be only when needed.
(From OE-Core rev: 198bacaa1068fd68075d9182318fe64e9809dd36)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With hashequiv the get_taskhash function is called much more regularly
and contains expensive operations. This these don't change based upon
hash in a given build, improve the caching within the function to
reduce overhead.
(From OE-Core rev: de98cfe3cde4b8d5f4b163b5fba3f129651ef06a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
