Backport upstream fix. No upstream release version of
binutils it yet, so backport the fix independently.
(From OE-Core rev: 3693a0a8b9461521b95613a76b7fd79c86a3bf8f)
Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport upstream fix. No upstream release version of
binutils it yet, so backport the fix independently.
(From OE-Core rev: a4ead72b958ded4941f96741029f4955930ba758)
Signed-off-by: Trevor Gamblin <trevor.gamblin@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oe-core e37a1ecc stopped downloading a LZMA tarball, but the checksums were not
removed at the same time.
(From OE-Core rev: 73a1e1135618a23f3f2a714c311df39c7b809ed5)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Automatic generation seems to work fine,
and does not become outdated.
(From OE-Core rev: 8993270f8bc65e152418d84fde03f8ead83c054b)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changing the gl options to qemu doesn't result in a correctly rebuilt
binary, the GL linkage can persist from a build where it was enabled
to one where it was not.
As well as clearly being incorrect and non-reproducible, this caused
some mystery failures on the autobuilder.
Cleaning ${B} at do_configure time avoids this. Most recipes
(e.g. autotools derived ones) already clean ${B} as appropriate and
avoid this issue.
(From OE-Core rev: b91b30c09ffbcd81e8dcaae832b3ae4f61046236)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 'accept' function on the socket of unfsd daemon
is always in below error state:
accept(4, 0x7ffd5e6dddc0, [128]) = -1 EINVAL (Invalid argument)
accept(6, 0x7ffd5e6dddc0, [128]) = -1 EINVAL (Invalid argument)
And 'strace -c -p <the pid of unfsd>' shows:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
70.87 0.005392 0 513886 513886 accept
29.13 0.002216 0 256943 poll
This error state is in the 'for' loop of the daemon, so it consumes 100%
CPU. The reason is that 'listen' is not called for the TCP socket before
'accept'. Actually the called 'svc_tli_create' from libtirpc will not call
'listen' on a bound socket.
(From OE-Core rev: 1f6784d2e839f81749d21ad1b615a9f7bb0e64d6)
Signed-off-by: Haiqing Bai <Haiqing.Bai@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a backported commit from upstream which helps fix build failures
in meta-oe.
(From OE-Core rev: 6665e84bfba43cd8897b9561b14975ac524fbbe2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* the (new?) ruby expects some additional compiled libraries
to run, so we need to copy them as part of ptest.
Fixes errors like:
# ruby ./runner.rb ./-ext-/vm/test_at_exit.rb
Run options:
# Running tests:
[1/1] TestVM#test_at_exit = 0.06 s
1) Failure:
TestVM#test_at_exit [/usr/lib/ruby/ptest/test/-ext-/vm/test_at_exit.rb:7]:
1. [1/2] Assertion for "stdout"
| <["begin", "end"]> expected but was
| <[]>.
2. [2/2] Assertion for "stderr"
| <[]> expected but was
| <["-:1:in `require': cannot load such file -- -test-/vm/at_exit (LoadError)",
| "\tfrom -:1:in `<main>'"]>.
* the 'erb' test can't find the erb binary, as we're not
running this from within the build directory
(From OE-Core rev: 158d5285372240f6b3502a6c715a2491e37a3118)
Signed-off-by: André Draszik <andre.draszik@jci.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In multilib builds python3-config gets renamed to eg python3-config-lib64 but
this ends up being packaged in python3-core not python3-dev.
The manifest uses an extended glob to package all python* binaries that are not
python-config into python3-core:
"${bindir}/python*[!-config]",
However, this doesn't do what was intended, as [] is a range match.
Replace the globs with more verbose but precise matches, and clear out
FILES_${PN} to ensure that new binaries don't end up in ${PN} (which shouldn't
exist).
[ YOCTO #13592 ]
(From OE-Core rev: c780f21c33b0684dafff3421600cd1c11ddd0c48)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With python3-config using the 'python-config' name, it's possible for
python-config to point at python3-config, which is obviously wrong.
(From OE-Core rev: 80a4a44d4d9da1cacda5f50ea955017502829c6d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python3-config uses distutils:
Traceback (most recent call last):
File "/usr/bin/python3-config", line 9, in <module>
from distutils import sysconfig
ModuleNotFoundError: No module named 'distutils'
Add the dependency so that distutils is always present.
[ YOCTO #13592 ]
(From OE-Core rev: 04136dbac48986dce5b2b872b2c0b46c673c44f2)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes:
# decode-dimms
Can't locate Carp.pm in @INC (you may need to install the Carp module) (@INC contains: /usr/lib/perl5/site_perl/5.28.1/x86_64-linux /usr/lib/perl5/site_perl/5.28.1 /usr/lib/perl5/vendor_perl/5.28.1/x86_64-linux /usr/lib/perl5/vendor_perl/5.28.1 /usr/lib/perl5/5.28.1/x86_64-linux /usr/lib/perl5/5.28.1 .) at /usr/lib/perl5/5.28.1/Tie/Hash.pm line 190.
BEGIN failed--compilation aborted at /usr/lib/perl5/5.28.1/Tie/Hash.pm line 190.
Compilation failed in require at /usr/lib/perl5/5.28.1/x86_64-linux/POSIX.pm line 505.
Compilation failed in require at /usr/bin/decode-dimms line 41.
BEGIN failed--compilation aborted at /usr/bin/decode-dimms line 41.
root@qt5222:~# apt-get install perl-module-carp
(From OE-Core rev: c73d2a2c0ecc99f0d6d7e6a1861ecce7a2312a57)
Signed-off-by: Ricardo Ribalda Delgado <ricardo@ribalda.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
file will automatically enable seccomp if the seccomp headers are available, but
the build will fail on Opensuse Tumbleweed because the include paths are wrong.
Enabling seccomp is a bad idea because it interacts badly with pseudo (causing
build failures), so explicitly and globally disable seccomp.
(From OE-Core rev: a752faa152df031df5acaa40491299ac115109a4)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libOptRemarks has been renamed as libRemarks
RISC-V backend is now supported
(From OE-Core rev: 7f4870132ece9efa7f1404e2620a2e05055bca12)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Version 2 of the recipe is not actually required by anything; the
lidmodulemd dependency in createrepo-c is optional, and the
libmodulemd feature is not used in YP.
(From OE-Core rev: e5bf0814f565458c1c13d305dfc80a70a060555e)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream has split version 1 of the libmodulemd recipe into
its own branch and removed version 1 from the master
branch and 2.x releases; as libdnf requires v1 of libmodulemd,
this commit introduces a v1-specific revipe.
(From OE-Core rev: e0678765b1fb66df6ec37da1d32836bee2237af1)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously the readline module would have been built regardless of
readline's presence in the sysroot, and the recipe would
fail at package_qa.
(From OE-Core rev: 79ebbca6943bc66b619671f93ac283ed2cfc8e5c)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The use case is building a gpl3-free image, without having
to rely on outdated recipes from meta-gplv2 layer.
(From OE-Core rev: 02eb487c8145e0f3d957c39cf16f6f805e95e536)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recent versions of gdbm are gplv3, so in some scenarios
it is beneficial to not depend on it.
(thanks Ross for leading the way with the db option :)
(From OE-Core rev: 88cf0b10d2e6c7f0cd08838ebe90ecdb95f31b2b)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>