Armin Kuster [Wed, 27 Jan 2016 22:20:21 +0000 (14:20 -0800)]
libpcre: bug fixes include security
[Yocto # 9008]
This is the next patch release for pcre. The 8.xx series now only contains
bug fixes.
http://www.pcre.org/original/changelog.txt
The following security fixes are included:
CVE-2015-3210 pcre: heap buffer overflow in pcre_compile2() / compile_regex()
CVE-2015-3217 pcre: stack overflow in match()
CVE-2015-5073 CVE-2015-8388 pcre: Buffer overflow caused by certain patterns with an unmatched closing parenthesis
CVE-2015-8380 pcre: Heap-based buffer overflow in pcre_exec
CVE-2015-8381 pcre: Heap Overflow in compile_regex()
CVE-2015-8383 pcre: Buffer overflow caused by repeated conditional group
CVE-2015-8384 pcre: Buffer overflow caused by recursive back reference by name within certain group
CVE-2015-8385 pcre: Buffer overflow caused by forward reference by name to certain group
CVE-2015-8386 pcre: Buffer overflow caused by lookbehind assertion
CVE-2015-8387 pcre: Integer overflow in subroutine calls
CVE-2015-8389 pcre: Infinite recursion in JIT compiler when processing certain patterns
CVE-2015-8390 pcre: Reading from uninitialized memory when processing certain patterns
CVE-2015-8392 pcre: Buffer overflow caused by certain patterns with duplicated named groups
CVE-2015-8393 pcre: Information leak when running pcgrep -q on crafted binary
CVE-2015-8394 pcre: Integer overflow caused by missing check for certain conditions
CVE-2015-8395 pcre: Buffer overflow caused by certain references
CVE-2016-1283 pcre: Heap buffer overflow in pcre_compile2 causes DoS
Signed-off-by: Armin Kuster <akuster@mvista.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Derek Straka [Mon, 25 Jan 2016 19:15:28 +0000 (14:15 -0500)]
bind: CVE-2015-8704 and CVE-2015-8705
CVE-2015-8704:
Allows remote authenticated users to cause a denial of service via a malformed Address Prefix List record
CVE-2015-8705:
When debug logging is enabled, allows remote attackers to cause a denial of service or have possibly unspecified impact via OPT data or ECS option
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Armin Kuster <akuster@mvista.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Armin Kuster [Sat, 23 Jan 2016 04:25:19 +0000 (20:25 -0800)]
glibc: CVE-2015-8776
it was found that out-of-range time values passed to the strftime function may
cause it to crash, leading to a denial of service, or potentially disclosure
information.
Signed-off-by: Armin Kuster <akuster@mvista.com> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Armin Kuster [Sat, 23 Jan 2016 04:23:04 +0000 (20:23 -0800)]
glibc: CVE-2015-9761
A stack overflow vulnerability was found in nan* functions that could cause
applications which process long strings with the nan function to crash or,
potentially, execute arbitrary code.
Signed-off-by: Armin Kuster <akuster@mvista.com> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Armin Kuster [Sat, 23 Jan 2016 04:19:24 +0000 (20:19 -0800)]
glibc: CVE-2015-8779
A stack overflow vulnerability in the catopen function was found, causing
applications which pass long strings to the catopen function to crash or,
potentially execute arbitrary code.
Signed-off-by: Armin Kuster <akuster@mvista.com> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Armin Kuster [Sat, 23 Jan 2016 04:13:00 +0000 (20:13 -0800)]
glibc: CVE-2015-8777.patch
The process_envvars function in elf/rtld.c in the GNU C Library (aka glibc or
libc6) before 2.23 allows local users to bypass a pointer-guarding protection
mechanism via a zero value of the LD_POINTER_GUARD environment variable.
Signed-off-by: Armin Kuster <akuster@mvista.com> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Richard Purdie [Thu, 17 Dec 2015 12:33:39 +0000 (12:33 +0000)]
nativesdk-buildtools-perl-dummy: Bump PR
Recent changes to this recipe caused automated PR increments
to break, regressing package feeds. The only way to recover
is to bump PR, so do this centrally to fix anyone affected.
Paul Eggleton [Fri, 11 Dec 2015 00:51:31 +0000 (13:51 +1300)]
nativesdk-buildtools-perl-dummy: properly set PACKAGE_ARCH
Turns out I did a silly thing in OE-Core revision 9b1831cf4a2940dca1d23f14dff460ff5a50a520 and forgot to remove the
explicit setting of PACKAGE_ARCH outside of the anonymous python
function; the original bug was apparently fixed but the functionality of
allarch.bbclass was being disabled because it was able to see that
PACKAGE_ARCH was not set to "all" - which was what I was trying to
ensure.
Paul Eggleton [Mon, 9 Nov 2015 16:45:21 +0000 (16:45 +0000)]
nativesdk-buildtools-perl-dummy: fix rebuilding when SDKMACHINE changes
This recipe produces an empty dummy package (in order to satisfy
dependencies on perl so we don't have perl within buildtools-tarball).
Because we were inheriting nativesdk here the recipe was being rebuilt,
but having forced PACKAGE_ARCH to a particular value the packages for
each architecture were stepping on eachother. Since the packages are
empty they can in fact be allarch (even though they won't actually go
into the "all" package feed). It turns out that nheriting nativesdk
wasn't actually necessary either, so drop that.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Richard Purdie [Sun, 17 Jan 2016 14:31:31 +0000 (14:31 +0000)]
gstreamer: Deal with merge conflict which breaks systemd builds
In jethro, the dependency is "udev", the change to libgudev happened
in master after the release and this was a mistake during
backporting of gstreamer fixes.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Jianxun Zhang [Tue, 12 Jan 2016 21:53:56 +0000 (13:53 -0800)]
kernel/kernel-arch: Explicitly mapping between i386/x86_64 and x86 for kernel ARCH
For a bare-bone kernel recipe which specifies 32 bit x86 target,
a 64 bit .config will be generated from do_configure task when
building 32-bit qemux86, once all of these conditions are true:
* arch of host is x86_64
* kernel source tree used in build has commit ffee0de41 which
actually chooses i386 or x86_64 defconfig by asking host when
ARCH is "x86" (arch/x86/Makefile)
* bare-bone kernel recipe inherits directly from kernel without
other special treatments.
Build will fail because of the mismatched kernel architecture.
The patch sets ARCH i386 or x86_64 explicitly to configure
task to avoid this host contamination. Kernel artifact is also
changed so that it can map i386 and x64 back to arch/x86 when
needed.
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Paul Eggleton [Wed, 6 Jan 2016 11:15:51 +0000 (00:15 +1300)]
devtool: reset: do clean for multiple recipes at once with -a
We need to run the clean for all recipes that are being reset before we
start deleting things from the workspace; if we don't, recipes providing
dependencies may be missing when we come to clean a recipe later (since
we don't and couldn't practically reset them in dependency order). This
also improves performance since we have the startup startup time for the
clean just once rather than for every recipe.
Paul Eggleton [Wed, 6 Jan 2016 11:15:47 +0000 (00:15 +1300)]
devtool: sdk-update: fix error checking
Running "raise" with no arguments here is invalid, we're not in
exception handling context. Rather than also adding code to catch the
exception I just moved the check out to the parent function from which
we can just exit.
Paul Eggleton [Wed, 6 Jan 2016 11:15:46 +0000 (00:15 +1300)]
devtool: sdk-update: fix metadata update step
* Clone the correct path - we need .git on the end
* Pull from the specified path instead of expecting a remote to be set
* up in the repo already (it isn't by default)
Paul Eggleton [Wed, 6 Jan 2016 11:15:45 +0000 (00:15 +1300)]
devtool: sdk-update: fix not using updateserver config file option
We read the updateserver setting from the config file but we never
actually used that value - the code then went on to use only the value
supplied on the command line.
Fix courtesy of Dmitry Rozhkov <dmitry.rozhkov@intel.com>
Paul Eggleton [Wed, 6 Jan 2016 11:15:43 +0000 (00:15 +1300)]
classes/populate_sdk_ext: fix cascading from preparation failure
During extensible SDK installtion, if the build system preparation step
fails we try to put something at the end of the environment setup script
to show an error when it is sourced, in case the user doesn't realise
that the partially-installed SDK is broken. However, an apostrophe in
the message (actually a single quote) appears to terminate the string
and therefore breaks the command. Drop it to avoid that.
Paul Eggleton [Wed, 6 Jan 2016 11:15:42 +0000 (00:15 +1300)]
scripts/oe-publish-sdk: add missing call to git update-server-info
We need to call git update-server-info here on the created repository or
we can't share it over plain http as we need to be able to for the
update process to function as currently implemented.
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>
Paul Eggleton [Sun, 20 Dec 2015 20:04:59 +0000 (09:04 +1300)]
buildhistory: fix not recording SDK information
After OE-Core revision baa4e43a29e45df17eaa3456acc179b08d571db6 we lost
recording SDK the contents in buildhistory. This was due to the
SDK_POSTPROCESS_COMMAND variable being set with = in
populate_sdk_base.bbclass which overwrote any value set with += in
buildhistory.bbclass; to fix it, use _append in buildhistory.bbclass
instead.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Paul Eggleton [Tue, 22 Dec 2015 04:03:17 +0000 (17:03 +1300)]
recipetool: create: fix error when extracting source to a specified directory
Having fetched the source and unpacked it to a temporary directory, we
then move part of it to the destination directory, or if the source is at
the top level we move the whole temporary directory, but in the latter
case we were later attempting to delete the temporary directory which no
longer existed. Clear out the variable so that doesn't happen.
Paul Eggleton [Tue, 22 Dec 2015 04:03:00 +0000 (17:03 +1300)]
recipetool: create: detect when specified URL returns a web page
If the user specifies a URL that just returns a web page, then it's
probably incorrect (or broken); attempt to detect this and show an error
if it's the case.
Paul Eggleton [Tue, 22 Dec 2015 04:02:59 +0000 (17:02 +1300)]
recipetool: create: prevent attempting to unpack entire DL_DIR
If you specify a URL ending in /, BitBake's fetcher returns a localpath
of ${DL_DIR}, and if you then try to unpack that it will attempt to copy
the entire DL_DIR contents to the destination - which at least on my
system filled my entire /tmp. Obviously we should fix the fetcher, but
at least detect and stop that from happening here for now.
Paul Eggleton [Tue, 22 Dec 2015 04:02:57 +0000 (17:02 +1300)]
recipetool: create: fix do_install handling for makefile-only software
In my testing here it appears make -qn returns an error (exit code 2)
whereas make -n doesn't; I can't immediately tell why based on the
documentation. We don't actually care for it to be quiet since we're
capturing the output, so let's just leave -q off and have this work
properly as a result.
Paul Eggleton [Tue, 22 Dec 2015 04:02:55 +0000 (17:02 +1300)]
recipetool: create: handle https://....git URLs
When you grab a URL for a github repository you'll almost certainly find
it in https://github.com/path/to/repository.git format; but bitbake's
fetcher can't handle that because it'll see https:// at the start and
assume it should use wget to fetch it. If the URL starts with http:// or
https:// and the path part ends with .git then assume it's a git
repository and adjust it accordingly.
Paul Eggleton [Tue, 22 Dec 2015 03:19:18 +0000 (16:19 +1300)]
devtool: sdk-update: fix traceback without update server set
If the SDK update server hasn't been set in the config (when building
the extensible SDK this would be set via SDK_UPDATE_URL) and it wasn't
specified on the command line then we were failing with a traceback
because we didn't pass the default value properly - None is interpreted
as no default, meaning raise an exception if no such option exists.
Additionally we don't need the try...except anymore either because with
a proper default value, NoSectionError is caught as well.
Ross Burton [Fri, 6 Nov 2015 15:30:58 +0000 (15:30 +0000)]
libaio: don't disable linking to the system libraries
For some reason that I don't understand (a decade-old attempt at optimisation?)
libaio disables linkage to the system libraries. Enabling fortify means linking
to the system libraries, so remove the existing addition of -lc for x86 (the
problem also happens on at least PPC) and just link to the system libraries on
all platforms.
Also remove the sed of src/Makefile as the build not respecting LDFLAGS has been
fixed upstream.
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: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Needed to quiet GNU_HASH warnings, and some minor fixes.
...
it explicitly move logrotate to /usr/bin without any reason,
which is against the original Linux location /usr/sbin.
So partly revert the above commit which let logrotate be
kept in the original place /usr/sbin.
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Mark Hatle [Fri, 30 Oct 2015 14:48:27 +0000 (09:48 -0500)]
glibc: Fix ld.so / prelink interface for ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA
A bug in glibc 2.22's ld.so interface for the prelink support causes
the displayed values to be incorrect. The included path fixes this
issue.
Clear ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA for prelink
prelink runs ld.so with the environment variable LD_TRACE_PRELINKING
set to dump the relocation type class from _dl_debug_bindings. prelink
has the following relocation type classes:
where ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA has a conflict with
RTYPE_CLASS_TLS.
Since prelink doesn't use ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, we
should clear the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA bit when the
DL_DEBUG_PRELINK bit is set.
Mark Hatle [Mon, 2 Nov 2015 14:52:28 +0000 (08:52 -0600)]
gcc: Update default Power GCC settings to use secure-plt
The gcc default, bss-plt, will cause errors when using the prelinker. All
other distributions that I am aware of are using the the secure-plt. For an
explanation of the differences, the gcc docs:
Current PowerPC GCC accepts a `-msecure-plt' option that generates code
capable of using a newer PLT and GOT layout that has the security
advantage of no executable section ever needing to be writable and no
writable section ever being executable. PowerPC ld will generate this
layout, including stubs to access the PLT, if all input files (including
startup and static libraries) were compiled with `-msecure-plt'.
`--bss-plt' forces the old BSS PLT (and GOT layout) which can give
slightly better performance.
The security of the new PLT and ability to run the prelinker outweigh
any performance penalty.
The secure-plt is enabled by default. The old bss-plt can be enabled by
selecting 'bssplt' in the DISTRO_FEATURES.
Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
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> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
OpenJDK-8 has it's configure script at common/autotools - which will cause
the entire assumption of ${S}/configure is regenerated by autoreconf, intltoolize or alike
fails heavily.
Also - other configure mechanisms can be supported more similar (see how pkgsrc
manages different ones ...)
Signed-off-by: Jens Rehsack <sno@netbsd.org> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
On Ubuntu-system, When sourcing the env.sh from an exported sdk, and
running a bogus linux command (for example "asd"), a core dump of
python is usually generated.
Paul Eggleton [Sun, 22 Nov 2015 21:07:57 +0000 (10:07 +1300)]
devtool: upgrade: fetch remote repository before checking out new revision
If we're upgrading a recipe that fetches from git, and we've simply
fetched a tarball of the repo instead of directly from the upstream repo
(this can happen if you have PREMIRRORS set up as in poky with a core recipe,
e.g. kernelshark) then we won't have any new revisions, and the checkout
will fail with "fatal: reference is not a tree: <hash>". To avoid this,
do a "git fetch" before checking out the new revision.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Paul Eggleton [Sun, 22 Nov 2015 21:06:50 +0000 (10:06 +1300)]
devtool: upgrade: remove erroneous error when not renaming recipe
If we're upgrading a git recipe the recipe file usually won't need
renaming; for some unknown reason we were throwing an error here which
isn't correct.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Paul Eggleton [Sun, 22 Nov 2015 21:14:44 +0000 (10:14 +1300)]
devtool: upgrade: fix updating PV and SRCREV
This code was clearly never tested. Fix the following issues:
* Actually set SRCREV if it's been specified
* Enable history tracking and reparse so that we handle if variables are
set in an inc file next to the recipe
* Use a more accurate check for PV being in the recipe which will work
if it's in an inc file next to the recipe
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Paul Eggleton [Sun, 22 Nov 2015 20:39:39 +0000 (09:39 +1300)]
devtool: upgrade: fix removing other recipes from workspace on reset
If you did a "devtool add" followed by "devtool upgrade" and then did
a "devtool reset" on the recipe you upgraded, the first recipe would
also be deleted from the workspace - this was because we were
erroneously adding the entire "recipes" subdirectory and its contents to
be tracked for removal on reset. Remove the unnecessary call to
os.path.dirname() that caused this.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Tzu-Jung Lee <roylee17@currantlabs.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Paul Eggleton [Fri, 4 Dec 2015 02:42:50 +0000 (15:42 +1300)]
toolchain-shar-extract.sh: proper fix for additional env setup scripts
buildtools-tarball uses a custom env setup script, which isn't named the
same as the default; thus unfortunately OE-Core revision a36469c97c9cb335de1e95dea5141038f337df95 broke installation of
buildtools-tarball. Revert that and implement a more robust mechanism.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
toolchain-shar-relocate: don't assume last state of env_setup_script is good
In the case where many environment-setup-* files exist, the incorrect
filename might be lastly set in env_setup_script, which leads to
incorrect behaviour for the initialization of native_sysroot.
The scenario I had was that our custom meta-toolchain-*.bb, which
inherits populate_sdk, defined another environment-setup-* file to dump
variable information for qt-creator. The file is named like so in order
for the sdk shell script to pick it up and fix the SDK paths in the
file. Since it (coincidentally) alphabetically comes after ...-core2, it
was last set in env_setup_script and the grep OECORE_NATIVE_SYSROOT
would simply be blank. The apparent symptom was "...relocate_sdk.py:
Argument list too long" since the find command would not be searching in
the right path.
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>
Paul Eggleton [Wed, 18 Nov 2015 20:59:36 +0000 (09:59 +1300)]
classes/populate_sdk_ext: fail if SDK_ARCH != BUILD_ARCH
The extensible SDK relies upon uninative, and with the way that
uninative works, the build system architecture must be the same as the
SDK architecture or the extensible SDK won't be usable. At some point in
future hopefully we can remove this limitation, but until then it's
disingenuous to allow this to build, so add a check to ensure
SDK_ARCH == BUILD_ARCH and fail if it isn't.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Paul Eggleton [Thu, 12 Nov 2015 15:24:29 +0000 (15:24 +0000)]
classes/populate_sdk_ext: tweak reporting of workspace exclusion
If you have a local workspace layer enabled when building the
extensible SDK, we explicitly exclude that from the SDK (mostly because
the SDK has its own for the user to use). Adjust the message we print
notifying the user of this so it's clear that we're excluding it from
the SDK, and scale it back from a warning to a note printed with
bb.plain().
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Paul Eggleton [Thu, 12 Nov 2015 15:00:47 +0000 (15:00 +0000)]
classes/populate_sdk_ext: tidy up preparation log file writing
Use a variable for the log file which includes the full path; this is
not only neater but avoids us writing the first part (the output of
oe-init-build-env) to a file in another directory since we are
changing directory as part of this subshell.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes the following warning sometimes appearing during image builds:
WARNING: The license listed ABC was not in the licenses collected for recipe xyz
The files being looked for here, which runs during do_rootfs,
are written out by the do_populate_lic task for each recipe. However,
there was no explicit dependency between do_rootfs and all of the
do_populate_lic tasks to ensure they had run - only an implicit link via
do_build, so it is possible that sometimes they had not depending on how
the tasks were scheduled. Add an explicit set of dependencies to fix
this.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Paul Eggleton [Mon, 9 Nov 2015 14:40:08 +0000 (14:40 +0000)]
classes/metadata_scm: fix git errors showing up on non-git repositories
Fixes the following error showing up for layers that aren't a git repo
(or aren't parented by one):
fatal: Not a git repository (or any of the parent directories): .git
This was because we weren't intercepting stderr. We might as well just
use bb.process.run() here which does that and returns stdout and stderr
separately.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Paul Eggleton [Fri, 6 Nov 2015 09:34:05 +0000 (09:34 +0000)]
classes/distrodata: split SRC_URI properly before determining type
We weren't splitting SRC_URI values containing multiple URIs here; this
didn't cause any errors except when a trailing ; was left on a URI, in
which case the next URI was considered part of the parameter, which
didn't contain a = and therefore was considered invalid.
We only care about the first URI in SRC_URI in this context (since
that's the upstream URI by convention) so split it as we should and take
the first item.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Ross Burton [Wed, 11 Nov 2015 14:50:27 +0000 (14:50 +0000)]
openssl: sanity check that the bignum module is present
The crypto_use_bigint_in_x86-64_perl patch uses the "bigint" module to
transparently support 64-bit integers on 32-bit hosts. Whilst bigint (part of
bignum) is a core Perl module not all distributions install it (notable Fedora
23).
As the error message when bignum isn't installed is obscure, add a task to check
that it is available and alert the user if it isn't.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Li Xin <lixin.fnst@cn.fujitsu.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Martin Jansa [Fri, 4 Dec 2015 18:44:23 +0000 (19:44 +0100)]
texinfo: don't create dependency on INHERIT variable
* we don't want the do_package signature depending on INHERIT variable
* e.g. just adding the own-mirrors causes texinfo to rebuild:
# bitbake-diffsigs BUILD/sstate-diff/*/*/texinfo/*do_package.sig*
basehash changed from 015df2fd8e396cc1e15622dbac843301 to 9f1d06c4f238c70a99ccb6d8da348b6a
Variable INHERIT value changed from
' rm_work blacklist blacklist report-error ${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST} sanity'
to
' rm_work own-mirrors blacklist blacklist report-error ${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO} ${INHERIT_BLACKLIST} sanity'
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Martin Jansa [Wed, 25 Nov 2015 09:07:26 +0000 (10:07 +0100)]
package_manager.py: define info_dir and status_file when OPKGLIBDIR isn't the default
* without this the do_rootfs task doesn't respect OPKGLIBDIR and
info, status are created in different directory than opkg on
target expects
* people who modify OPKGLIBDIR need to make sure that opkg.conf included
in opkg package also sets info_dir and status_file options
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Ross Burton [Wed, 11 Nov 2015 13:40:13 +0000 (13:40 +0000)]
libsdl2: require GLES when building Wayland support
The Wayland support requires GLES2 to be enabled as otherwise the EGL support
code in SDL2 isn't enabled.
| In file included from .../SDL2-2.0.3/src/video/wayland/SDL_waylandvideo.c:34:0:
| .../SDL2-2.0.3/src/video/wayland/SDL_waylandvideo.c: In function 'Wayland_CreateDevice':
| .../SDL2-2.0.3/src/video/wayland/SDL_waylandopengles.h:38:38: error: 'SDL_EGL_GetSwapInterval' undeclared (first use in this function)
| #define Wayland_GLES_GetSwapInterval SDL_EGL_GetSwapInterval
Solve this by adding gles2 to the Wayland PACKAGECONFIG option.
Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Martin Jansa [Thu, 12 Nov 2015 19:44:51 +0000 (20:44 +0100)]
gst-plugins-bad: add PACKAGECONFIGs for voamrwbenc, voaacenc, resindvd
* allows to easily enable them and fixes:
WARNING: QA Issue: gstreamer1.0-plugins-bad: Files/directories were installed but not shipped in any package:
/usr/share/gstreamer-1.0
/usr/share/gstreamer-1.0/presets
/usr/share/gstreamer-1.0/presets/GstVoAmrwbEnc.prs
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
gstreamer1.0-plugins-bad: 3 installed and not shipped files. [installed-vs-shipped]
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Martin Jansa [Thu, 12 Nov 2015 12:07:28 +0000 (13:07 +0100)]
gstreamer1.0-plugins-good: fix PACKAGECONFIG for gudev and add one for v4l2 and libv4l2
* WARN: gstreamer1.0-plugins-good: gstreamer1.0-plugins-good-video4linux2 rdepends on libcap, but it isn't a build dependency?
WARN: gstreamer1.0-plugins-good: gstreamer1.0-plugins-good-video4linux2 rdepends on libgudev, but it isn't a build dependency?
WARN: gstreamer1.0-plugins-good: gstreamer1.0-plugins-good-video4linux2 rdepends on libudev, but it isn't a build dependency?
WARN: gstreamer1.0-plugins-good: gstreamer1.0-plugins-good-video4linux2 rdepends on zlib, but it isn't a build dependency?
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Martin Jansa [Thu, 12 Nov 2015 11:49:37 +0000 (12:49 +0100)]
gstreamer1.0-plugins-bad: fix dependencies for uvch264 PACKAGECONFIG
* ERROR: gstreamer1.0-plugins-bad: gstreamer1.0-plugins-bad-uvch264 package isn't created when building with minimal dependencies?
* ERROR: gstreamer1.0-plugins-bad: gstreamer1.0-plugins-bad-uvch264-dev package isn't created when building with minimal dependencies?
* it's because it should depend on libgudev not udev:
configure: *** for plug-ins: uvch264 ***
checking linux/uvcvideo.h usability... yes
checking linux/uvcvideo.h presence... yes
checking for linux/uvcvideo.h... yes
checking for GST_VIDEO... yes
checking for G_UDEV... no
checking for LIBUSB... yes
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
