openembedded-core.git/meta/conf/distro, branch dora

ltp: set PREFERRED_PROVIDER and rename runtests_noltp.sh script

2014-01-24T12:48:15+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)

Signed-off-by: Martin Jansa 
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie 
Signed-off-by: Robert Yang

mesa: add virtual/mesa provider

2013-09-17T19:48:05+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.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie

avahi: fix and enable out-of-tree builds

2013-09-17T18:28:08+00:00

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:26:17+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.

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:36+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.

Signed-off-by: Richard Purdie

web-webkit: Drop, we have midori now

2013-08-30T16:25:55+00:00

This was never a particularly useful browser and is a dead codebase, retire
it and suggest midori instead.

[YOCTO #2318]

Signed-off-by: Richard Purdie

linux-libc-headers: update to v3.10

2013-08-26T10:23:43+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.

Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie

default-providers: Set the preferred provider for bluez

2013-08-23T15:03:58+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]

Signed-off-by: Cristian Iorga 
Signed-off-by: Richard Purdie

default-distrovars.inc: Add 'DISTRO_FEATURES_DEFAULT' variable

2013-08-20T14:09:06+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"
`----

Signed-off-by: Otavio Salvador 
Signed-off-by: Saul Wold

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

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

* it's safer to select it consistently with virtual/libgl* providers

Signed-off-by: Martin Jansa 
Signed-off-by: Saul Wold