openembedded-core.git/meta/classes/sstate.bbclass, branch uninative-1.3

meta-extsdk-toolchain: add meta-recipe to install toolchain into eSDK

2016-07-25T22:47:02+00:00

Add a meta-recipe to bring the toolchain into the extensible SDK. This
was modelled on meta-ide-support but some adjustments were needed to the
dependency validation function in sstate.bbclass to ensure that all of
the toolchain gets installed into the sysroot. With this, after
installing a minimal eSDK you only need to run the following after
sourcing the environment setup script to get the toolchain:

  devtool sdk-install meta-extsdk-toolchain

Addresses [YOCTO #9257].

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

sstate.bbclass: make PV to depend on PV variable value

2016-07-20T09:24:49+00:00

Currently PV is defined in meta/conf/bitbake.conf as a python
expression: "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE',
False),d)[1] or '1.0'}". As FILE is whitelisted it causes PV to
not depend on it. This causes sstate code to not detect that
PV changes when recipe filename changes.

Making PV to explicitly depend on PV variable value overrides default
behaviour. Instead of depending on python expression bitbake depends
on evaluated value of PV variable, which should fix the above
mentioned issue.

[YOCTO #9806]

Signed-off-by: Ed Bartosh 
Signed-off-by: Ross Burton

classes/sstate: add a mode to error if sstate package unavailable

2016-07-07T12:29:01+00:00

If BB_SETSCENE_ENFORCE is set to "1" and an sstate package fails to
download outside of the whitelist specified by
BB_SETSCENE_ENFORCE_WHITELIST, then fail immediately so you can tell
that the problem was caused by failing to restore the task from sstate.

Part of the implementation of [YOCTO #9367].

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

classes/sstate: show progress during sstate object availability check

2016-07-07T12:29:01+00:00

Show progress through bitbake's standard terminal UI when checking for
shared state object availability, since this can take some time if there
are a large number of tasks to be executed and/or the network connection
is slow.

Part of the implementation for [YOCTO #5853].

Signed-off-by: Paul Eggleton 
Signed-off-by: Richard Purdie

classes/lib: Convert to use python3 octal syntax

2016-06-02T07:10:02+00:00

The syntax for octal values changed in python3, adapt to it.

Signed-off-by: Richard Purdie

sstate.bbclass: Don't create symlinks, download to the correct location

2016-05-25T06:49:53+00:00

Previously the sstate was all downloaded to the same directory and then
symlinks were added in the directories that pointed to the siginfo and
sstate in the parent directory.

This change makes it so that now the files are just downloaded to the
correct location without the need for symlinks.

Signed-off-by: Randy Witt 
Signed-off-by: Richard Purdie

sstate: Ensure we sort the value used for SSTATETASKS for determinism

2016-05-16T22:23:58+00:00

This avoids 'basehash changed' errors with python 3 but could break
build determinism in general.

Signed-off-by: Richard Purdie

sstatesig.py: Split single locked sigs check into multiple checks

2016-04-08T06:53:09+00:00

Add the SIGGEN_LOCKEDSIGS_TASKSIG_CHECK and
SIGGEN_LOCKEDSIGS_SSTATE_EXISTS_CHECK variables to replace
SIGGEN_LOCKEDSIGS_CHECK_LEVEL.

SIGGEN_LOCKEDSIGS_TASKSIG_CHECK will no control whether there is a
warning or error if a task's hash in the locked signature file doesn't match
the computed hash from the current metadata.

SIGGEN_LOCKEDSIGS_SSTATE_EXISTS_CHECK will control whther there is a
warning or error if a task that supports sstate is in the locked
signature file, but no sstate exists for the task.

Previously you could only have warning/errors for both controlled by
SIGGEN_LOCKEDSIGS_CHECK_LEVEL. This was an issue in the extensible sdk,
because we know sstate won't exist for certain items in the reverse
dependencies list for tasks. However, we still want to error if task
signatures don't match.

[YOCTO #9195]

Signed-off-by: Randy Witt 
Signed-off-by: Richard Purdie

useradd.bbclass: remove user/group created by the package in clean* task

2016-04-06T09:29:57+00:00

At present, if a recipe is built which creates users/groups via
useradd.bbclass, those users/groups are not removed from sysroot
when the recipe/package is cleaned using clean/cleansstate/cleanall
or when a recipe is rebuild and 'unstaged' from the the sysroot.

The "userdel_sysroot_sstate()" provides that functionality.

[YOCTO #9262]

Signed-off-by: Maxin B. John 
Signed-off-by: Richard Purdie

sstate: Allow late expansion of NATIVELSBSTRING

2016-03-07T10:47:45+00:00

uninative needs to adjust NATIVELSBSTRING fairly late in the
configuration parsing process but the sstate code encodes it into
variables. Since this string doesn't vary on a per recipe basis, we
defer its expansion until usage time.

Signed-off-by: Richard Purdie