We're seeing pthread being linked sometimes and not others leading to
non-reproducible target binaries. The reason is mixing the native python
config with the target one. We should use the target one.
(From OE-Core rev: 0a390b5b36bbd1b2a3aefa74d03e8e40240c68fb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1bc5378db760963e2ad46542f2907dd6a592eb66)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recently a number of CVEs have been logged against a nodejs project
called "node-tar". These appear as false positives against the GNU tar
being built by Yocto. Some of these have been manually excluded using
CVE_CHECK_WHITELIST.
To avoid this problem, use the vendor name (in addition to package name)
for filtering CVEs. The syntax for this is:
CVE_PRODUCT = "vendor:package"
When not specified, the vendor defaults to "%" which matches anything.
(From OE-Core rev: d11e970c6e2482ad0b21994e4ec85ddf2aea1ede)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 45d1a0bea0c628f84a00d641a4d323491988106f)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We occasionally see bitbake-worker failing and from the logs, an unpickle error
occurs. Add more debug so we can further debug this next time it fails.
[YOCTO #14595]
(Bitbake rev: 692fa35f4c23722f3179502cb965960cc230e709)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit fe8105cc06beca8240b76ea366a1eff5aa9c5412)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've seen races where the socket may be gone but the server is still writing
out it's database. Handle that case too to avoid cleanup tracebacks.
[YOCTO #14440]
(Bitbake rev: 36b1b4c4fcee9dde628c7113203939730ab12ae5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit b9e4fb843cb9d3a4d4404af093a781fab5520465)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It turns out that for Ubuntu, lz4 is the valid package name for newer
versions (e.g. 20.04 LTS) but not for older ones (e.g. 18.04 LTS, where
the correct package is liblz4-tool). In 20.04 the lz4 package includes
liblz4-tool in its "provides" so it's best to list that one for now.
(From yocto-docs rev: 222af72b9ee307d43a8463283e058c6ebb18fefc)
Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ensure we have a brief introductory section and tweak the general
migration considerations a little.
(From yocto-docs rev: c94aa8b9d828f9267a70deee05bdf483dc570101)
Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add migration instructions gathered by combing the commits in this
release.
(From yocto-docs rev: b864f8570271df4e6cb47d21cb658d13ffd1d8f5)
Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These are now required so update the corresponding distro-specific
lists used in the system requirements documentation.
(From yocto-docs rev: 1ddd56a98064015582a8c161a1b998c06ebcaf26)
Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was recently removed so remove the reference to it.
(From yocto-docs rev: 46bfdb0b4ae2cb834589ef09436b120715663a31)
Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have a choice of policy with hashequivalence - whether to reduce
sstate duplication in the sstate feed to a minimum or have maximal
sstate reuse from the user's perspective.
The challenge is that non-matching outhashes are generated due to
determinism issues, or due to differences in host gcc version,
architecture and so on and the question is how to reconcile then.
The approach before this patch is that any new match is added and
matches can update. This has the side effect that a queried value
from the server can change due to the replacement and you may not
always get the same value from the server. With the client side
caching bitbake has, this can be suboptimal and when using the
autobuilder sstate feed, it results in poor artefact reuse.
This patch switches to the other possible behaviour, once a hash is
assigned, it doesn't change. This means some sstate artefacts may be
duplicated but dependency chains aren't invalidated which I suspect
may give better overall performance.
Update the tests to match the new behaviour.
(Bitbake rev: 20d6ac753efa364349100cdc863e5eabec8e5b78)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes the hashequivalence server to resolve the diverging report race
error. This error occurs when the same task(hash) is run simultaneous on
two different builders, and then the results are reported back but the
hashes diverge (e.g. have different outhashes), and one outhash is
equivalent to a hash and another is not. If taskhash was not originally
in the database, the client will fallback to using the taskhash as the
suggested unihash and the server will see reports come in like:
taskhash: A
unihash: A
outhash: B
taskhash: C
unihash: C
outhash: B
taskhash: C
unihash: C
outhash: D
Note that the second and third reports are the same taskhash, with
diverging outhashes.
Taskhash C should be equivalent to taskhash (and unihash) A because they
share an outhash B, but the server would not do this when tasks were
reported in the order shown.
It became clear while trying to fix this that single large table to
store all reported hashes was going to make these updates difficult
since updating the unihash of all entries would be complex and time
consuming. Instead, it makes more sense to split apart the database into
two tables: One that maps taskhashes to unihashes and one that maps
outhashes to taskhashes. This should hopefully improve the parsing query
times as well since they only care about the taskhashes to unihashes
table, at the cost of more complex INNER JOIN queries on the lesser used
API.
Note this change does delete existing hash equivlance data and starts a
new database table rather than converting existing data.
(Bitbake rev: dff5a17558e2476064e85f35bad1fd65fec23600)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Prevents `ResourceWarning: unclosed event loop` warnings when using the
synchronous client and python exits
(Bitbake rev: 8b95972bc04ce52a98c7780184af15a5e95f987b)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When ptest-runner times out or otherwise fails, it tries to
call ptest-runner-collect-system-data, so install the script.
The script currently calls dmesg, df, free (which are provided
by busybox, etc.) and pstree (which is a sub-package of psmisc).
Add pstree as an RDEPENDS.
(From OE-Core rev: 4e6be3fb521b23cfc175d0c09725bcc3ebbc73b2)
Signed-off-by: Tim Orling <timothy.t.orling@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libcidn has been dropped since glibc 2.28
(From OE-Core rev: cf83790728ad569af01300f793754c0108c78b4e)
Signed-off-by: Fred Liu <yclw3d2y@live.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After upgrade to 2.13.0, for arm32, with DEBUG_BUILD enabled, lttng-ust
build failed with error:
| /path/to/tmp/work/cortexa15t2hf-neon-poky-linux-gnueabi/lttng-ust/2_2.13.0-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/11.2.0/ld: ../../../src/lib/lttng-ust/.libs/liblttng-ust.so: undefined reference to `_uatomic_link_error'
| collect2: error: ld returned 1 exit status
| Makefile:399: recipe for target 'test_ust_error' failed
| make[3]: *** [test_ust_error] Error 1
The problem has reported to upstream, and upstream suggests to use
-DUATOMIC_NO_LINK_ERROR for the failure case, refer [1].
[1]https://lists.lttng.org/pipermail/lttng-dev/2021-September/030056.html
(From OE-Core rev: 722d58bccd5616b3b3364845bbf1121d3cc0c3cd)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
