linux/poky.git/meta/conf/distro, branch dora

ltp: set PREFERRED_PROVIDER and rename runtests_noltp.sh script

2014-01-24T12:48:39+00:00

* ltp installs 2 different runtests_noltp.sh files from different directories into /opt/ltp/testcases/bin/runtests_noltp.sh last one installed wins and causes unexpected changes in buildhistory's files-in-image.txt report, rename them to have unique name as other ltp scripts have. * also define PREFERRED_PROVIDER to resolve note shown when building with meta-oe layer: NOTE: multiple providers are available for ltp (ltp, ltp-ddt) NOTE: consider defining a PREFERRED_PROVIDER entry to match ltp * use patch generated without -M in my builds both versions worked, but Saul reported that it fails to apply with: Applying patch 0001-Rename-runtests_noltp.sh-script-so-have-unique-name.patch patch: **** Only garbage was found in the patch input. Now I've see the same issue on different builder (with Ubuntu 12.04). (From OE-Core master rev: ec3bb2c2203b2e8bafc1a631f623f858779e20b7) (From OE-Core rev: 198623d80d31f19c963e61d03cbcb12dd318dfdf) Signed-off-by: Martin Jansa Signed-off-by: Saul Wold Signed-off-by: Richard Purdie Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

mesa: add virtual/mesa provider

2013-09-17T19:48:09+00:00

As there are two alternative mesa recipes (mesa and mesa-gl), there needs to be a virtual provider that recipes that explicitly need Mesa (such as xserver-xorg) can depend on. (From OE-Core rev: 4a407568472d3c87cd2ce11baf199568249640b6) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

avahi: fix and enable out-of-tree builds

2013-09-17T18:34:56+00:00

(From OE-Core rev: 6112a07f4e9865f7ae0e5a953669c1adf789f9f0) Signed-off-by: Ross Burton Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

mesa-gl: add GL-only Mesa recipe

2013-09-17T18:34:55+00:00

Some machines have hardware-specific GL drivers that do EGL and GLES (many ARM boards). Others have their own EGL/GLES drivers and provide a Mesa DRI driver (EMGD). Previously adding Mesa, for software GL/GLX rendering in the first case and hardware GLX in the second, involved bbappends and changing Mesa to be machine-specific. By adding a just-GL Mesa the machine definition can combine it with the hardware drivers cleanly. (From OE-Core rev: f5a3a4bc33109181c741a2e66c13d0b45566e8fa) Signed-off-by: Ross Burton Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

meta: Don't use deprecated bitbake API

2013-09-01T14:51:42+00:00

These have been deprecated for a long time, convert the remaining references to the correct modules and prepare for removal of the compatibility support from bitbake. (From OE-Core rev: 6a39835af2b2b3c7797fe05479341d71a3f3aaf6) Signed-off-by: Richard Purdie

web-webkit: Drop, we have midori now

2013-08-30T16:27:08+00:00

This was never a particularly useful browser and is a dead codebase, retire it and suggest midori instead. [YOCTO #2318] (From OE-Core rev: 3883d2cb03fb79fa39a7d85505c79784a996f178) Signed-off-by: Richard Purdie

linux-libc-headers: update to v3.10

2013-08-26T10:29:45+00:00

Now that the 3.10 kernel has been released we can bump the libc-headers to that version and remove the 3.8 variant. Userspace compatibility is maintained through kernel versions, we also make the single 3.10 version the toolchain default. (From OE-Core rev: 4e79a46254e778f85c00efd4b0085cbaeb6e0d4d) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

default-providers: Set the preferred provider for bluez

2013-08-23T15:20:14+00:00

There is a need for a default provider for bluez now that bluez5 recipe is also present. After the introduction of bluez5 recipe, the following warnings are displayed: "NOTE: multiple providers are available for runtime libasound-module-bluez (bluez4, bluez5) NOTE: consider defining a PREFERRED_PROVIDER entry to match libasound-module-bluez" Upon debug, bitbake shows: DEBUG: checking PREFERRED_PROVIDER_bluez4 (value None) against ['bluez4', 'bluez5'] DEBUG: checking PREFERRED_PROVIDER_bluez4-4.101 (value None) against ['bluez4', 'bluez5'] DEBUG: checking PREFERRED_PROVIDER_bluez4-4.101-r5 (value None) against ['bluez4', 'bluez5'] DEBUG: checking PREFERRED_PROVIDER_bluez5 (value None) against ['bluez4', 'bluez5'] DEBUG: checking PREFERRED_PROVIDER_bluez5-5.7 (value None) against ['bluez4', 'bluez5'] DEBUG: checking PREFERRED_PROVIDER_bluez5-5.7-r0 (value None) against ['bluez4', 'bluez5'] Bitbake is faced with the question "what should provide libasound-module-bluez?" which is a runtime name. It needs to try and find a PREFERRED_PROVIDER entry which matches this but those use *build time* naming. So it converts "libasound-module-bluez" into the canonical ${PN} of bluez4 and bluez5 and then tries to look those up. What it actually should do is go one step further of mapping bluez4/bluez5 into the virtual/bluez but that does not happen. Bug opened on this issue: YB5044 https://bugzilla.yoctoproject.org/show_bug.cgi?id=5044 [YOCTO #5030] (From OE-Core rev: 6f07d066074b1e01ff3c16408812e6b6d5e531ac) Signed-off-by: Cristian Iorga Signed-off-by: Richard Purdie

default-distrovars.inc: Add 'DISTRO_FEATURES_DEFAULT' variable

2013-08-20T14:31:25+00:00

When making distributions based on the default distro-less config, it is useful to be able to reuse the default DISTRO_FEATURES options without the need of duplication. The new variable, DISTRO_FEATURES_DEFAULT, allow this reuse and customization. So distros can include 'default-distrovars.inc' and use: ,----[ Use example ] | DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature" `---- (From OE-Core rev: 660ec04786162ff7f40aa78eb154dc4b5bf6ed9f) Signed-off-by: Otavio Salvador Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

qemu, default-providers: Add mesa as default virtual/egl

2013-08-16T10:14:33+00:00

* it's safer to select it consistently with virtual/libgl* providers (From OE-Core rev: d9321da1bf01175a9e3721607df31055e3765bc6) Signed-off-by: Martin Jansa Signed-off-by: Saul Wold Signed-off-by: Richard Purdie