libgcc: Add MLPREFIX to sanity check skip

Fixes:
ERROR: QA Issue: non -staticdev package contains static .a library: lib32-libgcov-dev path '/work/x86-pokymllib32-linux/lib32-libgcc-4.7.0+svnr186651-r0/packages-split/lib32-libgcov-dev/usr/lib/i586-pokymllib32-linux/4.7.1/libgcov.a'
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa
ERROR: Logfile of failure stored in: /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-multilib/build/build/tmp/work/x86-pokymllib32-linux/lib32-libgcc-4.7.0+svnr186651-r0/temp/log.do_package.9691
NOTE: package lib32-libgcc-4.7.0+svnr186651-r0: task do_package: Failed
ERROR: Task 1077 (virtual:multilib:lib32:/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-multilib/build/meta/recipes-devtools/gcc/libgcc_4.7.bb, do_package) failed with exit code '1'
Signed-off-by: Saul Wold <sgw@linux.intel.com>
autospectacle.pl: pull it from meego as a base

This autospectacle.pl is from meego project
http://meego.gitorious.org/meego-developer-tools/autospectacle

And take its latest
commit f462b759c6f569f35283d0885c97ae53b010bb03
as base of Yocto 1656: Recipe creation/import script.

Signed-off-by: Kang Kai <kai.kang@windriver.com>
create-recipe: base on autospectacle.pl to create recipe file

[Yocto 1656]
create-recipe is based on original autospectacle.pl from project Meego.
Add feature to create a recipe .bb file. It requires a parameter to be
told where to download source package, then download and parse.
Create recipe file according to parse results.

Signed-off-by: Kang Kai <kai.kang@windriver.com>
mesa: add missing flex-native/bison-native deps

A quick glance at configure.ac shows that both are required to build mesa, but
we were relying on their being built implicitly via other recipes in the
dependency chain. Make it explicit.

Signed-off-by: Christopher Larson <chris_larson@mentor.com>
distcc: use PACKAGECONFIG for x11 distro feature

Signed-off-by: Christopher Larson <chris_larson@mentor.com>
libpcap: use PACKAGECONFIG for bluetooth distro feature

Signed-off-by: Christopher Larson <chris_larson@mentor.com>
libsndfile1: use PACKAGECONFIG for alsa distro feature

Signed-off-by: Christopher Larson <kergoth@gmail.com>
bitbake.conf: shift build config summary control to here

Signed-off-by: Christopher Larson <kergoth@gmail.com>
base.bbclass: use isinstance for base_eventhandler

Signed-off-by: Christopher Larson <kergoth@gmail.com>
csl-versions.inc: capture version in signatures

We want to ensure that changing external toolchain version will change the
metadata checksums of target recipes. This will do so via ensuring that any
variable which references TOOLCHAIN_OPTIONS also pulls in the toolchain
version variables.

Signed-off-by: Christopher Larson <kergoth@gmail.com>
external-csl-toolchain: split out a libstdc++-staticdev package

This silences one of the QA warnings.

Signed-off-by: Christopher Larson <kergoth@gmail.com>
external-csl-toolchain: silence .a/.debug QA warnings

Signed-off-by: Christopher Larson <kergoth@gmail.com>
external-csl-toolchain: cleanup, simplify, use base_libdir

Signed-off-by: Christopher Larson <kergoth@gmail.com>
external-csl-toolchain: update SUPPORTED to match toolchain

Signed-off-by: Christopher Larson <kergoth@gmail.com>
tclibc-eglibc: drop hardcoded locale-base-en-us/en-gb

This is handled by IMAGE_LINGUAS, so hardcoding it here is at best unnecessary
duplication.

Signed-off-by: Christopher Larson <kergoth@gmail.com>
libc-package: rework ''precompiled' locale handling

There were a couple problems with the handling of precompiled locales.

- it gathered the list of locales from the directories - this breaks due to
  the naming mismatch, e.g. en_US.UTF-8 vs en_US.utf8.
- it retained its hardcoded assumption that the non-suffixed locale (en_US, as
  opposed to en_US.*) is UTF-8, while the others are otherwise. Hardcoding
  this is both inflexible and just plain wrong for some toolchains. It's most
  common in desktop distros for 'en_US' to be non-utf8, and ''en_US.UTF-8' is
  utf8, and this is the case in some external toolchains as well.

The code now uses the SUPPORTED file to hold the knowledge it needs. This file
not only holds the list of locales to generate, but also maps the locale names
to the charsets they correspond to. The code now uses this to assemble its
charset map, falling back to the '.' suffix as charset when the locale is not
in the map. For precompiled, it now uses the locale->charset knowledge it has,
thereby allowing non-utf8 non-suffixed locale names, whereas for
non-precompiled, it reverts to the previous assumption, renaming the utf8
locale and forcibly suffixing the others.

So, a person maintaining an external toolchain recipe is responsible for
ensuring that the SUPPORTED file they provide matches up with the compiled
locales in the toolchain, if they want to utilize precompiled locales.

I believe in the long term the compiled case should do the same thing
precompiled does, and use SUPPORTED or a similar mechanism to encode the
knowledge, and if people want all the non-suffixed names to be utf8, they can
change that file to do so. This would avoid the hardcoded assumption in the
code, as well as consolidating the behavior between the compiled and
precompiled cases.

Signed-off-by: Christopher Larson <kergoth@gmail.com>
tcmode-external-csl: use the existing precompiled locale files

Signed-off-by: Christopher Larson <kergoth@gmail.com>
makedepend: upgrade from 1.0.3 to 1.0.4

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
quilt: upgrade from 0.51 to 0.60

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
gdb: upgrade from 7.4 to 7.4.1

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>

[Fixed sha256 - sgw]

Signed-off-by: Saul Wold <sgw@linux.intel.com>