ERROR: mpfr-native-3.1.5-r0 do_checkuri: Fetcher failure for URL: 'http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5.tar.xz'. URL http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5.tar.xz doesn't work
ERROR: mpfr-native-3.1.5-r0 do_checkuri: Function failed: do_checkuri
Found gnu has the same copy
(From OE-Core rev: 90e50ec8033051367f0c649e354ddf0107be3231)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The previous tarball URI seems to be gone.
Also, adjust a few things to make it actually build;
handling autotools-based projects from git checkouts is always harder
than taking them from tarballs :-(
(From OE-Core rev: b4542e867d54c56e6ef088fac28ae3d5e6c0d7bc)
(From OE-Core rev: 67aede4c4b91e333b48451c6f08835d19532abb2)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@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 don't have latex2man in HOSTTOOLs so documentaion is never built but this
dependency does cause problems on older releases like morty, pre-HOSTTOOLS.
Document the configuration explicitly in master.
(From OE-Core rev: 594966f14147edd47f46944060a21e0cff778ba2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Affected versions: curl 7.34.0 to and including 7.54.1
Not affected versions: curl < 7.34.0 and >= 7.55.0
(From OE-Core rev: a12cc7500a224d4be91f67f7921e1f16fcf880d4)
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Affected versions: libcurl 7.15.0 to and including 7.54.1
Not affected versions: libcurl < 7.15.0 and >= 7.55.0
(From OE-Core rev: eafbe104727d79643c1738360789ae455fff116c)
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Multi-threaded applications using libcurl crash
on DNS timeouts when built using OE.
The reason is as follows:
By default, libcurl implements DNS timeouts using a
timer (alarm()) and a pair of setjmp()/longjmp().
This approach is unsafe in multi-threaded applications
for various reasons, as e.g. explained in the relevant
man-pages.
To avoid this, libcurl can be compiled with a built-in
threaded resolver, or against the c-ares asynchronous
resolver library.
To keep extra dependencies to a minimum, and to mimic
other distributions (debian at least), and because
c-ares is not available in OE-core, add a PACKAGECONFIG
to be able to enable use of of the built-in threaded
resolver and enable it by default.
(From OE-Core rev: f4dbb4ce29fcd03e64c83efea39f32df437c21cc)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 41f1e44fce976c4140cda62a41349e91e69d04ef)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We were relying on running ca-certificates from the -native version. This
meant the host and target path layouts had to match which might not be true,
it certainly isn't true for the sdk builds.
There was a dependency on run-parts which wasn't represented (we can get it
from busybox or debianutils).
Since this is an allarch script, call the script directly, making sure debianutils
and openssl are available as postinst rootfs time to resolve the issues.
(From OE-Core rev: a406704fd68d08c3916b7986f96175be34affc50)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit d9575e05f2cb8bf293534c036ddc0d0336701256)
Signed-off-by: André Draszik <adraszik@tycoint.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
GitHub automatically-generated tarballs from tags can and do change over time,
so change libproxy to use the uploaded tarball.
(From OE-Core rev: 1a159da61a8a3d06918f838b1dcec45eed2815a7)
(From OE-Core rev: ea56903d4dded44845d89d7ee7208b88027512d8)
Signed-off-by: Ross Burton <ross.burton@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>
CVE-2017-12678: In TagLib 1.11.1, the rebuildAggregateFrames function in
id3v2framefactory.cpp has a pointer to cast vulnerability, which allows
remote attackers to cause a denial of service or possibly have
unspecified other impact via a crafted audio file.
Reference:
https://nvd.nist.gov/vuln/detail/CVE-2017-12678
Patch from:
eb9ded1206
(From OE-Core rev: 24ac12ecb19efc7c131c9711ba32e298ba860eb7)
(From OE-Core rev: bb90e08fbcbc7c60731aacdc4b82163507d9afdc)
Signed-off-by: Yi Zhao <yi.zhao@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>
The _asn1_check_identifier function in GNU Libtasn1 through 4.12 causes
a NULL pointer dereference and crash when reading crafted input that
triggers assignment of a NULL value within an asn1_node structure. It
may lead to a remote denial of service attack.
References:
https://nvd.nist.gov/vuln/detail/CVE-2017-10790http://git.savannah.gnu.org/gitweb/?p=libtasn1.git;a=commit;
h=d8d805e1f2e6799bb2dff4871a8598dc83088a39
(From OE-Core rev: 6176151625c971de031e14c97601ffd75a29772f)
(From OE-Core rev: 649f78102222ec156d490968c13d3222379a1956)
Signed-off-by: Yue Tao <Yue.Tao@windriver.com>
Signed-off-by: Wenzong Fan <wenzong.fan@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>
* Fixes:
ERROR: nativesdk-libcheck-0.10.0-r0 do_package_qa: QA Issue:
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/checkmk
contained in package nativesdk-libcheck requires
/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-linux/usr/bin/gawk,
but no providers found in RDEPENDS_nativesdk-libcheck? [file-rdeps]
(From OE-Core rev: 04e11808e6a22adfa367dd2565b20cb9ecdd6439)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is used in NVD for CVE's like:
https://nvd.nist.gov/vuln/detail/CVE-2016-6153
(From OE-Core rev: 2dcd0f87bc8754afba09f6a1ed68eab19228c261)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit cec6f26f4d2f16c9a58fac5a6344e3d43b36ed09)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is used in NVD database entries like CVE:
https://nvd.nist.gov/vuln/detail/CVE-2016-1951
(From OE-Core rev: 183c3b4455a6c358000a775e3e5806467726b730)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit c75e5d3f4b9293cf2f2ebdd3a23743b3df7aa3df)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is used in NVD as product name for CVE's like:
https://nvd.nist.gov/vuln/detail/CVE-2017-8786
(From OE-Core rev: 594a729950272b6596567dca1d4aa6f147ba3085)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit ce32c5b8ee77012b36c74323f298dc561741aebd)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is used in NVD for CVE's like:
https://nvd.nist.gov/vuln/detail/CVE-2017-7246
(From OE-Core rev: a561cc581ae9d9a7ae3eb90ee0563f3b47ba843c)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 523e823988f08679a384a14c4e768b2819f8a6bf)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In libgcrypt before 1.7.7, an attacker who learns the EdDSA session key (from
side-channel observation during the signing process) can easily recover the
long-term secret key. 1.7.7 makes a cipher/ecc-eddsa.c change to store this
session key in secure memory, to ensure that constant-time point operations are
used in the MPI library.
(From OE-Core rev: 6039dbfd981830b5406c25a27ccfae0e5ed016e8)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Something in the fetched webpage made the default regex matching really slow.
(From OE-Core rev: e4d1100a84e28cb97438c18df6d9f98996a7d578)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed race issue:
In file included from acl_copy_entry.c:22:0:
libacl.h:19:21: fatal error: sys/acl.h: No such file or directory
#include <sys/acl.h>
[snip]
compilation terminated.
acl_get_file.c:27:24: fatal error: acl/libacl.h: No such file or directory
#include <acl/libacl.h>
^
The acl.h is in "include" directory, and include/Makefile creates
symlink "sys" and "acl" poinst to current dirctory:
$ ls include/ -l
acl -> .
sys -> .
So if "libacl" target runs before "include", the error would happen
since no "acl" or "sys" directory.
Let libacl depend on include can fix the problem.
[YOCTO #11349]
(From OE-Core rev: 73d3d81fcdb92dd85c6ad1609e3a6eb20f1ea539)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Existing patch was actually doing the wrong thing and
sometimes removing a linking flag (-lgpgme) that should be present.
Instead, gpgme-config actually has internal logic to remove /usr/lib from the output,
which works only in non-multilib setups, so it is adjusted to include all possible
/usr/lib* and /lib* directories.
(From OE-Core rev: 84cb611079b7cf78b9921c78978943fa4adae1c7)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To fix a problem when print ERROR after a ptest timeout, this
causes the user confusion about if a test ends or not.
[YOCTO #10842]
(From OE-Core rev: 210c518ba8f8d6ec6e9d34e0df8b963a3b2e0593)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are a number of reasons that importing a module could cause output on
stderr that isn't a fatal error (compatibilty problems with inputrc, or encoding
warnings) so backport a patch from autoconf-archive to only check the exit code
instead of asserting that stderr is empty.
[ YOCTO #11231 ]
(From OE-Core rev: ebfd79ae6e5954253c3bb0886d476be480b24de8)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Re-order some assignments to be logically arranged.
Remove the set -ex statements as they serve no purpose.
Pass --debug-configuration to see what configuration steps boost is taking.
(From OE-Core rev: 2dc4796f02ecdc99ee3c51c668e8d9090e68a655)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As Python 3 is the default Python version, change Boost to build against Python
3 instead of Python 2 if enabled. It's not simple to support both, so this
means that support for building boost-python against Python 2 has been removed.
This involves backporting a number of patches upstream to fix Python 3 support,
and telling Boost precisely where to find the Python headers and libraries so
that it doesn't try to invoke the host Python to determine these values.
[ YOCTO #11104 ]
(From OE-Core rev: 0f5418eb0ce12811b16d2e3c28c28140a509f685)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rename local function to avoid conflicts with compiler intrinsics
(From OE-Core rev: fcfbbae9fdda539665a1e8bfe292f917bd5a1927)
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>
Building the C++ bindings for native requires a host C++ compiler with
C++11 support. Since these bindings are currently not needed, we can
disable them and thus avoid increasing the requirement for the host C++
compiler.
(From OE-Core rev: 052547561f3b2c13d357da87061716c6eb968fb9)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To fix:
file /usr/share/man/man1/which.1 conflicts between attempted installs
of debianutils-doc-4.8.1-r0.core2_64 and which-doc-2.21-r3.core2_64
(From OE-Core rev: ba304046307cd741694b25215b562d5f05c9c7a5)
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It breaks rpm 4.x because musl is printing an error message
when the symbol is not found, and rpm takes it as an actual error.
(From OE-Core rev: ff750c42e2eb5e9ddb5ef438e571d708ec0adf77)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Version 6.x of Berkeley DB has been rejected by open source community due to its hostile
AGPLv3 license; both Fedora and Debian are sticking with db 5.x - and by extension,
all the open source projects are still developed and tested with db 5.x
In oe-core the only thing that was requiring db 6.x was rpm 5.x, and so there's no reason
to continue carrying db 6.x in oe-core. If someone needs API features that are only available in
db 6.x, it can be re-added to meta-oe.
(From OE-Core rev: 2694de76542840f79e3953c546d07b8ae479b8a1)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As it varies from one machine to another.
(From OE-Core rev: e34ac7634a6d1f110ee4748de813e7b1fd89d119)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace some "+=/=+" with "=" when setting BBCLASSEXTEND, they are
redundant and inconsistent with the same setting in other recipes.
(From OE-Core rev: 09266d6c91acd8ba4df6e8242aa44d9ba41e9cee)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Was detected in Martin's world build
(From OE-Core rev: ef9dfc361e5e97157d05dfeaf67a3e872648d372)
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gpgme failed when configuring since you can only configure for one python
system at a time (via the inherits). So we need to have a PACKAGECONFIG
that defines which one [or neither] you want to use.
The prior pkgconfig patch introduced the usage of the variable PKG_CONFIG,
which is not defined anywhere. Define this.
When building the python module, we can not call gpg-error-config, so we
need to find an alternative way of finding the information the setup.py.in
requires. (In this case, it's easy to just use the environment
STAGING_INCDIR.)
(From OE-Core rev: 839d6f124c2761194c868cf5597e1aa96571e1ca)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These are recipes where the upstream has moved to GPLv3 and these old
versions are the last ones under the GPLv2 license.
There are several reasons for making this move. There is a different
quality of service with these recipes in that they don't get security
fixes and upstream no longer care about them, in fact they're actively
hostile against people using old versions. The recipes tend to need a
different kind of maintenance to work with changes in the wider ecosystem
and there needs to be isolation between changes made in the v3 versions
and those in the v2 versions.
There are probably better ways to handle a "non-GPLv3" system but right
now having these in OE-Core makes them look like a first class citizen
when I believe they have potential for a variety of undesireable issues.
Moving them into a separate layer makes their different needs clearer, it
also makes it clear how many of these there are. Some are probably not
needed (e.g. mc), I also wonder whether some are useful (e.g. gmp)
since most things that use them are GPLv3 only already. Someone could
now more clearly see how to streamline the list of recipes here.
I'm proposing we mmove to this separate layer for 2.3 with its future
maintinership and testing to be determined in 2.4 and beyond.
(From OE-Core rev: 19b7e950346fb1dde6505c45236eba6cd9b33b4b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For mingw32 targets do not attempt to replace the
syscfg/lock-obj-pub.*.h as for mingw32 there are no arch specific
headers that are included in the libgpg-error source.
(From OE-Core rev: 45a5253a6c8d3e394c1a74491b95fc63a1616646)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Armin Kuster
Oleksandr Kravchuk
Alexander Kanavin
Richard Purdie
Armin Kuster
André Draszik
Ross Burton
Yi Zhao
Yue Tao
Khem Raj
Martin Jansa
Mikko Rapeli
Fan Xin
Andre McCurdy
Robert Yang
Aníbal Limón
Peter Kjellerstedt
Amarnath Valluri
Paul Gortmaker
Ming Liu
Andreas Müller
Mark Hatle
Nathan Rossi