To avoid races between the sstate tasks/hooks using ${B} as the cwd, and other
tasks such as cmake_do_configure which deletes and re-creates ${B}, ensure that
all sstate hooks are run in the right directory, and run the prefunc/postfunc in WORKDIR.

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

FILESPATH was only being overridden in one fetch location, it should be
equally handled in both.

Also use SSTATE_DIR as FILESPATH so that mirror urls which do remapping
can search the local SSTATE_DIR for other paths.

Also ensure that MIRRORS is removed in both locations, previously
it was only unset in one but both codepaths should be consistent.

(From OE-Core rev: ab6bebddbdefec323e284b6438d9c57b3d8a2cc3)

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

Without this patch the source archiver class is not allowed to
archive the same source archive for different builds.

Signed-off-by: Adrian <adrian.freihofer@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Commit e9672387 split one long line into a multi-line string, but in
the process white space between words was lost. This results in badly
formatted output when this message is printed.

Signed-off-by: Peter Urbanec <openembedded-devel@urbanec.net>

For some recipes that inhrient cmake, the ${B} may be removed by
cmake_do_configure() while sstate_hardcode_path() running, this
causes build errors:

  Exception: OSError: [Errno 2] No such file or directory: \
  '/path/to/build'

The function sstate_hardcode_path() called command:

  $SSTATE_SCAN_CMD which extended as "find ${SSTATE_BUILDDIR} ..."

So the proper function dirs could be ${SSTATE_BUILDDIR}.

Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

The too long line would cause "git send-email" report errors:
patch contains a line longer than 998 characters

Though we can use "--no-validate" to force the send.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>

The code:
bb.fatal("foo1")
bb.fatal("foo2")

Would make the second one not work, use bb.error for first one to fix
the problem.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>

The packagegroup allarch rpm files for multilib can overwrite each other since
they are in theory indentical (in contrast to the other backends). We therefore
need to whitelist this to avoid build failures now this overwrite failure
is fatal.

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

Update the sstate file's timestamps after it is installed, it will be
very useful for removing the old sstate file, especially, it's not easy
to remove when use the shared SSTATE_DIR, we can easily remove them with
this change, for example:

$ find state-cache -type f -ctime +10 -exec rm -f {} \;

Will remove the sstate file which isn't used by recent 10 days.

We can use the -atime, but it is not always available, for example,
when mounted with "-o noatime".

The touch is a very light weight action, and the
scripts/sstate-cache-management.sh also requires this.

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

When files overlap in the sysroot, something bad usually happened. We've had
two independent cases recently where a couple of months after one of these
warnings was shown, builds failed due to corruption.

This change moves the warning to become a fatal error. The complaint I've had
about this is that we need to tell the user what happened and more importantly
how to recover from it. If we could recover from it, great but the trouble is
we simply don't know what happened.

As a compromise, we can document several of the possible scenarios in the error
message. We don't normally go to this level of detail however in this case, I'm
lacking other viable alternatives.

I do believe it is important to stop as corruption occurs rather than letting the
build contunue into territory that is not deterministic amongst other things.

The complex message is followed by a simpler one in case the long message is too
much for the user.

(From OE-Core rev: 179ac7de03977b6e440409eddb2166819e07286a)

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