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>

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>

I've been giving things some thought, specifically why sstate doesn't
get used more and why we have people requesting external toolchains. I'm
guessing the issue is that people don't like how often sstate can change
and the lack of an easy way to lock it down.

Locking it down is actually quite easy so patch implements some basics
of how you can do this (for example to a specific toolchain). With an
addition like this to local.conf (or wherever):

SIGGEN_LOCKEDSIGS = "\
gcc-cross:do_populate_sysroot:a8d91b35b98e1494957a2ddaf4598956 \
eglibc:do_populate_sysroot:13e8c68553dc61f9d67564f13b9b2d67 \
eglibc:do_packagedata:bfca0db1782c719d373f8636282596ee \
gcc-cross:do_packagedata:4b601ff4f67601395ee49c46701122f6 \
"

the code at the end of the email will force the hashes to those values
for the recipes mentioned. The system would then find and use those
specific objects from the sstate cache instead of trying to build
anything.

Obviously this is a little simplistic, you might need to put an override
against this to only apply those revisions for a specific architecture
for example. You'd also probably want to put code in the sstate hash
validation code to ensure it really did install these from sstate since
if it didn't you'd want to abort the build.

This patch also implements support to add to bitbake -S which dumps the
locked sstate checksums for each task into a ready prepared include file
locked-sigs.inc (currently placed into cwd). There is a function,
bb.parse.siggen.dump_lockedsigs() which can be called to trigger the
same functionality from task space.

A warning is added to sstate.bbclass through a call back into the siggen
class to warn if objects are not used from the locked cache. The
SIGGEN_ENFORCE_LOCKEDSIGS variable controls whether this is just a warning
or a fatal error.

A script is provided to generate sstate directory from a locked-sigs file.

(From OE-Core rev: 7e14784f2493a19c6bfe3ec3f05a5cf9797a2f22)

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