nativesdk is built with a specific prefix but this will be different at install
time, however glibc hard-codes the path to locale files. Expand these strings to 4K and move them to a magic segment which we can relocate when the SDK is installed.
(From OE-Core rev: 59e0679378aac27c4fea0b06721e0a184a93c100)
(From OE-Core rev: 839479f63a6b927606742b15000d55b1223cb3af)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This mitigates following issues during u-boot do_compile() step --
otherwise, if comm is not available, they are quietly ignored:
.../scripts/check-config.sh: line 33: comm: command not found
.../scripts/check-config.sh: line 39: comm: command not found
Since 'comm' is provided by coreutils package, adding it to HOSTTOOLS
was considered a lower impact fix compared to adding coreutils-native
buildtime dependency to u-boot recipe.
(From OE-Core rev: 8c370ab4352581c19c45d476a97c2c3b45a56fdb)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
portmap was dropped in rocko and later and doesn't work with libtirpc
so don't build it for musl
(From OE-Core rev: 5e4b4874c4d81b62a32b3836d1c22ecc4c5479c6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If glibc is newer on the host than in uninative, the failure mode is
pretty nasty for clusters where the sstate is shared, including the Yocto
Project autobuilder.
This check aborts the use of uninative in such scenarios where a newer
glibc version appears and avoids corruption of sstate caches.
We use ldd to check the glibc version since that is included in libc-bin
(or equivalent) which locales use so it should always be present.
(From OE-Core rev: 8147911a951c7b0508f9c2aef93480d65b4362c0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now distros are starting to ship glibc 2.27 we need a uninatve version
which contains glibc 2.27 which is in the 1.8 version.
(From OE-Core rev: f2006493d26de1a6b5ffdbfd553d82d6254884d5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Should also fix build on new build hosts where
with glibc 2.27 rpc support is dropped in favor
of libtirpc
(From OE-Core rev: f5992ee01fca27d5fdfb9108f436adfcb49f1ae7)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libtirpc prior to 1.0.2 assumed that the system provided nis.h but this isn't
always true. Until now we've been using a tarball of the missing files from
Gentoo, but libtirpc 1.0.2 added a copy of nis.h to the sources so this isn't
required anymore.
(From OE-Core rev: e58b420a0e4ef62bd597ce286c9faea2a51913c4)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This vulnerability is also called "rpcbomb".
Backport upstream patch to fix this vulnerability.
CVE: CVE-2017-8779
(From OE-Core rev: bb6af5f0dbb39553654ba3a587c8078bb635da6f)
Signed-off-by: Fan Xin<fan.xin@jp.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use memset() API instead of __bzero()
Drop the patch removing des_* functions for musl
(From OE-Core rev: 8264826911888bd45b1d0cc914675d30a1a78546)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libnsl needs this API
(From OE-Core rev: 103a41f50961d916d52343c6457639c6734d4e72)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These fixes are needed for it to work with gcc7
(From OE-Core rev: d31ee3eb2be020b072278262693ed7bd607ba18a)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
| ../../valgrind-3.12.0/VEX/priv/host_ppc_isel.c: In function 'iselInt64Expr':
| ../../valgrind-3.12.0/VEX/priv/host_ppc_isel.c:3270:1: internal compiler error: Segmentation fault
| }
| ^
| Please submit a full bug report,
| with preprocessed source if appropriate.
| See <http://gcc.gnu.org/bugs.html> for instructions.
| rm -f libvexmultiarch-amd64-linux.a
| Makefile:1813: recipe for target 'priv/libvex_amd64_linux_a-host_ppc_isel.o' failed
Remove the patch to gcc causing this until the issue can be figured out.
(From OE-Core rev: f76ee525a75dd6e443743bf723ad4511707c7f49)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backported series of patches from https://github.com/hjl-tools/gcc.git
branch /hjl/indirect/gcc-6-branch/master which contains
an IA patch series for security related issues
(From OE-Core rev: 8283b4ee5290843b1033ca496759fce6229b8f91)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The following commit added the FL_LPAE flag to FL_FOR_ARCH7VE, but
neglected to also add it to the armv7ve compatible cores defined in
arm-cores.def.
af2d9b9e58
The result is that gcc 6.4 now refuses to allow -march=armv7ve and
-mcpu=XXX to be used together, even when -mcpu is set to an armv7ve
compatible core:
arm-linux-gnueabi-gcc -march=armv7ve -mcpu=cortex-a7 -Werror ...
error: switch -mcpu=cortex-a7 conflicts with -march=armv7ve switch [-Werror]
Fix by defining flags for armv7ve compatible cores directly from
FL_FOR_ARCH7VE, rather than re-creating the armv7ve flags
independently by combining FL_FOR_ARCH7A with the armv7ve specific
FL_THUMB_DIV and FL_ARM_DIV flags.
(From OE-Core rev: 166863e85a614a88ae0856274cfe7657e4f1e95d)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We saw builds where runtime providers were sometimes changing order and the
build result was therefore non-deterministic. For example it could show:
DEBUG: providers for lib32-initd-functions are: ['lib32-lsbinitscripts', 'lib32-initscripts']
or
DEBUG: providers for lib32-initd-functions are: ['lib32-initscripts', 'lib32-lsbinitscripts']
which could cause a test to pass or fail.
This change ensures we don't rely on the random order of dictonaries in
memory and act deterministically.
(Bitbake rev: eddab52a4e7c49bfcdc2c26004d0bc777a1e5c25)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Generating the host keys atomically prevents power interruptions during the
first boot from leaving the key files incomplete, which often prevents users
from being able to ssh into the device.
[YOCTO #11671]
(From OE-Core rev: d532735e608e32ef1f5a7307c344e528e8fa2f01)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 43fc3d8e180c168dbe5dd5faa577e69a279bd1bd)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add tools required by testimage to HOSTTOOLS only when testimage is
inherited. These tools, as described in the comment, are only required
by the testimage task. So this change should not have negtive effect.
This would also solve build error on hosts which miss some tool such as scp.
Cherry-picked from rocko 8ca61a5464743ff85b6d26886112750d6ddd13e0
(From OE-Core rev: 189d8282e82381d65c8cc9efe1896f628e9632bd)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We changed to make tools required by testimage to be included conditionally.
This resulted in users who use ssh for git fetching having failures.
Add ssh to HOSTTOOLS_NONFATAL to make things work for the above situation.
[YOCTO #12227]
(From OE-Core rev: 9be68b7fd09f9925c22797b0c99a3db7d460c223)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We see occasional network glitches which break this test. Use our own
mirror (which has a .gz instead of .bz2) to avoid the errors, we're not
trying to test network connectivity.
(From OE-Core rev: 01df65be2ae4bc337e10babeb9c2394d71ddff84)
(From OE-Core rev: b37a049327626ffc6413e53a2d23c55cf18af7f4)
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>
I have concerns that bad timing of the flow of data from the logger
might corrupt the output due to the way binary strings are handled
in qemurunner.
This simplifies the code to do the same thing it did before but much
more safely.
(From OE-Core rev: 20bc247316ab915465a4b1add6d09b48e07202ac)
(From OE-Core rev: 84f801e44f4b5ba65489a3a418e5f699abccd003)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 1e87283e92a2765bb5d54d17138b208bc395953b)
Signed-off-by: Armin Kuster <akuster808@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>
The logger handling in oeqa was confused at best. This patch:
a) Passes in a logger through various qemu runner pieces
b) Uses that logger consistently in the code
c) Creates a logger for QemuRunner outside the bitbake namespace
meaning we don't conflict with the tinfoil logging changes
The result of this is more consistency. For runtime tests in testimage,
the logs always contain the debug info, nothing is shwon on the console.
For the oe-selftests, logs are intercepted and only shown if the test
fails.
(From OE-Core rev: ba8babc45141891d0624f9a181a580fa416e87ec)
(From OE-Core rev: 22003f97ff7f53c32999dc466d26c1471ead9b6b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster@mvista.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>
I have no idea why we didn't do this but it means the code has nowhere
to log to unless we do this. This means we can then use the logger
to log data to the task logs.
(From OE-Core rev: 1054965a2d44df2617127c0c47e34adc62c1bf4d)
(From OE-Core rev: 93aaa0cf4f792f76d76f9f79be7fbbe59d01e910)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster@mvista.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>
Bitbake logs info messages to the console. These messages are really
there as debugging information. At the debug level, they will be shown
in failure logs and in the task logs but not on the console which
is what we want in this case.
(From OE-Core rev: 5c1cdd4f3ea59a202fff853e0390b9aa5859dc74)
(From OE-Core rev: 7274a9caa39c77128ecaf398437e685923ebc2c5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster@mvista.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>
If we don't remove the handler we end up with duplicate log messages
which is undesireable.
(From OE-Core rev: 39e6194615b139e2b772084641940fffa2c9380f)
(From OE-Core rev: 074b510c8720e82e5f5978e2824d2168f7f11139)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster@mvista.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>
The current implementation is broken when the localpath is a link.
Then only a symlink would be created on the target, instead of copying
the actual file.
[YOCTO #11524]
(From OE-Core rev: a9d446d9c42a67109ae87a156ae43dcbb0f56e1e)
(From OE-Core rev: fc0cdeca1b9820e070175a0b8d9fefa40eaed15d)
Signed-off-by: Erik Botö <erik.boto@pelagicore.com>
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Armin Kuster <akuster@mvista.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>
There are cases where the 'while loop' waiting for login prompt fails
and the bootlog variable does not get populated, thus use the the new
qemurunner member (self.msg) which stores all output coming from the qemu
process.
[YOCTO #12113]
(From OE-Core rev: 39ffa0f3779305c5e8ef86fe4572e961c5912021)
(From OE-Core rev: 40f9f0358184660f23ac7b5fc3e477e2c54e21bc)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.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>
We need QEMU PID in order to access "/proc/<qemupid>/cmdline"
Having a valid QEMU PID does not mean we can access the proc entry
immediately, we need to wait for the /proc/<qemupid> to appear
before we can access it.
(From OE-Core rev: d2d069fa9910d1c7a94c898355a63fca03ec5ad8)
(From OE-Core rev: bf05abc7931a9a9e0823b24c6f4df4f93913da82)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.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>
Ask QEMU to store the QEMU process PID in a file, this way we don't
have to parse running processes and analyze descendents.
This is done via QEMU command line argument "-pidfile".
[YOCTO #12001]
(From OE-Core rev: 67612dcd2a8a1aa1d683dddb0bd2f592886ff020)
(From OE-Core rev: 9fe7aa1824666d3f7ceb085bef59026e245cb752)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.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>
Python unittest intercepts stdout and stderr however qemurunner sets
up a streamhandler before that interception occurs, hence the messages
spam the unittest output.
By moving the logging init to the class init time, we use the unittest
stdout/stderr and this means unittest can only show the log output upon
failure. This cleans up the selftest and testimage output whilst still
showing logging upon failure.
(From OE-Core rev: 9099cecc727fe0ae5f1559582426d30ba7a9f4d3)
(From OE-Core rev: ee13216284c4d49b762eaab488f21de573d2079d)
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>
We're seeing timeouts in the autobuilder testing code. Increase these
timeouts to 120, print the length of time we're having to wait, change
the error messages to really be errors and don't print empty logs, its
not helpful, print a message about the empty log instead.
(From OE-Core rev: b87a33d9c86cc1d2ea196259020e1d3dc712ccef)
(From OE-Core rev: 4234ea8aae52347e49f848292deb0936ffd905ae)
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>
Ross Burton
Niko Mauno
Richard Purdie
Khem Raj
Maxin B. John
Fan Xin
Juro Bystricky
Andre McCurdy
Joshua Watt
Armin Kuster
Chen Qi
Erik Botö
Leonardo Sandoval