[OE-core] [PATCH 0/3] Fix problem with leftover files in tmp/sysroots-components

Peter Kjellerstedt peter.kjellerstedt at axis.com
Fri Apr 6 18:26:54 UTC 2018


We have seen problems where sometimes files are leftover in
tmp/sysroots-components when changing PACKAGE_ARCH for a package. This
could then lead to those files being picked up instead of the real
files when the RSS for another package was created.

It turned out that this happened if the original architecture of the
package was one that was added using PACKAGE_EXTRA_ARCHS. Those extra
architectures were not handled in the sstate_eventhandler2() function
in sstate.bbclass that does the clean up of tmp/sysroots-components.

During the course of debugging this problem I also noticed that there
were two index files in tmp/sstate-control for machines that contain a
dash in their names. This turned out to be due to the use of the
stamp-extra-info task flag for some tasks, which were using ${MACHINE}
rather than ${MACHINE_ARCH} to specify the architecture. Since this
seemed inconsistent and confusing, I fixed that as well.

//Peter

The following changes since commit 312a5a93cac95fe62c56e374db728c825b272e64:

  layer.conf: Update LAYERSERIES rocko -> sumo (2018-04-06 11:39:49 +0100)

are available in the git repository at:

  git://push.yoctoproject.org/poky-contrib pkj/extra-archs-in-sstate

Peter Kjellerstedt (3):
  Use ${MACHINE_ARCH} instead of ${MACHINE} for stamp-extra-info task
    flag
  sstate.bbclass: Add ${PACKAGE_EXTRA_ARCHS} to SSTATE_ARCHS
  license.bbclass: Minor simplification of get_deployed_dependencies()

 meta/classes/deploy.bbclass            | 2 +-
 meta/classes/image.bbclass             | 2 +-
 meta/classes/license.bbclass           | 4 +---
 meta/classes/package.bbclass           | 2 +-
 meta/classes/populate_sdk_base.bbclass | 2 +-
 meta/classes/populate_sdk_ext.bbclass  | 2 +-
 meta/classes/sstate.bbclass            | 5 +++--
 meta/recipes-core/meta/signing-keys.bb | 3 ++-
 8 files changed, 11 insertions(+), 11 deletions(-)

-- 
2.12.0



More information about the Openembedded-core mailing list