bb.data.expand(x, d) is deprecated API.

[YOCTO #10678]

Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
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 sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.

Motivating quote below:

< kergoth> the *original* intent was for the function/task to error via
           whatever appropriate means, bb.fatal, whatever, and
           funcfailed was what you'd catch if you were calling
           exec_func/exec_task. that is, it's what those functions
           raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself

FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.

Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Update older exception syntax to modern one required by python 3.
Compatible with python 2.7.

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

This sets the scene for removing the default False for expansion
from getVarFlag. This would later allow True to become the default.

On the most part this is an automatic translation with:

sed -e 's:\(\.getVarFlag([^,()]*, [^,()]*\)):\1, True):g'  -i `grep -ril getVar *`

In this case, the default was False, but True was used since in most
cases here expansion would be expected.

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

replacement in npth is available in OE-core

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Rather than just use d.getVar(X), use the more explict d.getVar(X, False)
since at some point in the future, having the default of expansion would
be nice. This is the first step towards that.

This patch was mostly made using the command:

sed -e 's:\(getVar([^,()]*\)\s*):\1, False):g' -i `grep -ril getVar *`

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

* Sort the list so it's at least in some form of logical order. I looked
  at sorting by dependencies, but that's a topological sort, and given
  no such function is shipped as part of the python standard libraries
  it would seem excessive to pull one in just for this. In any case, I'm
  not sure that for the data we have this would lead to any particularly
  pleasing result.
* Show the doc values as defined in documentation.conf (where present)
  as a description

Addresses [YOCTO #4856].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

See the bitbake commit adding the recideptask flag for details of the
problem but in summary, we weren't seeing the [depends] of tasks like
do_rootfs being taking into account for fetchall. This was leading
to not all sources being fetched and this is the OE-Core part of the
fix for this problem.

BB_DEFAULT_TASK is the default task used since this is the one that
most commands would end up targeting and is how users expect the command
to behave.

[YOCTO #4597]

(From OE-Core rev: abf468963a087244887384122fd5202909e7f118)

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