multiconfig dependencies should be excluded from BB_TASKDEPDATA.
However in thud, multiconfig filtering on task dependencies doesn't
happen until after deps has already been added to taskdepdata.
One manifestation of this results in multiconfig dependencies leaking
into staging processing.
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:extend_recipe_sysroot(d)
0003:
File: '/home/user/thud/meta/classes/staging.bbclass', lineno: 344, function: extend_recipe_sysroot
0340: #bb.note(" start is %s" % str(start))
0341:
0342: # Direct dependencies should be present and can be depended upon
0343: for dep in set(start):
*** 0344: if setscenedeps[dep][1] == "do_populate_sysroot":
0345: if dep not in configuredeps:
0346: configuredeps.append(dep)
0347: bb.note("Direct dependencies are %s" % str(configuredeps))
0348: #bb.note(" or %s" % str(start))
Exception: KeyError: 'multiconfig:musl:/home/user/thud/meta/recipes-kernel/linux/linux-yocto_4.18.bb:do_deploy'
This can be reproduced on thud by backporting the multiconfig.MultiConfig.test_multiconfig
test and mcextend bbclass from warrior.
d22b6e03a5 mcextend: Add helper class useful for multiconfig
d9018a3d9c selftest: Add multiconfig test
Flipping the ordering to match warrior's behavior fixes the test case.
(Bitbake rev: b690030efc87850951e8e3ecf4ae3c1dd1dc9b63)
Signed-off-by: Kyle Russell <bkylerussell@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to fix a systemtap bug [1] on arm board, we backport a kernel
patch from v5.0 kernel to v4.14 & v4.18 kernel, then need to bump the
kernel version to include this patch. Even this is only an arm specific
bug, we would like to bump the kernel version for the BSPs at the same
time. Boot test for all the boards.
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=13273
(From meta-yocto rev: 23ea5a859346f19ea3a53451702621e9102c853d)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was a weird error in OE-Core where "devtool modify virtual/kernel"
was showing basehash mismatch errors. This was due to SRCPV sometimes being:
AUTOINC+b867b78b50_47b80ef7bd and sometimes AUTOINC+b867b78b50_255a750d28.
The latter hash comes from KBRANCH and meant sometimes the correct branch
was seen, sometimes it was not. The issue was complicated by the execution
using a remote datastore over tinfoil.
The problem turns out to be a fetcher caching error. If the datastore
changes, the cached url data may not be valid.
We therefore ensure we match cached url data against the datastore that
generated it, which appears to fix this issue.
(Bitbake rev: 97067634b1f149b56844b10e3a5e8d0d980b6e34)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Updated poky.ent to use 2.6.4 stuff
* Updated mega-manual.sed to use "2.6.4" string
* Updated all the <manual>.xml files manual revision table
to be "November 2019"
(From yocto-docs rev: 607598f72bc3e7393ccf7c6380c03dddef3bb41c)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bitbake-worker child on the SIGTERM signal handling send the SIGTERM to all
processes in it's process group. In cases when the bitbake-worker child got
SIGTERM after registering own SIGTERM handler and before the os.setsid() call
it can send SIGTERM to unwanted processes.
In the worst case during SIGTERM processing the bitbake-worker child can be in
the group of the process that started BitBake itself. As a result it can kill
processes that not related to BitBake at all.
(Bitbake rev: b51877cbb8a7c713aa2bcec8354ec66e2f3dad51)
Signed-off-by: Ivan Efimov <i.efimov@inango-systems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit e8cd30ba6c.
This backport introduced an issue not seen the AB QA.
Issue can be seen if
BAD_RECOMMENDATIONS_append = " udev-hwdb" is used
(From OE-Core rev: 5110080fbecd3f1cf43797c7eeb742951d88d1a8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If one has provided external key/certificate for modules signing, Kbuild
will skip creating signing_key.pem and will write only signing_key.x509
certificate. Thus we have to check for .x509 file existence rather than
.pem one.
(From OE-Core rev: 4972582767a3325d22a16db9a5479c2d0001964b)
Signed-off-by: Dmitry Eremin-Solenikov <dmitry_eremin-solenikov@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 2527e731eba43bd36d0ea268aca6b03155376134)
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The variable values that result from parsing multiconfig should be
included in the cooker data hash, otherwise changes to these files won't
be detected, which will allow the parsing cache to be loaded with the
old values for the multiconfigs. This can either manifest as the
variable values simply not updating, or getting basehash changed errors
when building.
This bug was previously undetected because all of the multiconfig base
files were a direct file dependency in all parsed recipes. This was
fixed in 34137a00f60 ("bitbake: bitbake: cooker: Rename __depends in all
multiconfigs"), exposing this bug.
[YOCTO #13541]
(Bitbake rev: 6b045e074c6fea97d4e305a5a3c8bf82135d95eb)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes the following error:
TOPDIR/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:254:16: error: static declaration of ‘gettid’ follows non-static declaration
254 | _syscall0(int, gettid)
| ^~~~~~
TOPDIR/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:185:13: note: in definition of macro ‘_syscall0’
185 | static type name (void) \
| ^~~~
In file included from /usr/include/unistd.h:1170,
from TOPDIR/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/include/qemu/osdep.h:90,
from TOPDIR/tmp/work/x86_64-linux/qemu-native/3.1.0-r0/qemu-3.1.0/linux-user/syscall.c:20:
/usr/include/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ was here
34 | extern __pid_t gettid (void) __THROW;
| ^~~~~~
(From OE-Core rev: 5b5ca76cc5dd424248c7e687e562597a2c85df57)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In recent years AMD CPUs have had various problems with RDRAND
giving either non-random data or no result at all, which is
problematic if either build or target machine has a CPU with
this problem.
The fallback is /dev/urandom, and I'd trust the kernel here.
--enable-rdrand was added in an upgrade to a new upstream
version without mentioning any reason.
[YOCTO #13534]
(From OE-Core rev: fad633eb5c464d4e2a984b9259625bcd150ee357)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ensure log directory exists to avoid the following error.
FileNotFoundError: [Errno 2] No such file or directory: '/.../build-selftest/tmp/log/oe-selftest-results-20181207043431.log'
(From OE-Core rev: c54411d0e03fe1cea8b6bb0c80dea029dd264f36)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 7cb42ae87ef9 "dhcp: update 4.4.1" dropped
0008-tweak-to-support-external-bind.patch
from recipe, but left the patch itself in source tree.
Remove this patch since nobody uses it.
Cc: Armin Kuster <akuster808@gmail.com>
(From OE-Core rev: 109e8420c8a4e94dccb3c83e2b0b7fc6ceb66b04)
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Source: golang.org
MR: 99376
Type: Security Fix
Disposition: Backport from golang.org
ChangeID: 41576ab4a0abdebbc44f1a35a83bf04e5f2fde06
Description:
https://golang.org/doc/devel/release.html
go1.11.11 (released 2019/06/11) includes a fix to the crypto/x509 package. See the Go 1.11.11 milestone on our issue tracker for details.
go1.11.12 (released 2019/07/08) includes fixes to the compiler and the linker. See the Go 1.11.12 milestone on our issue tracker for details.
go1.11.13 (released 2019/08/13) includes security fixes to the net/http and net/url packages. See the Go 1.11.13 milestone on our issue tracker for details.
Includes CVE: CVE-2019-14809
(From OE-Core rev: 6018e9755dce3eaa22a1fe691dc18546c43c9cbe)
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The build fails on qemu-native if we're using kernels after commit
0768e17073dc527ccd18ed5f96ce85f9985e9115. This adds an upstream
patch that fixes the issue.
(From OE-Core rev: fac2d3846dadfda256e94500bdf33f546a8d1fb4)
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Refactoried for thud context]
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
