Forcing the use of "\n" in mirror variables is pointless, we can just require that
there are pairs of values. With the bitbake restriction relaxed, we can relax
the sanity check too.

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

Using docker with the Fedora 23 container exposed an issue with
the rpm-native configure step. If which is not present the configure
script fork bombs. After much pain, I tracked this to which not being
present in the default container. Add a check for which so others
do not have to have this experience.

Signed-off-by: Philip Balister <philip@balister.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Now that the datastore works dynamically we don't need the update_data calls
so we can just remove them. They're not actually done anything at all for
a while.

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

With the recipe specific sysroots, we need a clean tmpdir, else pseudo-native,
openssl-native, subversion-native and serf-native need to be manually cleaned.
After these there are probably more places where software doesn't rebuild correctly
even if we pass in new parameters to it.

The simplest solution is to force people to start from a clean TMPDIR since
everything would rebuild anyway.

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

When a non-existing MACHINE is specified, sanity check issues
the following message:

    Please set a valid MACHINE in your local.conf or environment

However, MACHINE can also be set in multiconfig .conf file(s).
Hence we may have several different MACHINE settings within one
(multiconfig) build, so the present error message is fairly
ambiguous.

This patch remedies this by explicitly naming the offending MACHINE and
by amending the list of places where this erroneous MACHINE definition
could have originated.

    MACHINE=xyz is invalid. Please set a valid MACHINE in your local.conf, environment or other configuration file.

[YOCTO#10810]

Signed-off-by: Juro Bystricky <juro.bystricky@intel.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>

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>

The old code:
network_enabled = not d.getVar('BB_NO_NETWORK', True)

It is True only when BB_NO_NETWORK is not set (None),
but BB_NO_NETWORK = "0" should also be True while "1" means no network,
"0" means need network in a normal case.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

This can help fix the problem when the error happens.

Now the error message is:
    Fetcher failure for URL: 'https://www.example.com/'. URL https://www.example.com/ doesn't work.
    Please ensure your host's network is configured correctly,
    or set BB_NO_NETWORK = "1" to disable network access if
    all required sources are on local disk.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Fixes a crash in exception handler. All bb logging functions need an
string instances as arguments.

Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>