I updated the notes to help the user get the version of the
docs that they are interested in. Sometimes a search using the
web returns really old versions of the manual and the user
is clueless about using a manual that is not matching the
YP release they are working with.
(From yocto-docs rev: d0ef1c7edec0a28ce8a49992b71e6d3c878cdbb4)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Explicitly capture and ignore errors when trying to load the optional
'custom.xml' fixture file.
[YOCTO #12554]
(Bitbake rev: 5b26fc8e332daaed092cdbafea3f0b8e11e5e7ae)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix typo in shutdown code to kill threads when "kill -0" is not enough.
Use the '--noreload' flag for 'runserver' so that there are no extra
and unaccounted threads.
[YOCTO #12555]
(Bitbake rev: 14079cb1fd497799548c677962d89c02a6d2bf92)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
