Boost is an optional dependency but avoid build non-determinism by adding it as
DEPENDS. It is only for the shared pointer types so can be disabled explicitly
if required.
Turn sqlite into a PACKAGECONFIG.
Add a patch for the "monitor" feature to control the optional dependencies on
ncurses and json-c. Previously this was enabled for target only but enable it
everwhere now that json-c is available for native/nativesdk.
Of course all of this was predicated about systemtap needing systemtap-native to
be built, but it turns out that this dependency is due to oe-core 507bd2 which
adds systemtap-native as DEPENDS for convenience. Remove this dependency, if
the user wants systemtap-native then they can build it explicitly.
(From OE-Core rev: fb9dc1cf7a2d6d5e22beb68f17b4c9c8d1136e37)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
commit 1fe8e0f074c [include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and linux/in6.h]
breaks the builds of net-tools.
We remove the new includes until such a time that userspace can adapt to the
new kernel headers.
(From OE-Core rev: cd3720317abaff1e857cfb6b1e2a3741baf8f944)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Before standard/intel/* was created in the 4.1 and 4.4 kernel trees,
some patches were merged to standard/base to add features/support for
intel platforms.
While this isn't entirely bad, there have been some compile issues
reported in some configurations. Since we don't need these commits
on standard/base, we can relocate them to make standard/base upstream
clean.
This commit removes those patches from standard/base, and restores
then to the standard/intel/* branches.
(From OE-Core rev: 2c19e6378697141992c9bd7ff2bd4d57a4f9fe9b)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The following kernel commits broke the compilation of ppp, due to redefined
structures.
Nothing else breaks in userspace with or without these uapi changes, so we
revert them to keep everything building.
commit 05ee5de7451796cf9a8aeb2f05a57790d4fd2336
Author: Mikko Rapeli <mikko.rapeli@iki.fi>
Date: Mon Aug 22 20:32:42 2016 +0200
include/uapi/linux/if_pppol2tp.h: include linux/in.h and linux/in6.h
Fixes userspace compilation errors like:
error: field <E2><80><98>addr<E2><80><99> has incomplete type
struct sockaddr_in addr; /* IP address and port to send to */
^
error: field <E2><80><98>addr<E2><80><99> has incomplete type
struct sockaddr_in6 addr; /* IP address and port to send to */
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit eafe92114308acf14e45c6c3d154a5dad5523d1a
Author: Mikko Rapeli <mikko.rapeli@iki.fi>
Date: Mon Aug 22 20:32:43 2016 +0200
include/uapi/linux/if_pppox.h: include linux/in.h and linux/in6.h
Fixes userspace compilation errors:
error: field <E2><80><98>addr<E2><80><99> has incomplete type
struct sockaddr_in addr; /* IP address and port to send to */
error: field <E2><80><98>addr<E2><80><99> has incomplete type
struct sockaddr_in6 addr; /* IP address and port to send to */
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
(From OE-Core rev: 12451a412fb7b5706c1553618ee7b704234876cc)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've been using a -rc4 variant of the libc-headers, now that
4.8 has been released, we switch to the final tgz of the headers.
(From OE-Core rev: d7cef1c71dedacda86426a1f9f815a8b7108857b)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Updating the common-pc* configuration to have the following mmc
configs available by default:
meta/common-pc-64: use mmc-sdhci feature
meta/common-pc: use mmc-sdhci feature
meta: add mmc/mmc-sdhci feature
meta: add mmc/mmc-block feature
meta: add mmc/base feature
(From OE-Core rev: 024ee2f47ebac39438f87069d48f5e34c9c81891)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: ff310dd103e16a5345a4bb48090af05f50171de3)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 5f8eb6726a492d259bfe25b0bbce2333c9505504)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: de45a7e302fe5a2a08baf26c91e2c788d7285263)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 8443b6f3f25181f5ac49bc25a1387cd05b814376)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 5369bb7fa6238cc85f0b5263519974c1a2d9eea8)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 086240468265dc15c5b4cdb2594d5aa7c3114dda)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 20e669f56489b2c8a9bc6a0e6f3eac81ef35445a)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 33611b69c221cf875eba1c7cb599c256825ae470)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 21969c3d1397e0a11a8cb9dad8ce3469ee655f57)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 11a2f932073635f9680470cd69216cecf7ed0c37)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 8e956d66087b9c41591b8e4e817ed6c9e42f5981)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 8e9255763674703ea16651da64fe794e5359f16e)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: a77b4e543407eee133fbd38ac9b69e90bea541e0)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: f7c82acbac583c7838550175796a7aa697a5c7e0)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: c61d7a01c89f0d25d069191cc47d6768bee2ce48)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: cca772ecf0adafbd767974add27ada125aae5269)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 48c4faa1d7117732974e51428f7ed2f62ad7e7bf)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: e507cb978fd52164beb28324933cb3d5e368c3ab)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: f0561ba205723fd7f05c28d501c2c517034b326c)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 5a074e8a26d27ea9c4f31e2b75b2b14f6e0641d3)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 01e3ac73860a24710852383a15bb5d01db13de57)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
(From OE-Core rev: 9635af9785509a39c1ac2509740d46276119a0ca)
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't autoreconf/libtoolize binutils as it has very strict requirements, so
extend our patching of the stock libtool to include two fixes to RPATH
behaviour, as part of the solution to ensure that native binaries don't have
RPATHs pointing at the host system's /usr/lib.
This generally doesn't cause a problem but it can cause some binaries (such as
ar) to abort on startup:
./x86_64-pokysdk-linux-ar: relocation error: /usr/lib/libc.so.6: symbol
_dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with
link time reference
The situation here is that ar is built and as it links to the host libc/loader
has an RPATH for /usr/lib. If tmp is wiped and then binutils is installed from
sstate relocation occurs and the loader changed to the sysroot, but there
remains a RPATH for /usr/lib. This means that the sysroot loader is used with
the host libc, which can be incompatible. By telling libtool that the host
library paths are in the default search path, and ensuring that all default
search paths are not added as RPATHs by libtool, the result is a binary that
links to what it should be linking to and nothing else.
[ YOCTO #9287 ]
(From OE-Core rev: 6b201081b622cc083cc2b1a8ad99d6f7d2bea480)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was a clear typo in a function name, correct it.
(From OE-Core rev: dcf44e184a807d76463a3bf1b2315e80b9469de3)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This variable is used by libtool to know what paths are on the default loader
search path. As we have modified loader paths, native.bbclass can tell libtool
that both the sysroot libdir and the host library paths are searched, so no
RPATHs for those will be generated.
(From OE-Core rev: 2d0a1b029447842a6f97f72ae636c9020c4206a9)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This variable is used by libtool to know what paths are on the default loader
search path. As we have modified loader paths, cross.bbclass can tell libtool
that both the sysroot libdir and the host library paths are searched, so no
RPATHs for those will be generated.
(From OE-Core rev: 5b61324fa76b27bb6ce13e78b17e767eed2f8f57)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added wic images to the list of default image types for Beaglebone
machine. Added kernel image and device tree packages to the image
to make it bootable. Added required wic dependencies.
[YOCTO #8719]
(From meta-yocto rev: 71cb33a39bf01e588c2df769c34d110d3e2ca6ea)
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>
The value used for exclusion was always being expanded. This is actually
a bad idea since in most cases you'd want to exclude an unexpanded
value and makes it impossible to use the variable as intended.
This adjusts things so the value is not expanded and we can correctly
remove things from checksums much more easily.
(Bitbake rev: 81bc8201c475d2b6bef0168573915ad0140f6dad)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When switching MACHINE, nativeksdk recipes could end up being rebuilt. Clear
ABIEXTENSION to avoid this problem and ensure sstate checksum consistency.
(From OE-Core rev: 21cc2a3f63ea260dbf6b50e2fd4dd50cacdd9935)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Switching between multilib configurations should not change allarch recipe
or nativesdk checksums. Add a new sstate test for this based on the standard
allarch test.
(From OE-Core rev: 660543601171f88c75fb4e90f34dac86037f3f23)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building boost-native on i686, the x86 override isn't applied
unless the target also happens to be x86. Similarly the x86_64 override
is only applied on 64 bit target machines.
Avoid various problems by removing the new problematic configure options
in the native case.
(From OE-Core rev: 5a4fe5a735b16e313e7a33649b4e7764a6888d0c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gcc-cross target recipes should not depend on SDK_SYS but started to
after recent changes. Remove the dependency to stop this (its caused
by shared code in do_install). The compiler names contain SDK_SYS
so changes would be correctly handled via other means.
(From OE-Core rev: 2b5761350a074de2e1a6db19621945fba39089fc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When enabling multilib.conf, the world was rebuilding due to changes in the
pkg-config search path. This doesn't matter so exclude it from the checksums.
(From OE-Core rev: 22001ba163e80b114212580279339acd15fa7298)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When changing multilibs, allarch recipes should not be rebuilding. This
adds enough variable exclusions to make this work properly. Future
regressions will be prevented with new testing.
(From OE-Core rev: ce1e7fcc60276040477c1d5e3129e029bb9f204b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
package_write_rpm references the MULTILIBS variable and the checksums
of nativesdk recipes were changing as a result of this.
We don't need/want MULTILIBS values for nativesdk so disable this.
(From OE-Core rev: 738ff6bc72533bbdeb58425b20b0bfbeff280a04)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
StreamHandler was added due missing log information on the console in
oe-selftest with Qemu Runner
(From OE-Core rev: a4e2df151af781edbcb6b0e17b51b5ed226bf77f)
Signed-off-by: Francisco Pedraza <francisco.j.pedraza.gonzalez@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This begins moving away from the deprecated subprocess calls in an
effort to eventually move to some more global abstraction using the run
convenience method provided in python 3.5.
[ YOCTO #9342 ]
(From OE-Core rev: 0d6b7276003f1afabc6de683f663540327d52bdc)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create kbd-ptest sub-package:
* add file run-ptest and runtime dependency make
* modify installed Makefile to disable remake Makefile and the test
cases when run the ptest
* add patch to set proper path for test cases to get resource files
(From OE-Core rev: 901ccb3e70e9036112c51acc6d18d05025f6e1bb)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a preparation to use mkefidisk as a default wks for
genericx86* BSPs. This change enables usage of partition UUID
instead of device name to specify root partition in kernel
command line. It should make images to boot on devices with
boot device names that differ from what's mentioned in wks file.
(From OE-Core rev: 23cca700870230b46d251086441136e99659ef12)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
