The new name is much more consistent with what this actually means. We put
the pieces in place to rename everything a while back but looks like we
forgot to actually do it! Fix that now.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

* Fixed:
  The netmap has been blacklisted in
  meta-networking/recipes-kernel/netmap/netmap_git.bb, but lib32-netmap still can
  be built (suppose it doesn't depend on another broken recipe netmap-modules, it
  is a little complicated, will talk below):
  $ bitbake lib32-netmap

  This is because of the old code masks on bb.event.ConfigParsed which can only
  handle global blacklist, netmap sets blacklist in the recipe, so it can't be
  handled, and lib32-netmap can be built. which was incorrect:
  blacklist_multilib_eventhandler[eventmask] = "bb.event.ConfigParsed"

  Move multilib code into multilib.bbclass can fix the problem easily:
  $ bitbake lib32-netmap
    ERROR: Nothing PROVIDES 'lib32-netmap'
    ERROR: lib32-netmap was skipped: Recipe is blacklisted: BROKEN: <foo>

* Not fixed
  Another problem is netmap-modules has also been blacklisted in the recipe, and
  the recipe inherits module.bbclass, so multilib.bbclass doesn't handle it as the
  code shows:
    # There should only be one kernel in multilib configs
    # We also skip multilib setup for module packages.
    provides = (e.data.getVar("PROVIDES") or "").split()
    if "virtual/kernel" in provides or bb.data.inherits_class('module-base', e.data):
        raise bb.parse.SkipPackage("We shouldn't have multilib variants for the kernel")

  And netmap-modules provides lib32-netmap-modules which is handled in
  multilib_global.bbclass, so bitbake lib32-netmap-modules can't show
  the blacklist message:
  $ bitbake netmap-modules
  ERROR: Nothing PROVIDES 'netmap-modules'
  ERROR: netmap-modules was skipped: Recipe is blacklisted: BROKEN: <foo>
  ERROR: netmap-modules was skipped: We shouldn't have multilib variants for the kernel

  $ bitbake lib32-netmap-modules
  ERROR: Nothing PROVIDES 'lib32-netmap-modules'. Close matches:
    netmap-modules
    netmap-modules
    lib32-fbset-modes

  Note the different messages between netmap-modules and lib32-netmap-modules.
  This is because multilib.bbclass doesn't handle the "module" recipe so
  there is no PN called lib32-netmap-modules, therefore blacklist.bbclass can't
  handle it.

  Note, there are two "netmap-modules" which needs to be fixed later.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

There were a few straggling expansion parameter removals left for
getVar/getVarFlag where the odd whitespace meant they were missed
on previous passes. There were also some plain broken ussages such
as:

d.getVar('ALTERNATIVE_TARGET', old_name, True)
path = d.getVar('PATH', d, True)
d.getVar('IMAGE_ROOTFS', 'True')

which I've corrected (they happend to work by luck).

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

getVarFlag() now defaults to expanding by default, thus remove the
True option from getVarFlag() calls with a regex search and
replace.

Search made with the following regex:
getVarFlag ?\(( ?[^,()]*, ?[^,()]*), True\)

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.

Search made with the following regex: getVar ?\(( ?[^,()]*), True\)

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

This deletes and therefore breaks PACKAGECONFIG[doc], so revert.

This reverts commit b741780d43ad412f6a1ae91d8489ec3522447ea2.

Signed-off-by: Ross Burton <ross.burton@intel.com>

The FOO[doc] is set in meta/conf/documentation.conf, we need remove it
from d.getVarFlags()'s return dict when it causes many loops.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

base.bbclass had code which handled the PNBLACKLIST in case of
multilib use. This is better to be done in the blacklist.bbclass so it
has all logic in a single place.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

Revise the handling from ANGSTROM_BLACKLIST to PNBLACKLIST[pn].

Refactor the code to eliminate references to the distribution and recipe
name in the message.

Change the skipPackage message message from:

ERROR: <recipe> was skipped: <distro> DOES NOT support <recipe> because <reason>

to:

ERROR: <recipe> was skipped: Recipe is blacklisted: <reason>

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>

Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>

Import directly from meta-openembedded commit: 	a63c374cdc785ade69d2998978d08280e671dc1f

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>