openembedded-core.git/meta/conf, branch krogoth Mirror of openembedded-core xserver-xf86-config: pre-load int10 and exa modules 2016-09-23T14:26:14+00:00 Khem Raj raj.khem@gmail.com 2016-08-20T20:36:09+00:00 13fd49fd719d7e59ea347241934ccb991264f14f musl doesn't like lazy loading that xorg uses, therefore load the needed modules explicitly [YOCTO #10169] (From OE-Core rev: e279c9a30f0df400b06a47a487967a734854714b) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> 
musl doesn't like lazy loading that xorg uses, therefore
load the needed modules explicitly

[YOCTO #10169]

(From OE-Core rev: e279c9a30f0df400b06a47a487967a734854714b)

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
arch-mips.inc: Disable QEMU usermode usage when building with n32 ABI 2016-09-23T14:26:12+00:00 Alexander Kanavin alexander.kanavin@linux.intel.com 2016-09-01T17:50:54+00:00 013dfa3e9f14f50a3d1efb5e98a45ce1e579abcf QEMU usermode doesn't support n32 binaries, erroring with "Invalid ELF image for this architecture". (From OE-Core rev: 66aa39a959bd41f7063fe64a9225eb9fd6c3293b) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> 
QEMU usermode doesn't support n32 binaries, erroring with "Invalid
ELF image for this architecture".

(From OE-Core rev: 66aa39a959bd41f7063fe64a9225eb9fd6c3293b)

Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
bitbake.conf: set READELF for cross compilation 2016-09-23T14:26:05+00:00 Jeremy Puhlman jpuhlman@mvista.com 2016-08-01T16:02:55+00:00 e24b5fe3f04cbb5953ec82f9e4d040f6600012b3 In the case of using an external toolchain that supports multilib compilation with a single binary, TARGET_PREFIX is the same for both main and multilib abis. Without READELF exported, python3 assumes it is either the readelf for ${BUILD_SYS}-readelf. Exporting cross readelf fixes the build issue. checking LDLIBRARY... libpython$(LDVERSION).so checking for i586-montavistamllib32-linux-ranlib... x86_64-montavista-linux-ranlib checking for i586-montavistamllib32-linux-ar... x86_64-montavista-linux-ar checking for i586-montavistamllib32-linux-readelf... no checking for readelf... readelf configure: WARNING: using cross tools not prefixed with host triplet (From OE-Core rev: 3442ee423813d547be7899a25ea31efe719e662f) Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> 
In the case of using an external toolchain that supports multilib
compilation with a single binary, TARGET_PREFIX is the same for both main
and multilib abis. Without READELF exported, python3 assumes it is
either the readelf for ${BUILD_SYS}-readelf. Exporting cross readelf
fixes the build issue.

checking LDLIBRARY... libpython$(LDVERSION).so
checking for i586-montavistamllib32-linux-ranlib...
x86_64-montavista-linux-ranlib
checking for i586-montavistamllib32-linux-ar...
x86_64-montavista-linux-ar
checking for i586-montavistamllib32-linux-readelf... no
checking for readelf... readelf
configure: WARNING: using cross tools not prefixed with host triplet

(From OE-Core rev: 3442ee423813d547be7899a25ea31efe719e662f)

Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
bitbake.conf/toolchain-scripts.bbclass: Remove debug prefix mappings in SDK 2016-09-23T14:26:01+00:00 Jacob Kroon jacob.kroon@gmail.com 2016-07-28T10:56:06+00:00 e52b98077e94e7071e70de28ed95092aad74d3ac CFLAGS/CXXFLAGS in the SDK environment script adds debug-prefix mappings that include staging area/work directories. Remove them since the SDK shouldn't be aware of them. (From OE-Core rev: 7918e73e9c5fe8c8c1c1d341eaa42f2f7d3ddb69) Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> 
CFLAGS/CXXFLAGS in the SDK environment script adds debug-prefix mappings
that include staging area/work directories. Remove them since the SDK
shouldn't be aware of them.

(From OE-Core rev: 7918e73e9c5fe8c8c1c1d341eaa42f2f7d3ddb69)

Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
yocto-uninative: Update to 1.0.1 tarball 2016-08-31T13:20:52+00:00 Fabio Berton fabio.berton@ossystems.com.br 2016-08-31T12:30:29+00:00 4ac90c58032e1097abefc14bfc5029db0a893aa9 The 1.0.1 uninative tarball includes the change for GlibC to use the host locale data, which is required for Python 3 to work properly. Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br> 
The 1.0.1 uninative tarball includes the change for GlibC to use the
host locale data, which is required for Python 3 to work properly.

Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
feature-arm-vfp.inc: fix overzealous ARMPKGSFX_FPU modification 2016-07-06T16:25:11+00:00 André Draszik git@andred.net 2016-06-30T06:26:11+00:00 2c4ae03834be3f4449487a2c7c40829d94051d99 Since commit 972b4fc (feature-arm-neon.inc: restore vfpv3-d16 support) we're replacing _all_ dashes (-) in ARMPKGSFX_FPU, which is causing problems for all legitimate uses of the dash as TUNE_PKGARCH doesn't have the right value anymore: E.g. on raspberrypi2: ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Error, the PACKAGE_ARCHS variable (all any noarch armv5hf-vfp armv5thf-vfp armv5ehf-vfp armv5tehf-vfp armv6hf-vfp armv6thf-vfp armv7ahf-vfp armv7at2hf-vfp armv7vehf-vfp armv7vet2hf-vfp armv7vehf-neon armv7vet2hf-neon armv7vehf-neon-vfpv4 armv7vet2hf-neon-vfpv4 cortexa7hf-vfp cortexa7hf-neon cortexa7hf-neon-vfpv4 cortexa7t2hf-vfp cortexa7t2hf-neon cortexa7t2hf-neon-vfpv4 raspberrypi3) for DEFAULTTUNE (cortexa7thf-neon-vfpv4) does not contain TUNE_PKGARCH (cortexa7hf-neonvfpv4). Fix this by being more explicit about what we're modifying. Reported-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: André Draszik <git@andred.net> Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 
Since commit 972b4fc (feature-arm-neon.inc: restore vfpv3-d16 support)
we're replacing _all_ dashes (-) in ARMPKGSFX_FPU, which is causing
problems for all legitimate uses of the dash as TUNE_PKGARCH doesn't
have the right value anymore:

E.g. on raspberrypi2:

ERROR:  OE-core's config sanity checker detected a potential misconfiguration.
    Either fix the cause of this error or at your own risk disable the checker (see sanity.conf).
    Following is the list of potential problems / advisories:

    Error, the PACKAGE_ARCHS variable (all any noarch armv5hf-vfp armv5thf-vfp
armv5ehf-vfp armv5tehf-vfp armv6hf-vfp armv6thf-vfp armv7ahf-vfp
armv7at2hf-vfp armv7vehf-vfp armv7vet2hf-vfp armv7vehf-neon armv7vet2hf-neon
armv7vehf-neon-vfpv4 armv7vet2hf-neon-vfpv4 cortexa7hf-vfp cortexa7hf-neon
cortexa7hf-neon-vfpv4 cortexa7t2hf-vfp cortexa7t2hf-neon
cortexa7t2hf-neon-vfpv4 raspberrypi3) for DEFAULTTUNE (cortexa7thf-neon-vfpv4)
does not contain TUNE_PKGARCH (cortexa7hf-neonvfpv4).

Fix this by being more explicit about what we're modifying.

Reported-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
useradd-staticids.bbclass: Allow missing UIDs/GIDs to generate warnings 2016-06-29T18:34:46+00:00 Peter Kjellerstedt peter.kjellerstedt@axis.com 2016-06-17T14:59:02+00:00 5a37852e4ab3a7438cab372b288663535ecdfee1 Previously when USERADD_ERROR_DYNAMIC was set to "1", an exception was raised if no numeric UID/GID could be determined for a user/group. Now it is possible to set it to either "error", which results in the old behavior, or "warn" in which case a warning is issued instead. For backwards compatibility reasons, it is still possible to set USERADD_ERROR_DYNAMIC to "1" and get an exception in case of failure. (From OE-Core rev: 58c82f79efee8e68fa63b96a32f54660afb15769) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 3037e0df9b1a0e1cb5332ab8026245b61515fc33) Signed-off-by: Armin Kuster <akuster@mvista.com> 
Previously when USERADD_ERROR_DYNAMIC was set to "1", an exception was
raised if no numeric UID/GID could be determined for a user/group. Now
it is possible to set it to either "error", which results in the old
behavior, or "warn" in which case a warning is issued instead.

