Otherwise, if MACHINEOVERRIDES is expanded before SOC_FAMILY is set
(which may happen as MACHINEOVERRIDES is included in OVERRIDES) we can
see:
ExpansionError: Failure expanding variable MACHINEOVERRIDES, expression was
${@['', '${SOC_FAMILY}:']['${SOC_FAMILY}' != '']}p1022ds
which triggered exception SyntaxError: EOL while scanning string literal (MACHINEOVERRIDES, line 1)
To avoid this, give SOC_FAMILY a default empty value so it doesn't
get read as None.
(From OE-Core rev: dee005b6e1bc353230f9f27a469b2054a644e542)
(From OE-Core rev: 7c763846bca4347d6b9e8cc388ad075f00123235)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"MACHINE=qemux86-64 bitbake init-ifupdown; MACHINE=genericx86-64 bitbake init-ifupdown"
shows a rebuild when it would be expected. The reason is a LIC_FILES_CHKSUM which
contains file://${WORKDIR}, an absolute path which doesn't exist in the first build
but does in the second, causing a signature change and a rebuild.
Fix the problem by ignoring any file:// url which resolves since TMPDIR for
license file dependency purposes.
(From OE-Core rev: f27ddf0de23871fc72cfc31f514f0e144aaa2082)
(From OE-Core rev: d88bb3759c36f2a30550529468c8a8c511b1661c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Check up front in test_devtool_deploy_target whether the tap devices
exist and skip if not. If we don't do this we get a significantly less
comprehensible error via pexpect.
(From OE-Core master rev: 2258345e19efff7717fe19a5026ec55f1b6f90b6)
(From OE-Core rev: cdad3ea375590f6fa9330f481b6712681ad00cd2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we run devtool, if the workspace layer already exists but isn't in
bblayers.conf (perhaps because it was previously created but
subsequently removed from bblayers.conf by the user) then we should add
it and notify the user, otherwise devtool operations won't work.
(From OE-Core master rev: 313b622a6c6613092ed18a2158e090521344f6c0)
(From OE-Core rev: 2904c1130ea7cc1abde0609f1ba1394e0f31a6fa)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we execute an external command, we ought to prepare for the
possibility that it can fail and handle the failure appropriately. We
can especially expect this to happen when running bitbake in this
scenario. Ensure we return the appropriate exit code to the calling
process.
Fixes [YOCTO #7757].
(From OE-Core master rev: 98a716d79bfc5434a5b42d3ca683eab3eea30a41)
(From OE-Core rev: 2791fe9236f7173e6b998cf9b40fe238566ed8ee)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If -x is specified and the specified URI was a git repository, we need
to ensure that the resulting clone is a sandalone and not one that has
pointers into the temporary fetch location or DL_DIR (since the git
fetcher does a local clone with -s). Split out the code from devtool
that already does this for "devtool modify -x" and reuse that.
(From OE-Core master rev: fc47e8652ef32e7399f57c80593df90dc52d8b84)
(From OE-Core rev: d8f151b6a385f81abead65624ba15d42cbd90e11)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When -x was specified, we were getting the normal unpack subdirectory
which we don't really want - if there's only one subdirectory unpacked
then we should effectively copy just it to the extraction path, not as a
subdirectory under it.
(From OE-Core master rev: 0eeecce96a0aa757c2c4c4ac4d82e3bcbf0f982c)
(From OE-Core rev: 3378c932570ba2301cd02103225fcf7629de656f)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you've done "devtool add" (or "devtool modify" without -x) then it's
possible that the external source tree is not a git repository, so we
should handle that case here instead of printing a traceback.
(From OE-Core master rev: eb2147aa8facd4ef33a0749e9ae660ec686dad48)
(From OE-Core rev: c5dc3e819c1bb224e3cb667381faa5abf1888362)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the proper bbappend file name, don't just assume it will have a
version suffix (because it won't if the original recipe doesn't).
Fixes [YOCTO #7651].
(From OE-Core master rev: 3332d68ef7b2a300ce8dcf5021497d98e5b17baa)
(From OE-Core rev: 3d5ea16a1f53c12d86c4e8df6af864964541cf02)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We weren't adding the version into the bbappend file name when -V was
specified which meant that building or resetting failed.
Also adjust one of the tests so that we're testing devtool add both with
and without this option.
Fixes [YOCTO #7647].
(From OE-Core master rev: bdbeff0cd342e31053d7203d78fc5dda611052b1)
(From OE-Core rev: 0b9e8817fc8ba375a1045a66d04b3fd2b498427b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Names such as glib-2.0 are valid (and used) recipe names, so we need to
support them.
Fixes [YOCTO #7643].
(From OE-Core master rev: b9fd8d4d4dfae72de2e81e9b14de072e12cecdcf)
(From OE-Core rev: 36df1bb9bb3c92d096118b74fdf11a243be3f7d5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to get correct metadata, SRCREV for example.
Fixes [YOCTO #7648].
(From OE-Core master rev: 8b1794559dd7fd956716179d628e61cffdce1686)
(From OE-Core rev: becbd5d50a091fe4a980361d9c99efa01f43edcc)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This option can be used to have a separate build directory, in order to
keep the srctree directory clean for packages that do not need to be
built in the source directory.
(From OE-Core master rev: 5cc348c0a3016e4ccc1e80d099e2e197b3b38bd2)
(From OE-Core rev: a7316a4c564901b30af740ece6631a6f68355bb4)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Makes the build succeed for packages which do not support separate build
directory, e.g. zlib. The same outcome could be achieved with the
--same-dir option, but, it's generally hard to tell if a random package
would need that option. The negative side effect of this patch is that
dev srctree (of some packages that build fine without this modification)
gets dirtied by build artefacts.
(From OE-Core master rev: 6ac5692426956e276ba2119f917b0f30791e6cd6)
(From OE-Core rev: 97078c56e8b8a235e923d964253775e20112a36f)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Acked-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Give the correct data object ("config data" instead of "recipe data") as
an argument to oe.recipeutils.patch_recipe()
Fixes [YOCTO #7595]
(From OE-Core master rev: 7d2b918019b0afe215a6489dad697afac34f73e9)
(From OE-Core rev: f8427fe565e44e46246146bdaae66a5d83ae8c9d)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes a build issue with the 3.19.5 kernel where the regmap prototypes
have changed. The patch is rebased do to changes in the new version of the
Makefile.
[YOCTO #7737]
(From OE-Core rev: 787fde133c6b50c5df6ce8f90b2906b7955b41e4)
(From OE-Core rev: 2a355d2efb44a70571586bc5f6e500fa5d73db33)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed when build on armv7a_vfp_neon:
Python-3.3.3/Modules/_struct.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
All the archs should use -fPIC when build shared object for linux.
(From OE-Core rev: 60c1f76f65060cbea458b06f9719a2536f50474e)
(From OE-Core rev: d9c3d3036da6f36d1f494987aa854d0c76968a27)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport patch to fix CVE-2015-1345. The issue was introduced with
v2.18-90-g73893ff, and version 2.5.1a is not affected.
Replace tab with spaces in SRC_URI as well.
(From OE-Core rev: ea97b1dee834594358c342515720559ad5d56f33)
(From OE-Core rev: f5e18f8dbac54231441b8b6260bf608edc377f66)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Joshua Lock <joshua.lock@collabora.co.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3310
Buffer overflow in the rc_mksid function in plugins/radius/util.c in
Paul's PPP Package (ppp) 2.4.6 and earlier, when the PID for pppd is
greater than 65535, allows remote attackers to cause a denial of
service (crash) via a start accounting message to the RADIUS server.
oe-core is using ppp 2.4.7, and this CVE say ppp 2.4.7 was not
effected, but I found this buggy codes are same between 2.4.6 and
2.4.7, and 2.4.7 should have this issue.
(From OE-Core rev: 5b549c6d73e91fdbd0b618a752d618deb1449ef9)
(From OE-Core rev: 5450caccd45a2ee35ee227cdd64e66a304909a0e)
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
padlock_conf.patch will enable the padlock engine by default,
but this engine does not work on some 32bit machine, and lead
to openssl unable to work
(From OE-Core rev: f7d186abca6ed9b48ae7393b8f244e1bfb46cb41)
(From OE-Core rev: bbc41bc086009726f307edeedbd380c68b1be6a7)
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default search path in sysroot is sufficient to find zlib, so the
--with-libz-prefix configure option seems to be unnecessary.
For target builds, relying on sysroot also prevents an absolute path
from being hardcoded in the gnutls.pc pkg-config file.
(From OE-Core rev: 7a800bfeb6c8c83ee7cc74739f496982cd71c8e8)
(From OE-Core rev: f46c2ac0fd05f0e10258d8f03bfb2ebd0c2bcbe3)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The rootfs logfile check errors out if it finds an "exit 1" in
a log. But consider the shell idiom:
if ! $command; then exit 1; fi
and consider a postinstall script with a "set -x" for debugging
purposes (to get log output in /var/log/postinstall.log.)
Solution: Ignore lines prefixed with a +, because those show shell
code even if a specific fragment won't be executed.
(From OE-Core rev: f23f129dba66144abf8fe8450320e01fa4c02f5c)
(From OE-Core rev: a13185ba4a29fca319b4eb4a76fdbdfcfe767322)
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
check_sanity() no longer needs the subprocess module but
sanity_handle_abichanges() does use subprocess.call().
(From OE-Core rev: 469b53fb3bb94c7e5e9fb53d07cec2292b13c87d)
(From OE-Core rev: f0bf36c669790f1bcb2f897e61c82b075cb0a83b)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Current regex can cause false negatives if paths in bitbake log files
contain "ERR" or "Fail". do_rootfs fails with return code 1 in
this case.
Improved regexp is based on error messages produced by rpm.
Those are found by analyzing rpm source code.
[YOCTO #7789]
(From OE-Core rev: 38871dc0295fb2516e1c8b1dc9948c2d2fc4d2cd)
(From OE-Core rev: 4a7f15e1d64a5d4ca4cd9b46a0ee5903e441b4e0)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libz.so symbolic link created in ${libdir} is
../../${base_libdir}/libz.so.1.2.8. This doesn't work if base_libdir or libdir
is changed, so use oe.path.relative to construct the correct path at build time.
(From OE-Core rev: ada8972ec40441b06e50d3e9ccbc07241a48e30a)
(From OE-Core rev: 20a60f137a9a1ae2689286241cc3d68a0392803d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The icu recipe installs icu-native twice, once in the usual location,
and once for cross builds into the path given by --with-cross-build.
This latter path is not included in the list of paths recognised by
chrpath.bbclass, hence the binaries in there retain the rpath as used
during compilation. This causes the package to not be relocateable
from sstate
[YOCTO #6851]
We use the infrastructure that is in place already, and simply set
PREPROCESS_RELOCATE_DIRS as necessary, and things start to work.
(From OE-Core rev: e7fcaa534511e3f65b630b01cf0c824ee5a5fd4d)
(From OE-Core rev: 922faf8ed42cd2d105e30a8c92836664d6b5bb18)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The building failure still display after upstream commit 055a5bbfc[
pcmciautils: fix for parallel build], so refix it.
(From OE-Core rev: fb426a1f5a103a1dc096977533dfbec2aefe07ae)
(From OE-Core rev: 14b5556ad3a4d7e817442e004b73601041f31b69)
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport Arjun Shankar's patch for CVE-2015-1781:
A buffer overflow flaw was found in the way glibc's gethostbyname_r() and
other related functions computed the size of a buffer when passed a
misaligned buffer as input. An attacker able to make an application call
any of these functions with a misaligned buffer could use this flaw to
crash the application or, potentially, execute arbitrary code with the
permissions of the user running the application.
https://sourceware.org/bugzilla/show_bug.cgi?id=18287
(From OE-Core rev: c0f0b6e6ef1edc0a9f9e1ceffb1cdbbef2e409c6)
(From OE-Core rev: 54f5e2001249c117cdfc1c26631ba50bc7a155dd)
Signed-off-by: Haris Okanovic <haris.okanovic@ni.com>
Reviewed-by: Ben Shelton <ben.shelton@ni.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The way native_virtclass_handler was implemented leaded to
unintended substring replacements when setting PROVIDES for
native providers, in case the original PROVIDES value contains
providees with common substrings.
Here's a practical case where the old behavior was problematic:
the oracle-jse-jdk-x86-64 recipe provides both virtual/java and
virtual/javac:
Before:
$ bitbake -e oracle-jse-jdk-x86-64-native | grep ^PROVIDES=
PROVIDES="oracle-jse-jdk-x86-64-native virtual/java-native virtual/java-nativec"
After:
$ bitbake -e oracle-jse-jdk-x86-64-native | grep ^PROVIDES=
PROVIDES="oracle-jse-jdk-x86-64-native virtual/java-native virtual/javac-native"
Change-Id: I8186992dae58e37c2a2364586360ff9b7da9198f
(From OE-Core rev: c28291f1fb07fbc80275d9bceefed642c963e204)
(From OE-Core rev: e0814f2306e1404fffafc7695862c6ee542b08fa)
Signed-off-by: Mario Domenech Goulart <mario@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The EGL is used by the Wayland backend. When building using Software
Rendering and without Wayland support the EGL backend is not available
so we should not require EGL for GLES2 support.
This fixes following build error:
,----
| ...
| checking for bcm_host_init in -lbcm_host... no
| checking for WAYLAND_EGL... no
| configure: error: Could not find the required EGL libraries
| Configure failed. The contents of all config.log files follows to aid debugging
| ERROR: oe_runconf failed
`----
(From OE-Core rev: 9c3a94aea1de3ab98e5693640926bfc86acde2db)
(From OE-Core rev: 2a0a2f276ef631bf7d60ec9821800d9b40a5832b)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* it was partially fixed in:
commit 291e20a51544c640d07767d1dc32d762f4370f41
Author: Venkata ramana gollamudi <ramana.gollamudi@huawei.com>
Date: Fri Apr 13 11:42:46 2012 +0000
Subject: boost: fix re-execution of task
but with disadvantage that when CXX or *FLAGS variables were changed
it was continuing to use old values
* just remove the line before appending it with current values to fix
that
(From OE-Core rev: 8ce9584a78079b3db88eabfa902025a94443378d)
(From OE-Core rev: f055d084ad74a01a431ea87ead6bfdcaca0d7bde)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This workaround is not needed in version 219 since the fix is upstreamed with:
919699ec301ea507edce4a619141ed22e789ac0d
(From OE-Core rev: e3330d0602fb3ad347f028063d25f634a36ea344)
(From OE-Core rev: fdcbbb50a9946733bd204b8db45606c929e43822)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without pkgconfig being present at build time it's possible for the .pc files to
not be installed correctly.
(From OE-Core rev: f049a53078b3876be9fefc1e5f64404a3f378724)
(From OE-Core rev: c6e39f271a737aa867a15f70c2975987e9d7b209)
Signed-off-by: Christophe Guillon <christophe.guillon@st.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* install populate-extfs.sh from contrib, be aware that in order
to use it you need to set DEBUGFS shell variable, otherwise it will
try to use debugfs from relative path which is almost always
incorrect:
CONTRIB_DIR=$(dirname $(readlink -f $0))
DEBUGFS="$CONTRIB_DIR/../debugfs/debugfs"
(From OE-Core rev: 525b7b587a00466e4322450c171d920b47201e56)
(From OE-Core rev: 32e847f6988eb488dad23badf1cabae92ef803df)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On x32 builds, sysd-syscalls appears malformed since the make-target-directory
appears on the wrong line. This causes races during the build process where you can
see failures like:
Assembler messages:
Fatal error: can't create [...]glibc/2.21-r0/build-x86_64-poky-linux-gnux32/time/gettimeofday.os: No such file or directory
Assembler messages:
Fatal error: can't create [...]glibc/2.21-r0/build-x86_64-poky-linux-gnux32/time/time.os: No such file or directory
The issue is that the carriage return is being escaped when it should
not be. The change to sysd-syscalls with this change:
before:
"""
$(foreach p,$(sysd-rules-targets),$(objpfx)$(patsubst %,$p,time).os): \
$(..)sysdeps/unix/make-syscalls.sh $(make-target-directory)
(echo '#include <dl-vdso.h>';
"""
after:
"""
$(foreach p,$(sysd-rules-targets),$(objpfx)$(patsubst %,$p,time).os): \
$(..)sysdeps/unix/make-syscalls.sh
$(make-target-directory)
(echo '#include <dl-vdso.h>';
"""
which ensures the target directory is correctly created. Only x32 uses the vdso
code which contains the bug which is why the error only really appears on x32.
(From OE-Core rev: ae4729ed6c5e5443c42f8825dd85873f06a3570e)
(From OE-Core rev: c945453a8453dd6dab5aa5a132bea20e73ae4d6d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In a similar way to http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=aa1438b56f30515f9c31b306decef7f562dda81f
and http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=527b28c10955daf0387597020d69593ce24bcaa4
there is a find race in base.bbclass.
For recipes with PACKAGES_remove = "${PN}", the find which removes
.la files can race against deletion of other directories in WORKDIR
e.g.:
find: '/home/autobuilder/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build/tmp/work/qemux86_64-poky-linux/init-ifupdown/1.0-r7/sstate-build-populate_lic': No such file or directory
| WARNING: /home/autobuilder/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build/tmp/work/qemux86_64-poky-linux/init-ifupdown/1.0-r7/temp/run.do_configure.6558:1 exit 1 from
| find /home/autobuilder/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build/tmp/work/qemux86_64-poky-linux/init-ifupdown/1.0-r7 -name \*.la -delete
Fix the race in the same way.
[YOCTO #7522]
(From OE-Core rev: 90861b8908d254154f4d1d613471070df8013da8)
(From OE-Core rev: 220141c63161f7c4f4112ac8b95bf44775843a9f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
make[1]: Entering directory `alsa-tools-1.0.28/envy24control'
make[1]: *** No rule to make target `clean'. Stop.
There is no "make clean" in envy24control when DISTRO_FEATURES is
changed from no-x11 to x11.
(From OE-Core rev: 8ccc47c37765487b535c4d6a8b43c2b6365ff000)
(From OE-Core rev: 4ff4bca025277fd19f11a6ba86102fca8563a1ff)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9636
unzip 6.0 allows remote attackers to cause a denial of service
(out-of-bounds read or write and crash) via an extra field with
an uncompressed size smaller than the compressed field size in a
zip archive that advertises STORED method compression.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-1315
Buffer overflow in the charset_to_intern function in unix/unix.c in
Info-Zip UnZip 6.10b allows remote attackers to execute arbitrary code
via a crafted string, as demonstrated by converting a string from CP866
to UTF-8.
(From OE-Core rev: f86a178fd7036541a45bf31a46bddf634c133802)
(From OE-Core rev: d868f9e8a6a5d4dc9c38e2881a329f7e3210eab8)
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As reported by Steffen Pankratz <Steffen.Pankratz@elektrobit.com>, the
previous logic of KBUILD_DEFCONFIG processing would not propagate an in
tree defcofig to WORKDIR if one was not already present.
We fix the propagation by copying the in tee config if a defconfig is
not already in WORKDIR.
Additionally we only warn (versus copying) if an in tree configuration
is specified, is different than the WORKDIR version and isn't copied.
(From OE-Core rev: 58cc903a5156063b24e48011438a709cb6e09f54)
(From OE-Core rev: 0b12cc3a326740bd95bb199d4f1b38bf5beadfa9)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are two tasks that must run before a linux-yocto kernel is built.
- Kernel checkout and relocation to work-shared (kernel_checkout)
- Meta data gathering and configuration prep (kernel_metadata)
The current task definitions for both are simply "before do_patch",
which is correct, but kernel_checkout must run before and not race with
kernel_metadata.
So we set the definition of kernel_checkout to be more specific and
enforce the proper ordering.
[YOCTO: #7731]
(From OE-Core rev: 9d806f3d05de918952f839f5e595cb71cd1261db)
(From OE-Core rev: 561b7776d93d40cac009360ec95b8de78888f1ca)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Race condition between do_compile_kernelmodules and do_shared_workdir
tasks occurs when do_compile_kernelmodules changes files in
include/generated/* while do_shared_workdir tries to copy them to
shared working directory.
Fixed race by moving do_shared_workdir after do_compile but before
do_compile_kernelmodules.
[YOCTO #7321]
(From OE-Core rev: b4ec689f71fe9504559c1921c893f5e096d6b744)
(From OE-Core rev: a224584b6b0b7f12e0d1962d889587ce50957c60)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
