An elevation of privilege vulnerability in libnl could enable a local
malicious application to execute arbitrary code within the context of
the Wi-Fi service. This issue is rated as Moderate because it first
requires compromising a privileged process and is mitigated by
current platform configurations. Product: Android. Versions: 5.0.2,
5.1.1, 6.0, 6.0.1, 7.0, 7.1.1. Android ID: A-32342065. NOTE: this
issue also exists in the upstream libnl before 3.3.0 library.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-0553
Backport fix from upstream libnl 3.3.0 release:
3e18948f17http://lists.infradead.org/pipermail/libnl/2017-May/002313.html
(From OE-Core rev: f452fbc5d2ffb9c1417079574bed0dfcdc44787a)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
termlib needs to be disabled on some targets e.g. mingw
this change paves the way for doing that. Functionally
it does not change anything for other platforms
(From OE-Core rev: 88f33e1e5ba4f85093f60a296cba3ee1c1341c43)
(From OE-Core rev: 82fc84b059367917690336d279cd8cab679d63ed)
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>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The isELF function works by running:
result = file <pathname>
if 'ELF' in result
By default 'file' will prepend the result with the path name of the file
that is being checked. This usually works fine, such as:
$ file /home/foo/openembedded-core/meta/classes/package.bbclass
/home/foo/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines
However, if the path includes 'ELF', ELF will end up in the result, and then
the check will return positive.
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
/home/ELF/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines
This will then result in the isELF coming back true, and possibly causing the
checks that use isELF, such as the 'is it already stripped' check, to do the
incorrect thing.
Adding the '-b' option to file will result in the path being omitted in the
result:
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
Python script, ASCII text executable, with very long lines
(From OE-Core rev: b6d5729a0f0e6f2c8b36d425a18e9e2ed26f5de0)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 5a324e9b2cf6378f8eaa4e394f9cb36d4e2680ac)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Apparently there are recipes in the wild which generate files with
filenames containing '$' characters - which cause errors during
packaging.
Instead of adding another special case to escape '$' characters when
constructing the command passed to oe.utils.getstatusoutput(), switch
to using single quotes to quote the path - and therefore make isELF()
consistent with the way filenames and paths are quoted by every other
caller of oe.utils.getstatusoutput() in oe-core.
(From OE-Core rev: 080f0ee910684beb8bc263d5a45d3aa39b6ee647)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit 7877761534b0c2492da6289e9f2269d41b6ed464)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 46ddc11a8be79515b4ab9f9f7568c3d624ac72fe.
The change is good in master but became subtly broken during the
backport to rocko. Either the path passed to file should be quoted
using double quotes (with any " chars in the path being escaped) or
the path should be quoted using single quotes (and then any " chars
in the path should NOT be escaped). Escaping " chars and using single
quotes will cause problems for filenames containing " chars.
(From OE-Core rev: 534a4e6775e5b4030619b20ae1f6a319adadccf5)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The dot releases are maint only.
2.4.4 included:
CVE-2017-17742: HTTP response splitting in WEBrick
CVE-2018-6914: Unintentional file and directory creation with directory traversal in tempfile and tmpdir
CVE-2018-8777: DoS by large request in WEBrick
CVE-2018-8778: Buffer under-read in String#unpack
CVE-2018-8779: Unintentional socket creation by poisoned NUL byte in UNIXServer and UNIXSocket
CVE-2018-8780: Unintentional directory traversal by poisoned NUL byte in Dir
2.4.3 includes:
CVE-2017-17405: Command injection vulnerability in Net::FTP
(From OE-Core rev: 7003a36ef3f686af97798ff6f4bc7b3473f937de)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* with RSS used in pyro this script isn't very useful anymore
* RSS makes sure that the dependencies are almost always deterministic
the only case known to me where dependencies are different based on
what was already built in TMPDIR are runtime dependencies resolved
by shlibs code in package.bbclass (which is using global pkgdata, not
specific to given recipe and its RSS) as described here:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9217#c4
but for this case it's not worth running complete test-dependencies.sh
runs
(From OE-Core rev: 522005e722ceb1d1447826e6d7a36d43e49d0450)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: ded47001bec3fbbcbcdbe358a32c14ed0322d431)
Updating is safer than backporting the CVE fixes.
Included CVE:
CVE-2017-16548
CVE-2017-15994
CVE-2017-17434
CVE-2017-17434
CVE-2018-5764
plus many bugfixes
(From OE-Core rev: 3f244c68defd45d89107ff58a95c8d4462faeaed)
Signed-off-by: Yi Zhao <yi.zhao@windriver.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>
Its possible some dynamic runtime library in the dependency chain may
come from sstate and link to libraries which need the libc from
uninative. If we don't do this and binaries are run at do_install time
they would fail to find the symbols from the later libc. Examples:
cmake-native do_install:
bin/cmake: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by TOPDIR/tmp/work/x86_64-linux/cmake-native/3.10.3-r0/recipe-sysroot-native/usr/lib/libexpat.so.1)
dbus-native do_install:
tmp/work/x86_64-linux/dbus-native/1.12.2-r0/build/bus/.libs/lt-dbus-daemon: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x32/build/build/tmp/work/x86_64-linux/dbus-native/1.12.2-r0/recipe-sysroot-native/usr/lib/libexpat.so.1)
This issue is resolved when the interpreter is changed at sstate unpack
time but this isn't soon enough to avoid issues at compile/install time.
By specifing which dynamic linker/loader to use at compile time, this
race window is removed entirely.
(From OE-Core rev: 35867ee035030ab76fc9ccdb0eb1c3f80126301c)
(From OE-Core rev: cead3c4925d39f8adc328007d8a8c1b23cc72842)
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 have a problem when for example, a glibc 2.27 based system builds some
library like libpopt-native and puts it into sstate then it is reused
on a pre glibc-2.27 system to build something which depends on popt like
rpm-native. This results in an error like:
recipe-sysroot-native/usr/lib/libpopt.so: undefined reference to `glob@GLIBC_2.27'
In the past we've had this problem with new symbols like getrandom and
getentropy, here its with a more complex symbol where there is an old
version and a newer version.
We've looked into various options, basically we cannot link against our
uninative libc/ld.so since we don't have the right headers or compiler
link libraries. The compiler doesn't allow you to switch in a new set
either, even if we did want to ship them. Shipping a complete compiler,
dev headers and libs also isn't an option.
On the other hand if we follow the ld man page, it does say:
"""
The reasons for allowing undefined symbol references in shared libraries
specified at link time are that:
- A shared library specified at link time may not be the same as the one
that is available at load time, so the symbol might actually be
resolvable at load time.
"""
which is exactly this case. By the time the binary runs, it will use
our uninative loader and libc and the symbol will be available.
Therefore we basically have a choice, we get weird intermittent bugs,
we drop uninative entirely, or we pass this option.
If we pass the option, we can drop the other workarounds too.
(From OE-Core rev: 75a62ede393bf6b4972390ef5290d50add19341a)
(From OE-Core rev: d18bf7fa8e80d6cfaf3fdbe1ab06eec84b954432)
(From OE-Core rev: 4545f5436a5a106154680825ecb1cb60437faa91)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Clean up for Rocko context]
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We just ran into an issue where tar failed to build on one server setup
but built everywhere else just fine.
It was running makeinfo to regenerate some docs files and makeinfo was too
old for the host it was running on. There was no dependency on makeinfo-native
as it was not meant to be regenerating the docs.
It was being regenerated as a date from a timestamp used in the docs
was different in Asian timezones than in the other timezones our builds
were being tested in.
I added an entry to https://wiki.yoctoproject.org/wiki/TipsAndTricks/
about how this was debugged.
As such, lets default to setting and exporting TZ to 'UTC' as was already
pioneered by the reproducibile builds work. This makes the builds
deterministic.
[YOCTO #12665]
(From OE-Core rev: 2a90ae7a3286724ff9e3615c4dbf56038f703810)
(From OE-Core rev: e31f31f81efe4b60938b724bece2a03c7c74a68d)
(From OE-Core rev: 2c72aa56e6065100582cb17f281c4c11521712e6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Drop simple.bbclass changes]
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This includes the libxcrypt change which allows uninative to work on fedora28.
(From OE-Core rev: 4b27ab6487a54b42a52aa16e98ea4d19fa62b5ae)
(From OE-Core rev: 0685eb697f1dfa3b858b6e594cbd8e6070b4fbb8)
(From OE-Core rev: 2b462bdc2b9bad40425769ece380e46b52cca095)
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 isELF function works by running:
result = file <pathname>
if 'ELF' in result
By default 'file' will prepend the result with the path name of the file
that is being checked. This usually works fine, such as:
$ file /home/foo/openembedded-core/meta/classes/package.bbclass
/home/foo/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines
However, if the path includes 'ELF', ELF will end up in the result, and then
the check will return positive.
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
/home/ELF/openembedded-core/meta/classes/package.bbclass: Python script, ASCII text executable, with very long lines
This will then result in the isELF coming back true, and possibly causing the
checks that use isELF, such as the 'is it already stripped' check, to do the
incorrect thing.
Adding the '-b' option to file will result in the path being omitted in the
result:
$ file /home/ELF/openembedded-core/meta/classes/package.bbclass
Python script, ASCII text executable, with very long lines
(From OE-Core rev: 5a324e9b2cf6378f8eaa4e394f9cb36d4e2680ac)
(From OE-Core rev: 46ddc11a8be79515b4ab9f9f7568c3d624ac72fe)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[fixup for Rocko]
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When it was something else than /usr/libexec (e.g. when
installing native SDK packages), things broke down.
(From OE-Core rev: d99e819a6cbde6d1116c434ddba4c5f8eca7e6d8)
(From OE-Core rev: 1c8c163bfb736518f66276eca5765c493b8cc787)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
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>
When uninative is activated (poky's default) internal datastore variables are modified (NATIVELSBSTRING and SSTATEPOSTUNPACKFUNCS) to enable uninative
support. This is happening after parsing is done at the beginning of the build. On the next bitbake call the recipe would be parsed if the two
variables above were not added to the parsing whitelist BB_HASHCONFIG_WHITELIST.
The fix is to add these two variables to the recipe parsing whitelist BB_HASHCONFIG_WHITELIST, this is done at recipe parsing time, only when
uninative.bbclass is used.
(From OE-Core rev: 75bb95ada98ef129d2fa48568f27dddb078c852c)
(From OE-Core rev: ca52b8e4f32063234815493746c4059392862af8)
Signed-off-by: Cuero Bugot <cbugot@sierrawireless.com>
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>
By default, RPM_SIGN_PACKAGES is not defined. Add gpgcheck=0 to
oe-remote-repo.repo file, otherwise dnf will complain during
install operation on target
Note, RPM_SIGN_PACKAGES is set only when you inherit sign_rpm explicitly
(From OE-Core rev: 002a71eaa7606828c399972d8fd35e19e7b71929)
(From OE-Core rev: 21ca5428fa320aa4c925fe8a1a141c7df863fa84)
Signed-off-by: Manjukumar Matha <manjukumar.harthikote-matha@xilinx.com>
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>
If a fr_FR locale is found, it is automatically tested. The test
will fail if the locale is UTF-8, as the test blindly assumes
(and expects) a non-UTF fr_FR locale.
The remedy is to skip the test.
[YOCTO #12215]
(From OE-Core rev: 4cedddb83623c79980b354642dfeaf78218ca4b7)
(From OE-Core rev: ebb6c4f6a2bb6a6be4b3c4f8b7095bad529c62ea)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
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>
The recipes were using 'basename' to turn '/usr/lib' into 'lib', which breaks when libdir is '/usr/lib/tuple', leading to libraries ending up in '/usr/tuple', which isn't in FILES_*. Change the logic to use sed to strip the prefix instead.
(From OE-Core rev: e58d5521c7bae8daafdac85754545be176550a02)
(From OE-Core rev: 373763d4f6668c3e324edf8d699c8c15d0267278)
Signed-off-by: Koen Kooi <koen.kooi@linaro.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
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>
The patch tool will apply patches by default with "fuzz", which is where if the
hunk context isn't present but what is there is close enough, it will force the
patch in.
Whilst this is useful when there's just whitespace changes, when applied to
source it is possible for a patch applied with fuzz to produce broken code which
still compiles (see #10450). This is obviously bad.
We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For
that to be realistic the existing patches with fuzz need to be rebased and
reviewed.
(From OE-Core rev: 7baba7a19c5610a63ccbfd6a2238667772b32118)
(From OE-Core rev: 95b5ec1d6d614ebd1ea3a57bbbcef33b08966265)
Signed-off-by: Ross Burton <ross.burton@intel.com>
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 <akuster@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipes which use a shared workdir (e.g. gcc-runtine and libgcc) can
race over temporary files causing interesting build failures.
Using B instead of S avoids this problem.
[YOCTO #12605]
(From OE-Core rev: d6c13a5ff441f7076eb327c0d0b747bd7603db0f)
(From OE-Core rev: 9c72ddb605f1f4fc98fa427e37b5ba8c8758c6cd)
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>
Integrating the following commit for the 4.12+ kernels:
Author: Nathan Rossi <nathan@nathanrossi.com>
Date: Wed Mar 21 00:10:02 2018 +1000
features/wifi: Add WiFi driver fragments for various vendors/interfaces
This change adds WiFi driver configuration fragments. The fragments are
split into vendor and interface files to allow for easy selection of
drivers for specific interface types (USB, PCI, SDIO) which is useful
for BSPs with specific interfaces. The specific vendor/interface config
fragments can be included by specific BSPs in its .scc files.
However .scc files (wifi-*.scc) are provided to allow enabling interface
specific or all interfaces drivers via KERNEL_FEATURES or inclusion via
other .scc files. And wifi-common.scc is provided to enable the base
config options required for all WiFi drivers, which is done to ensure
correct configuration for default no config setups (e.g.
linux-yocto-tiny).
This patch only enables a limited set of drivers, which is based on what
the common-pc-wifi.cfg fragment sets as well as some additional drivers,
that primarily appear in USB WiFi devices.
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
This gives us a much better granularity of drivers and a good baseline for
future improvements.
The 4.12 fragments are also slightly re-organized on top of this commit
to avoid patch failures when including the new frags.
(From OE-Core rev: c24d6863768a64b2c1632d5202790689a1164694)
(From OE-Core rev: 9e1bc0e552d7609428cb71bda7d2b6b726146c21)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Removed upsupported kernels]
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Via the -stable updates, and other configuration changes the 4.12 kernel has the
same dependency on openssl headers as 4.14+.
So we add the same DEPENDS line that we already have in newer kernels to avoid the
following error:
| HOSTCC scripts/sign-file
| build/tmp/work-shared/qemux86-64/kernel-source/scripts/sign-file.c:25:30: fatal error: openssl/opensslv.h: No such file or directory
| compilation terminated.
| scripts/Makefile.host:107: recipe for target 'scripts/sign-file' failed
| make[3]: *** [scripts/sign-file] Error 1
| make[3]: *** Waiting for unfinished jobs....
(From OE-Core rev: 80f6840baecb8b161f6443f3dd1af4e70b5e5221)
(From OE-Core rev: 8660345a665ef74828036c89257bc23246243c40)
Signed-off-by: Bruce Ashfield <bruce.ashfield@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>
Debian anonscm service in Alioth is shutdown and thus
fetching sources fails.
https://wiki.debian.org/Alioth
"Alioth is broken, and there is nobody around to fix it. Don't ask the remaining people who give it life support to implement fixes and changes. It is being replaced by a cocktail of ?GitLab (see Salsa), read-only repos and keep-alive mechanisms. See below for more information."
https://wiki.debian.org/Salsa
"What is Salsa?
Salsa is the name of a collaborative development server for Debian based on the gitlab software. Salsa is supposed to provide the necessary tools for package maintainers, packaging teams and other Debian related individuals and groups for collaborative development.
What is the status of Salsa?
After various discussions about the future of Alioth, the Alioth Sprint in August 2017 gave birth to the initial setup of the the upcoming Salsa service. The productive weekend resulted in a working prototype and was launched as a beta in December 2017. It left its beta status in January 2018."
(From OE-Core rev: 08ff7b42d8b7d06ef61255185c95e900ada8769b)
(From OE-Core rev: 407de0c37ba21aff49b9fd43ee74ea4af28d19d4)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
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>
Debian anonscm service in Alioth is shutdown and thus
fetching ca-certificates sources fails.
https://wiki.debian.org/Alioth
"Alioth is broken, and there is nobody around to fix it. Don't ask the remaining people who give it life support to implement fixes and changes. It is being replaced by a cocktail of ?GitLab (see Salsa), read-only repos and keep-alive mechanisms. See below for more information."
(From OE-Core rev: fc20ff2003cee7ee3b78ba3bc236a60a8caabc35)
(From OE-Core rev: 127d1d68346bece34ccd8f6203976e2399c31a92)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
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>
Debian anonscm service in Alioth is shutdown and thus
fetching ncurses sources fails.
https://wiki.debian.org/Alioth
"Alioth is broken, and there is nobody around to fix it. Don't ask the remaining people who give it life support to implement fixes and changes. It is being replaced by a cocktail of ?GitLab (see Salsa), read-only repos and keep-alive mechanisms. See below for more information."
(From OE-Core rev: 8fab5794218445ddb3e8f73a74fa3f130e7c42f6)
(From OE-Core rev: fd64bf2dab8f259fb5e3d04e1a2af09e0775adc5)
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
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>
Since v7.51.0, libidn2 is the only available option, libidn
support was dropped.
The configure option was renamed as of v7.53.0
Therefore, curl unconditionally tries to build against libidn2,
which in particular is a problem for curl-native, as that might
or might not build against the build-machine's libidn2 now,
which furthermore causes problems when trying to share sstate
between multiple build machines.
We therefore see the following in the config log:
...
checking whether to build with libidn2... (assumed) yes
...
checking for libidn2 options with pkg-config... no
configure: IDN_LIBS: "-lidn2"
configure: IDN_LDFLAGS: ""
configure: IDN_CPPFLAGS: ""
configure: IDN_DIR: ""
checking if idn2_lookup_ul can be linked... yes
checking idn2.h usability... yes
checking idn2.h presence... yes
checking for idn2.h... yes
...
IDN support: enabled (libidn2)
...
even though this recipe tries to disable that.
While libidn2 isn't available in OE, this change at least:
* prevents curl-native to silently build against libidn2 if
that is installed on build machine, even if not requested
* alerts people who use the PACKAGECONFIG option that it's
not actually doing what they intend to do
(From OE-Core rev: 705eaea991622bdbb2ee83eefa8df8e665e3efe4)
(From OE-Core rev: 6ec8cb59b2f58784a9f74afa6018791694f8a030)
Signed-off-by: André Draszik <andre.draszik@jci.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>
1.Upgrade curl from 7.54.1 to 7.57.0.
2.Delete CVE-2017-1000099.patch, CVE-2017-1000100.patch, CVE-2017-1000101.patch, CVE-2017-1000254.patch, reproducible-mkhelp.patch, since it is integrated upstream.
3.Remove "do_install_append()" from curl_7.57.0.bb, since curl/curlbuild.h has been removed.
this update include CVE fixes for:
CVE-2018-1000007 CWE-522: Insufficiently Protected Credentials
CVE-2018-1000005 CWE-126: Buffer Over-read
CVE-2017-8818 CWE-125: Out-of-bounds Read
CVE-2017-8817 CWE-126: Buffer Over-read
CVE-2017-8816 CWE-131: Incorrect Calculation of Buffer Size
CVE-2017-1000257 CWE-126: Buffer Over-read
Most of the changes are bug fixes.
https://curl.haxx.se/changes.html
(From OE-Core rev: 215d5677004537fc190b5381157ac8b94db6d7e8)
(From OE-Core rev: 7f1029aff8abaadb25730fef50c495dcd6fc1e30)
Signed-off-by: Huang Qiyu <huangqy.fnst@cn.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Safer to upgrade than to backport CVE-2017-8818. Lots of depends patches]
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On some linux hosts image recipes will fail to build as follows:
ERROR: build-essential-0.3-r0 do_image_ext3: Usage: bbdebug [123] "message"
ERROR: build-essential-0.3-r0 do_image_ext3: Function failed: do_image_ext3 (log file is located at /opt/build/tmp/work/intel_corei7_64-wrs-linux/build-essential/0.3-r0/temp/log.do_image_ext3.43744)
ERROR: Logfile of failure stored in: /opt/build/tmp/work/intel_corei7_64-wrs-linux/build-essential/0.3-r0/temp/log.do_image_ext3.43744
ERROR: Task (/opt/layers/meta-overc/meta-build/recipes-core/images/build-essential_0.3.bb:do_image_ext3) failed with exit code '1'
Running with bitbake -v -v -v -D we get in the log file:
+ bbdebug 1 Executing 'dd if=/dev/zero of=/opt/build/tmp/work/intel_corei7_64-wrs-linux/build-essential/0.3-r0/deploy-build-essential-image-complete/build-essential-intel-corei7-64-20180220190510.rootfs.ext3 seek=484486 count=0 bs=1024'
+ USAGE='Usage: bbdebug [123] "message"'
+ '[' 3 -lt 2 ']'
+ DBGLVL=1
+ shift
++ echo 1
++ echo 1
++ tr -d t
++ tr -d t
+ NONDIGITS=1
+ '[' 1 ']'
+ bbfatal 'Usage: bbdebug [123] "message"'
The debug output tells us that the NONDIGITS check failed to remove
the digits using the tr expression. Enclosing the expression in
quotes causes it to work properly.
(From OE-Core rev: 9e6d283aa9c77685f55a62fa220226d9149ecd7a)
(From OE-Core rev: 35ed47d1fcbdd384aa804b686e1c92d22b74fc15)
Signed-off-by: Jason Wessel <jason.wessel@windriver.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>
Xiph.Org libvorbis 1.3.5 allows Remote Code Execution upon freeing
uninitialized memory in the function vorbis_analysis_headerout() in
info.c when vi->channels<=0, a similar issue to Mozilla bug 550184.
References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14632
(From OE-Core rev: a2b4718b5db8f220c89d71fbea4e3418be20731e)
Signed-off-by: Tanu Kaskinen <tanuk@iki.fi>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In Xiph.Org libvorbis 1.3.5, an out-of-bounds array read vulnerability
exists in the function mapping0_forward() in mapping0.c, which may lead
to DoS when operating on a crafted audio file with vorbis_analysis().
References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14633
(From OE-Core rev: 300b5e921460f8ab1d4870014b343eddd00e77b1)
Signed-off-by: Tanu Kaskinen <tanuk@iki.fi>
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: c1b711e265e2ff6ba74b0f6f568f231ddf476f8b)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LICENSE file contains a list of files and addtional files were added to
the list, license was unchanged.
(From OE-Core rev: f6372633b481fc267c1983a5276616513ec778a9)
(From OE-Core rev: 173f3534a7217074f7291d42b1d572242bc710e0)
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>
ERROR: distcc-3.2-r0 do_fetch: Fetcher failure: Unable to find revision d8b18df3e9dcbe4f092bed565835d3975e99432c in branch 3.2 even from upstream
ERROR: distcc-3.2-r0 do_fetch: Fetcher failure for URL: 'git://github.com/distcc/distcc.git;branch=3.2'. Unable to fetch URL from any source.
ERROR: distcc-3.2-r0 do_fetch: Function failed: base_do_fetch
[v2]
upstream deleted the branch and the hash no longer exists.
Took the git snapshot from yocto and created a copy on my github.
There was no offical 3.2 release, only rc versions.
(From OE-Core rev: 22d30ed7c847b6ee4fdccb96fa9a3ce3d1491967)
Signed-off-by: Armin Kuster <akuster@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
glibc 2.27 added function copy_file_range(), and e2fsprogs happens to
have a different function with the same name. The conflict made
e2fsprogs-native build fail.
Here's a backport of a fix from upstream, the fix was released in
e2fsprogs 1.43.8.
The master branch doesn't need this fix, since it has new enough
e2fsprogs version. At least rocko, pyro and morty need this, I haven't
checked older stable branches. Apparently the problematic function was
introduced in e2fsprogs version 1.43.
(From OE-Core rev: 0dbe43e520be5e60e3a98fc0e46358bb291b0c13)
Signed-off-by: Tanu Kaskinen <tanuk@iki.fi>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve reproducible build of:
openssl-staticdev
openssl-dbg
libcrypto
There are two main causes that prevent reproducible build, both related to
the generated file "buildinf.h":
1. "buildinf.h" contains build host CFLAGS, containing various build
host references. We need to pass sanitized CFLAGS to the script
generating this file ("mkbuildinf.pl". )
2. We also need to modify the script "mkbuildinf.pl" itsel in order to
generate a build timestamp based on SOURCE_DATE_EPOCH, if present in
the environment.
(From OE-Core rev: 6c556ed3553d8f5e75d65cd7db92b26df43846b7)
(From OE-Core rev: 5a7cf3296715ac6543a171984fd09168bf73d1af)
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>
Fix a crash when generating a txt report and the two commits to be
compared were not consecutive (but there were some tested commits
between them).
(From OE-Core rev: f3afd2c47f4c740df52dfd80e208ce721d5ebf6e)
(From OE-Core rev: 00b197b2fb2253f2c5c534b16cc2d3d55aad6352)
Signed-off-by: Markus Lehtonen <markus.lehtonen@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>
Nativesdk package has a special arrangement where the same thing is done
in do_install(). It was assumed (in the comment) that postinsts don't run when
installing nativesdk packages, but this was incorrect: they are run, but
any failures were previously silently ignored. Now this missing failure reporting has
been fixed, and so we get to see the failures.
(From OE-Core rev: 8ebb695c1429f8d57d655072a362a4f176258699)
(From OE-Core rev: 31f69f8fd8a08fadee0ea288214aa33c33ad6912)
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>
Integrating the following commits:
60b649971940 x86/hibernate/64: Mask off CR3's PCID bits in the saved CR3
cec3c008ec8f drm/i915/cfl: Coffee Lake works on Kaby Lake PCH.
073873cb152c brd: remove unused brd_mutex
912c53b1b346 audit: fix memleak in auditd_send_unicast_skb.
(From OE-Core rev: 3c14c6612c48d46677837f5f4c31cfd1a6ff6174)
(From OE-Core rev: 39202a1d0714e91dff6c18b1043fd236df25434f)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.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>
Integrating the following warning backport:
commit eb371933cf4d3495d0899880b2e0e252ce9db517 upstream.
Coffee Lake CPU on Kaby Lake PCH is possible.
It does exist, and it does work.
The only missed case was this warning here noticed
by Wendy who could get one system with this configuration
and reported the issue for us:
Hardware Configuration
Board ID KBL S DDR4 UDIMM EV CRB
Processor Intel® Processor code named Coffee Lake S, (6+2), 6 cores 12 threads, GT2, A0 (Internal) (QNJ4)
[ 3.220585] WARNING: CPU: 10 PID: 206 at drivers/gpu/drm/i915/i915_drv.c:340 i915_driver_load+0x1210/0x1660 [i915]
[ 3.221312] Modules linked in: hid_generic usbhid i915 i2c_algo_bit drm_kms_helper e1000e syscopyarea sysfillrect sysimgblt nvme fb_sys_fops ptp ahci i2c_hid drm pps_core nvme_core libahci wmi hid video
[ 3.222050] CPU: 10 PID: 206 Comm: systemd-udevd Not tainted 4.13.0-rc5-intel-next+ #1
[ 3.222706] Hardware name: Intel Corporation Kabylake Client platform/KBL S DDR4 UDIMM EV CRB, BIOS KBLSE2R1.R00.X089.P00.1705051000 05/05/2017
Cc: Wendy Wang <wendy.wang@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170821235056.9015-1-rodrigo.vivi@intel.com
Signed-off-by: Liwei Song <liwei.song@windriver.com>
(From OE-Core rev: 62acf087dca83ff094b1c0300b5752978807ca17)
(From OE-Core rev: 690075e07e39f28cd076ef66c9b49ab6a46457b6)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[Fixup to bypass the aufs & systemtap changes]
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
From: "Kexin(Casey) Chen" <Casey.Chen@windriver.com>
Forward port linux-yocto-4.8's patch to fix the build warning.
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.8/commit/?h=standard/base&id=7e0dd2f2b0971f0e3191e1ddc088e09eb9855567
fs/aufs/debug.h:95:19: warning: comparison of constant '0'
with boolean expression is always false [-Wbool-compare]
if (unlikely((e) < 0)) \
^
fs/aufs/vdir.c:852:2: note: in expansion of macro 'AuTraceErr'
AuTraceErr(!valid);
^~~~~~~~~~
In expansion of AuTraceErr(!valid), comparison of (!valid)
and constant '0' always passes unlikely(x) false. function
'static int seek_vdir(struct file *file, struct dir_context *ctx)'
is to find whether there is a valid vd_deblk following ctx->pos.
return 1 means valid, 0 for not. Change to AuTraceErr(valid - 1)
makes more sense.
Signed-off-by: Kexin(Casey) Chen <Casey.Chen@windriver.com>
Signed-off-by: Dengke Du <dengke.du@windriver.com>
(From OE-Core rev: 1ba624ec410b13da9645efe7bc72908195c08259)
(From OE-Core rev: 20a7e72a1fa97f673de12856b3bf53c48a05a834)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.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>
I don't know how this made it in, but the backported patch most definitely
fails to apply:
ERROR: lame-3.99.5-r1 do_patch: Command Error: 'quilt --quiltrc /home/ak/development/poky/build-musl/tmp/work/core2-64-poky-linux-musl/lame/3.99.5-r1/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:
Applying patch CVE-2017-13712.patch
patching file libmp3lame/id3tag.c
Hunk #1 succeeded at 195 with fuzz 1 (offset 1 line).
Hunk #11 succeeded at 1023 (offset 24 lines).
Hunk #12 FAILED at 1051.
The reason we have't seen it is that LICENSE_FLAGS_WHITELIST += " commercial"
needs to be in config to trigger this.
This reverts commit fd994b5bed.
(From OE-Core rev: 93aa9a5be30bbd6d9a39beb436a21bcfccceb9a7)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- No need to use bb.utils.which() as subprocess will search $PATH
- Clarity flow by moving the install inside the try/except
(From OE-Core rev: f4d22b7195dd8f08fe26dd353c7e860208e87d6a)
(From OE-Core rev: 92a0359b1e2558b175374a81a1d6146724cd1a9e)
(From OE-Core rev: 409e2e8c2b8f99d6f3d5930047f29649a1e62888)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're building a SDK and we're using glibc so may be installing locales,
add a build-dependency on natiesdk-glibc-locale so the locales we need will
exist.
(From OE-Core rev: 8d6869a0a89d8cf3c6e57723fab2750ba2c885db)
(From OE-Core rev: 602fad36954a8e6a31b1c4d7a3ac9c002dcc8b8d)
(From OE-Core rev: 6b573f8304a39780db3fd71ade6d5495cf8079d1)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As glibc 2.27 can't read older locale-archives, SDKs using glibc 2.27 on hosts
using glibc earlier than 2.27 won't be able to find any locales, so bitbake
won't start and Python can't use UTF-8.
So by default install all locales into the SDK. Special-case Extensible SDKs by
installing no locales as they ship glibc in a buildtools, and that will have the
locales.
Locale installation requires cross-localedef, so add that to DEPENDS.
Also remove the explicit en_US addition in buildtools-tarball as it is now
redundant.
(From OE-Core rev: 96896568d197cd06302713c24c0f7d91bfaea6c1)
(From OE-Core rev: 8327d50ef66c94592d76b42e147011daafc6a7c3)
(From OE-Core rev: 8859d60d48918d763213470429288553adaa419c)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using glibc-locale to install locales only makes sense if we're using glibc.
(From OE-Core rev: 8fc80734053645fa893694dfe33ddaee99aa9a1a)
(From OE-Core rev: e75b001444a5cb7bf6d91003d973cf3f9d84dae3)
(From OE-Core rev: 6ea3e46b60c89b37afadc186008dec3f0a39a69d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
localedef has no way to specify which locale archive to use, and the
compile-time default isn't useful as it points to the work directory.
Add support to read an environmental variable for the path, and don't fail to
write a new locale archive.
(From OE-Core rev: bf0f205a3c3714926649bd69db29e4df1c0ea112)
(From OE-Core rev: 14bcbecb6c19367ae0864a27750c8ea24681d48f)
(From OE-Core rev: 6c7c5f3e23278067a8585debe32dfd0955090b91)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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: 6456fceed311bcf5b3b9c7682448e51210278d1f)
(From OE-Core rev: db88ef58e5ce0b5d9b24a9bda0cd16a16a54ae6f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After commit edcf39820f the beaglebone
builds fail to mount the boot partition as it is specified in
/etc/fstab with the device node /dev/mmcblkp1. With systemd in
particular this is considered an error and the system drops into
emergency mode.
(From meta-yocto rev: f97e0e8beef8ce115ecaf40971def8ff3a0cfecd)
Signed-off-by: Drew Moseley <drew.moseley@northern.tech>
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix an internal compiler error on PPC from building a specific test:
$ $CC -S 7d-02.c
7d-02.c: In function â:
7d-02.c:11:5: internal compiler error: in copy_to_mode_reg, at explow.c:612
vec_st(v, i*16,p);
^~~~~~
The failure appears to happen on all optimizations levels as well.
(From OE-Core rev: b042347ee8cdbd2dfb0c2f616a94c4cca4b0ecd1)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Whenever "-mno-sse" is used, "-mfpmath" should be set to 387.
The test case should be modified accordingly as below:
/* { dg-additional-options "-mno-sse -mfpmath=387 " { target { i?86-*-* x86_64-*-* } } } */
Original patch from: RAGHUNATH LOLUR <raghunath.lolur@kpit.com>
(From OE-Core rev: b3d0d7b599d605568abdb45057d3f6fbc80224d9)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Create busybox-inittab recipe to produce machine-specific package with /etc/inittab
and necessary getty calls for a machine, based on SERIAL_CONSOLES, similar to how
sysvinit-inittab was done
* Since CONFIG_FEATURE_USE_INITTAB is controlled by VIRTUAL-RUNTIME_init_manager, make
main busybox package RDEPENDS on busybox-inittab when init_manager is set to busybox
(From OE-Core rev: afb09abd2f0f7555ba156260a87fd3867f591310)
(From OE-Core rev: b96bc3d6e575dab3a39634f5b22a199c4f9fc892)
Signed-off-by: Denys Dmytriyenko <denys@ti.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>
When running bitbake -c populate_sdk <image_name>, it is expected that
packages matching SDKIMAGE_INSTALL_COMPLEMENTARY name mask (unless
declared in PACKAGE_EXCLUDE_COMPLEMENTARY) are installed to resulting
SDK. Underlying mechanism issues a package manager install call for set
of complementary packages. However the mechanism doesn't seem to inform
the user all too obviously in case the package manager command behind
install_complementary() method fails -- and since it is combined with
attempt_only=True option, user might end up wondering why several *-dev,
*-dbg packages are missing from resulting SDK.
Improve associated install() method behaviour in affected OpkgPM and
DpkgPM classes so that a problematic state of affairs becomes directly
obvious for bitbake user, resulting in shell output like:
WARNING: someimage-1.0-r0 do_populate_sdk: Unable to install packages.
Command '...' returned 1:
Collected errors:
* Solver encountered 1 problem(s):
* Problem 1/1:
* - package somepkg-dev-1.0-r0.x86 requires somepkg = 1.0-r0, but
none of the providers can be installed
*
* Solution 1:
* - allow deinstallation of someotherpkg-1.1-r1.x86
* - do not ask to install a package providing somepkg-dev
* Solution 2:
* - do not ask to install a package providing somepkg-dev
(From OE-Core rev: 2502bd591c37bf532d02dc6b37fc1e8b5224fb0a)
(From OE-Core rev: 6ea3b9c595893f9148e579dc5628c0b9a239bcc9)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 0d4459e708)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 1.9.4 fixes a number of issues in the Go compiler and is important
to get in before we start working on 1.10 inclusion.
- go1.9.1 (released 2017/10/04) includes two security fixes.
- go1.9.2 (released 2017/10/25) includes fixes to the compiler,
linker, runtime, documentation, go command, and the crypto/x509,
database/sql, log, and net/smtp packages. It includes a fix to a
bug introduced in Go 1.9.1 that broke go get of non-Git
repositories under certain conditions.
- go1.9.3 (released 2018/01/22) includes fixes to the compiler,
runtime, and the database/sql, math/big, net/http, and net/url
packages.
- go1.9.4 (released 2018/02/07) includes a security fix to “go get”.
(From OE-Core rev: 06980901ee3cbe9ccb8cd3849bf6506d7b29a9bc)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Matt Madison <matt@madison.systems>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
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: 7dccdf82d49fb11cb2a7cb205ae08311e5d43291)
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: ead79135851c7b01968375bb6f512cb79d2618ca)
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: 6cc4046bfad12cc95b67a7dc72309c6c8577c655)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport a patch to fix errors such as:
error: aggregate 'sigaltstack handler_stack' has incomplete type and cannot be defined
(From OE-Core rev: 6a3d9e53e3b3340c48af2242c9871bb2e0a763f5)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This error can appear in gdb/nat/linux-ptrace.c because of
the order in which some headers are processed:
| In file included from ../../gdb-7.11.1/gdb/nat/linux-ptrace.c:20:0:
| ../../gdb-7.11.1/gdb/nat/linux-ptrace.h:175:22: error: expected identifier before numeric constant
| # define TRAP_HWBKPT 4
| ^
| Makefile:2357: recipe for target 'linux-ptrace.o' failed
| make[2]: *** [linux-ptrace.o] Error 1
| make[2]: *** Waiting for unfinished jobs....
| make[2]: Leaving directory '/oe/build/tmp-rpb-glibc/work/aarch64-linaro-linux/gdb/7.11.1-r0/build-aarch64-linaro-linux/gdb'
| Makefile:8822: recipe for target 'all-gdb' failed
| make[1]: *** [all-gdb] Error 2
| make[1]: Leaving directory '/oe/build/tmp-rpb-glibc/work/aarch64-linaro-linux/gdb/7.11.1-r0/build-aarch64-linaro-linux'
| Makefile:846: recipe for target 'all' failed
| make: *** [all] Error 2
A patch from GDB's current master solves the issue.
(From OE-Core rev: 4aaf747099714ec11158571527396ed9e818729e)
(From OE-Core rev: 5a4f22a0cb9b1a6151256d009d06e130ddc62573)
Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org>
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: 36be209262ee1e0a7598c9437c9f8c4e926c0e35)
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: e0d856d64f9e2afd762d6d40bcc6c8dc5e06b430)
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>
The change to link libssp_nonshared.a only for musl was to move
spec file changes to config/linux.h under a conditional when
DEFAULT_LIBC == LIBC_MUSL which worked fine for all but ppc
since gcc for ppc provided its own linux.h overrides which are
used. This patch duplicates the change in those headers too
Cherry-picked from oe-core master 9d39168a6acfa1f289a4448271c0bf9caaea10ec
(From OE-Core rev: 9d265f398a97dccb19811b048b1f4a2dd9d3fdd5)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
glibc already provides the content for libssp_nonshared
in libc_nonshared.a therefore we dont need to make it
universal.
This also fixed build issues on glibc when linking statically
and using -fstack-protector
Fixed errors like
/mnt/a/oe/build/tmp/work/i586-bec-linux/aufs-util/3.14+gitAUTOINC+bdfcc0dcfc-r0/recipe-sysroot/usr/lib/../lib/libc.a(stack_chk_fail.o): In function `__stack_chk_fail': /usr/src/debug/glibc/2.26-r0/git/debug/stack_chk_fail.c:27: multiple definition of `__stack_chk_fail_local' /mnt/a/oe/build/tmp/work/i586-bec-linux/aufs-util/3.14+gitAUTOINC+bdfcc0dcfc-r0/recipe-sysroot/usr/lib/../lib/libssp_nonshared.a(libssp_nonshared_la-ssp-local.o):/usr/src/debug/gcc-runtime/7.1.0-r0/gcc-7.1.0/build.i586-bec-linux.i586-bec-linux/i586-bec-linux/libssp/../../../../../../../../work-shared/gcc-7.1.0-r0/gcc-7.1.0/libssp/ssp-local.c:47: first defined here collect2: error: ld returned 1 exit status
Cherry-picked from oe-core master d71eba26850838b2878efea3f8c392a2eb2ebbfb
(From OE-Core rev: 9ee16f7f57f37e62c1fae3b27d93de2d83b2a804)
Signed-off-by: Khem Raj <raj.khem@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: 223a0f68530571d2280f526bddbc718fa803a3dc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will make it easy to backport to rocko if needed after 2.27 is landed in master
plus it fixes the aarch64 build issue seen with binutils 2.30
(From OE-Core rev: 774e372d95c9082766477ea6dbfcd10c48ac4658)
(From OE-Core rev: cb7cf1d12377d3b9a1cc159b68fc1d841004e6dd)
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>
[fixup to align with rocko context]
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change hardcoded /lib to ${nonarch_base_libdir} to correctly adapt the
code in do_install_append_aarch64() for when usrmerge is enabled in
DISTRO_FEATURES.
(From OE-Core rev: ac373c9f760463d989d6a1eb3a14b7c5b255b9d4)
(From OE-Core rev: 1c121dcf930b0b2e9f5c6e79715864a753a2d34b)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.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>
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: a6e786e7c8bed33fa269aac99724df606829ec6f)
(From OE-Core rev: a4153060233051f5e1c1e19c4c91350581b0c0f2)
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>
This helps in compiling on graphics drivers which use
this define to differentiate between eglfs and x11 headers
e.g. mali or mesa
(From OE-Core rev: 2638482c3b2a5766d2a1377a589245664140e270)
(From OE-Core rev: 670ccc391ed95564279d36a7967d46a922d69c95)
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>
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: af250003bdda95eb8b4eebff059a654e52d2497f)
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>
2018-02-27 15:51:03 +00:00
243 changed files with 9780 additions and 8922 deletions
if bb.utils.vercmp_string(d.getVar("UNINATIVE_MAXGLIBCVERSION"), glibcver) < 0:
raise RuntimeError("Your host glibc verson (%s) is newer than that in uninative (%s). Disabling uninative so that sstate is not corrupted." % (glibcver, d.getVar("UNINATIVE_MAXGLIBCVERSION")))
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