For backwards compatibility reasons, it is still possible to set
USERADD_ERROR_DYNAMIC to "1" and get an exception in case of failure.

(From OE-Core rev: 58c82f79efee8e68fa63b96a32f54660afb15769)

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 3037e0df9b1a0e1cb5332ab8026245b61515fc33)
Signed-off-by: Armin Kuster <akuster@mvista.com>
documentation.conf: Add information about USERADD variables 2016-06-29T18:34:46+00:00 Peter Kjellerstedt peter.kjellerstedt@axis.com 2016-06-17T14:59:00+00:00 1526c8ebfcada2cb3a8b6122a3cbb51a22c94d2a (From OE-Core rev: 6064ef3f3f9e03b2bafb5e55f02fac9b17901615) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> (cherry picked from commit 4ed711a2b330094b71844ec48833ba21501ee80e) Signed-off-by: Armin Kuster <akuster@mvista.com> 
(From OE-Core rev: 6064ef3f3f9e03b2bafb5e55f02fac9b17901615)

Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 4ed711a2b330094b71844ec48833ba21501ee80e)
Signed-off-by: Armin Kuster <akuster@mvista.com>
bitbake.conf: don't set CCACHE_DIR to $HOME by default 2016-06-29T18:34:46+00:00 Ross Burton ross.burton@intel.com 2016-06-20T12:13:09+00:00 8bcfed5a5d8c53a481028ef6e55008670cfbe8dc If the user hasn't inherited ccache.bbclass then CCACHE_DIR is set to $HOME. This was to work around a bug (#2554) for some users where if ccache < 3.1.10 (released 2014-10-19) was installed and enabled by default (i.e. /usr/bin/gcc is a symlink to ccache) and ccache.bbclass wasn't being inherited then autogen would fail to build because it sets $HOME to /dev/null during the build and ccache (prior to 3.1.10) would always create CCACHE_DIR even if it was disabled. As the default is $HOME/.ccache, this results in ccache attempting to create /dev/null/.ccache. However there was a mistake in this assignment of CCACHE_DIR - it should be $HOME/.ccache - as ccache will do cleanup inside CCACHE_DIR which will result in it deleting $HOME/tmp. In the future when we can assume that everyone has ccache 3.1.10 onwards this assignment can be deleted, but as of now we still support OpenSUSE 13.2 which ships with 3.1.9 so fix the assignment to be $HOME/.ccache. [ YOCTO #9798 ] (From OE-Core rev: 15eaf9cb1fa19036fe4442905876dae94070b04d) 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> 
If the user hasn't inherited ccache.bbclass then CCACHE_DIR is set to $HOME.

This was to work around a bug (#2554) for some users where if ccache < 3.1.10
(released 2014-10-19) was installed and enabled by default (i.e. /usr/bin/gcc is
a symlink to ccache) and ccache.bbclass wasn't being inherited then autogen
would fail to build because it sets $HOME to /dev/null during the build and
ccache (prior to 3.1.10) would always create CCACHE_DIR even if it was disabled.
As the default is $HOME/.ccache, this results in ccache attempting to create
/dev/null/.ccache.

However there was a mistake in this assignment of CCACHE_DIR - it should be
$HOME/.ccache - as ccache will do cleanup inside CCACHE_DIR which will result in
it deleting $HOME/tmp.  In the future when we can assume that everyone has
ccache 3.1.10 onwards this assignment can be deleted, but as of now we still
support OpenSUSE 13.2 which ships with 3.1.9 so fix the assignment to be
$HOME/.ccache.

[ YOCTO #9798 ]

(From OE-Core rev: 15eaf9cb1fa19036fe4442905876dae94070b04d)

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>
bitbake.conf: add default for IMAGE_FSTYPES_DEBUGFS 2016-06-29T18:34:42+00:00 Ross Burton ross.burton@intel.com 2016-05-06T11:26:05+00:00 c622eaff01383b2f18d243d10b2d2dd4393ef6f1 If debug filesystem generation is enabled but this isn't assigned then the generation code throws exceptions. (From OE-Core rev: 0a1b02fab0e2604cd55ea6f45d764a864599213a) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> 
If debug filesystem generation is enabled but this isn't assigned then the
generation code throws exceptions.

(From OE-Core rev: 0a1b02fab0e2604cd55ea6f45d764a864599213a)

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>