Unpacking an src.rpm uses rpm2cpio.sh, which requires 'file'.

Without this, builds of rpm on a host without 'file' installed will fail with
very strange messages.

(From OE-Core master rev: 97e1d84e2d1a74791ce6af88ddc27963bc0e1bec)

Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

gcc has cross and target components with a shared workdir. The unpack umask
settings need to match for all of these. We need to use strings in each
case to ensure the sstate code matches them correctly.

This patch tweaks various things to ensure the change adding the unpack umask
change doesn't break the compiler builds.

(From OE-Core master rev: 67162438ee9c402b23c32853af9d313949eb6e4a)

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

* when git checkouts files from fetched clone it respects system umask
  and creates files with different permissions, if such files are copied
  to packages, resulting target images have also different permissions
  on them.
* we need reproducible builds across different builders with different
  system umask, so set 022 umask

[YOCTO #5590]

(From OE-Core master rev: c9289c506633ffe5c482000d8d225e45454c064d)

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

PREFERRED_PROVIDER_virtual_pkg has been incorrectly set with more
than one multilib prefixes.  For example, if we have two alternative
multilibs lib64 and lib32, PREFERRED_PROVIDER_virtual_pkg will be
set to lib32-lib64-pkg or lib64-lib32-pkg, depending on which
multilib shows up first in the list.

(From OE-Core master rev: 17a432dc059e24ba10d4baec988828c0025a5e46)

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

The PACKAGECONFIG flags were iterated over using dict.items(), but this
returns the items in an undefined order. As this order determines the
EXTRA_OECONF append order, we can get EXTRA_OECONF which are functionally
equivalent, but whose contents differ, resulting in not using shared state
archives we should be using.

(From OE-Core master rev: 843a5dd8f8f0461e286d9fdb3ba55205b4275f88)

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

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 <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>

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

The build banner displayed at the start of builds can be misleading since
the data store has not been finalised. As easy way to illustrate this is
to use something like:

DEFAULTTUNE = "i586"
DEFAULTTUNE_<machineoverride> = "core2"

and the banner will display the i586 tune yet the core2 tune will be
used. We can avoid this if we finalise a copy of the data before
displaying it.

[YOCTO #4225]

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

Now that bitbake supports masking events for event handlers, lets use
this so event handlers are only called for events they care about. This
lets us simplify the code indentation a bit at least as well as mildly
improving the event handling performance.

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