Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit ab056c7f6065f310be4dd256ceb45f85ff981f69) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Mark Hatle [Fri, 4 May 2018 19:31:32 +0000 (12:31 -0700)]
package.bbclass: Add '-b' option to file call in isELF
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
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>
Andre McCurdy [Fri, 4 May 2018 19:31:31 +0000 (12:31 -0700)]
package.bbclass: use single quotes for path passed to file in isELF()
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.
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>
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.
Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Armin Kuster [Thu, 3 May 2018 16:00:59 +0000 (09:00 -0700)]
ruby: Update to 2.4.4
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
While installing grub and grub-efi, there are conflict files
in ${sysconfdir} ${datadir} ${bindir} ${sbindir}.
- Since all of the conflicted files are tools which is
common for grub and grub-efi, we split them (except
grub-editenv) to grub-common in grub.
- The package grub-common runtime depends grub-editenv
- The package grub-editenv runtime provides grub-efi-editenv
- Remove SYSROOT_DIRS_BLACKLIST
- The recipe grub-efi does not generate the duplicated files
and use runtime depends grub-common to instead
Debian and Fedora do the similar thing.
Debian use a common package grub-common for both of pc bios and efi,
and use package grub-pc-bin for pc bios, grub-efi-amd64-bin for efi.
Both of grub-pc-bin and grub-efi-amd64-bin requires grub-common.
https://packages.debian.org/sid/grub-common
https://packages.debian.org/jessie/grub-pc-bin
https://packages.debian.org/jessie/grub-efi-amd64-bin
Fedora use a common package grub2-tools for both of pc bios and efi,
and use package grub2 for pc bios, grub2-efi-modules for efi.
Both of grub2 and grub2-efi-modules requires grub2-tools.
https://www.rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/g/grub2-tools-2.02-0.34.fc24.x86_64.html
https://www.rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/g/grub2-2.02-0.34.fc24.x86_64.html
https://www.rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/g/grub2-efi-modules-2.02-0.34.fc24.x86_64.html
Martin Jansa [Wed, 25 Apr 2018 14:07:14 +0000 (14:07 +0000)]
scripts/test-dependencies.sh: remove
* 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
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Armin Kuster <akuster808@gmail.com>
Martin Jansa [Wed, 25 Apr 2018 14:07:13 +0000 (14:07 +0000)]
Revert "waf.bbclass: explicitly pass bindir and libdir if supported"
* this doesn't work correctly as discussed in:
http://lists.openembedded.org/pipermail/openembedded-commits/2018-January/218460.html
* some of the issues were fixed in master since then
but not all, so revert it until it's completely resolved
Richard Purdie [Wed, 18 Apr 2018 10:38:06 +0000 (11:38 +0100)]
uninative: Set the dynamic linker to use at compile time
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.
Richard Purdie [Tue, 17 Apr 2018 14:42:31 +0000 (15:42 +0100)]
uninative: Add allow-shlib-undefined to BUILD_LDFLAGS and drop other workarounds
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.
Richard Purdie [Fri, 13 Apr 2018 16:08:10 +0000 (17:08 +0100)]
bitbake.conf: Set and export TZ envvar to UTC
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.
Mark Hatle [Mon, 16 Apr 2018 15:34:18 +0000 (11:34 -0400)]
package.bbclass: Add '-b' option to file call in isELF
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
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>
* Fix arbitrary command execution in ed-style patches:
- src/pch.c (do_ed_script): Write ed script to a temporary file instead
of piping it to ed: this will cause ed to abort on invalid commands
instead of rejecting them and carrying on.
- tests/ed-style: New test case.
- tests/Makefile.am (TESTS): Add test case.
* Fix segfault with mangled rename patch
- src/pch.c (intuit_diff_type): Ensure that two filenames are specified
for renames and copies (fix the existing check).
Cuero Bugot [Fri, 16 Mar 2018 17:31:30 +0000 (17:31 +0000)]
uninative: add variables to the whitelist so that it does not re-triger recipe parsing
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.
package_manager.py: Skip gpgcheck while using dnf on target
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
Juro Bystricky [Thu, 29 Mar 2018 20:27:02 +0000 (13:27 -0700)]
libpcre-ptest: skip locale test
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.
Koen Kooi [Fri, 9 Mar 2018 10:55:14 +0000 (11:55 +0100)]
openssl: fix libdir logic to allow multiarch style paths
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.
The patch was applied in a completely incorrect spot (due to fuzz),
no one noticed or complained. Meanwhile upstream says the issue
has been resolved differently:
https://rt.openssl.org/Ticket/Display.html?id=3759&user=guest&pass=guest
Ross Burton [Fri, 9 Mar 2018 18:55:44 +0000 (20:55 +0200)]
openssl: refresh patches
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.
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>
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.
Mikko Rapeli [Mon, 26 Mar 2018 11:57:59 +0000 (14:57 +0300)]
mirrors.bbclass: change Debian anonscm to salsa
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."
Mikko Rapeli [Mon, 26 Mar 2018 11:57:58 +0000 (14:57 +0300)]
ca-certificates: change SRC_URI from Debian anonscm to salsa
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."
Mikko Rapeli [Mon, 26 Mar 2018 11:57:57 +0000 (14:57 +0300)]
ncurses: change SRC_URI from Debian anonscm to salsa
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."
André Draszik [Thu, 5 Apr 2018 11:08:58 +0000 (12:08 +0100)]
curl: DEPENDS on libidn2 (not libidn)
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
Huang Qiyu [Wed, 24 Jan 2018 03:01:36 +0000 (11:01 +0800)]
curl: 7.54.1 -> 7.57.0
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.
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.
Tanu Kaskinen [Sat, 31 Mar 2018 05:21:31 +0000 (08:21 +0300)]
libvorbis: CVE-2017-14632
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.
Tanu Kaskinen [Sat, 31 Mar 2018 05:21:30 +0000 (08:21 +0300)]
libvorbis: CVE-2017-14633
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().
Niko Mauno [Mon, 29 Jan 2018 17:47:24 +0000 (19:47 +0200)]
bitbake.conf: Add comm to HOSTTOOLS
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.
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
[got reports the latest 4.4 is having issues too] Signed-off-by: Armin Kuster <akuster808@gmail.com>
Armin Kuster [Fri, 23 Mar 2018 04:57:20 +0000 (21:57 -0700)]
distcc: Change SRC_URI
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.
Tanu Kaskinen [Wed, 21 Mar 2018 17:07:41 +0000 (19:07 +0200)]
e2fsprogs: fix compatibility with glibc 2.27
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.
Juro Bystricky [Sat, 10 Mar 2018 19:27:29 +0000 (11:27 -0800)]
openssl_1.0.2n: improve reproducibility
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.
ca-certificates: run postinst script only for -target package
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.
Bruce Ashfield [Wed, 14 Mar 2018 15:10:29 +0000 (11:10 -0400)]
linux-yocto/4.12: backport bugfixes for x86
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.
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>
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.
Ross Burton [Fri, 2 Mar 2018 20:52:54 +0000 (20:52 +0000)]
populate_sdk_base: depend on nativesdk-glibc-locale
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.
Ross Burton [Thu, 1 Mar 2018 18:26:32 +0000 (18:26 +0000)]
populate_sdk: install UTF-8 locales in SDKs
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.
Ross Burton [Thu, 1 Mar 2018 18:26:27 +0000 (18:26 +0000)]
glibc: relocate locale paths in nativesdk
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.
busybox: separate inittab into own package, due to SERIAL_CONSOLES being machine-specific
* 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
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
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 0d4459e7086fced5e9e0b4ad10378c9eddec56a8) Signed-off-by: Armin Kuster <akuster808@gmail.com>
Otavio Salvador [Mon, 12 Mar 2018 11:29:01 +0000 (04:29 -0700)]
go: Upgrade 1.9 to 1.9.4 stable release
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”.
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>
Richard Purdie [Wed, 14 Mar 2018 16:52:18 +0000 (09:52 -0700)]
uninative: Add compatiblity version check
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.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Daniel Díaz [Tue, 13 Mar 2018 16:07:50 +0000 (10:07 -0600)]
gdb: fix header ordering for TRAP_HWBKPT
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.
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>
Richard Purdie [Sun, 11 Mar 2018 12:12:49 +0000 (05:12 -0700)]
gcc: Remove patch causing ICE on x86_64 valgrind compile
| ../../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.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Juro Bystricky [Thu, 1 Mar 2018 18:32:43 +0000 (10:32 -0800)]
gcc6: Backport few more patches
Backported series of patches from https://github.com/hjl-tools/gcc.git
branch /hjl/indirect/gcc-6-branch/master which contains
an IA patch series for security related issues
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
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:
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.
Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
