Go to file
Richard Purdie 8c3866aa53 do_package/sstate/sstatesig: Change timestamp clamping to hash output only
The code was changing the timestamps of the files in the do_package output,
particularly the files added for debug sources. This was to do two things:

a) make do_package sstate more reproducible
b) ensure better hash equivalence matching

Unfortuately the debug source files are hardlinks into the source tree for
efficiency so touching these, touches a lot of files in ${B} and ${S}. This
causes unpredictable effects if compile is run again for example, or could
cause compiling in the install task.

The hash equivalence matching is of key importance but we can mimic that
using clamping of the file timestamps in the depsig output used to generate
the hashes.

This patch drops the global timestamp clamping, instead allowing the files
to retain their creation timestamps into sstate. This makes do_package sstate
slightly less reproducibile. We could clamp the sstate timestamps but that
would lead to two different sets of timestamps depending on whether the
data came from sstate or not. I'd prefer to have consistent code behaviour,
rather than differing behavhour depending on whether data came from sstate
or not.

If we wanted to have reproducibiliy and fix the "corruption" of S/B and have
consistent codepaths, the only other option would be two copies of the
sources, which could end up huge and seems the least desireable option.

This patch therefore drops the timestamp clamping in the sstate files
and tweaks the depsig data generation to clamp the timestamps for do_package
instead since this seems the best compromise.

I validated that rpm/deb/ipk files still generate correctly as before.

(From OE-Core rev: 0e6b2c761f6d727fe21a0ce2803a0f0aef236f59)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 475759fdab7200488b2a568b2ba1aa31a456d113)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
2024-12-09 06:25:53 -08:00
bitbake bitbake: runqueue: Fix scenetask processing performance issue 2024-12-09 06:25:53 -08:00
contrib contrib/git-hooks: add a sendemail-validate example hook that adds FROM: lines to outgoing patch emails 2020-12-30 14:01:07 +00:00
documentation dev-manual: bblock: use warning block instead of attention 2024-11-26 05:37:10 -08:00
meta do_package/sstate/sstatesig: Change timestamp clamping to hash output only 2024-12-09 06:25:53 -08:00
meta-poky poky.conf: bump version for 5.1.1 2024-11-30 05:41:59 -08:00
meta-selftest oeqa/selftest/bbclasses: Add tests for systemd and update-rc.d interaction 2024-09-01 11:05:20 +01:00
meta-skeleton useradd-example: Fix S = WORKDIR reference 2024-05-23 11:26:39 +01:00
meta-yocto-bsp layer.conf: Update to styhead 2024-09-06 18:39:44 +01:00
scripts scripts/install-buildtools: Update to 5.1 2024-11-30 05:41:59 -08:00
.gitignore vscode: drop .vscode folder 2024-02-19 11:34:33 +00:00
.templateconf meta-poky/conf: move default templates to conf/templates/default/ 2022-09-01 10:07:02 +01:00
LICENSE meta/lib+scripts: Convert to SPDX license headers 2019-05-09 16:31:55 +01:00
LICENSE.GPL-2.0-only meta/lib+scripts: Convert to SPDX license headers 2019-05-09 16:31:55 +01:00
LICENSE.MIT meta/lib+scripts: Convert to SPDX license headers 2019-05-09 16:31:55 +01:00
MAINTAINERS.md MAINTAINERS.md: fix patchtest entry 2024-06-25 11:50:58 +01:00
MEMORIAM MEMORIAM: Add recognition for contributors no longer with us 2020-01-30 15:22:35 +00:00
oe-init-build-env oe-init-build-env: generate .vscode from template 2024-02-19 11:34:33 +00:00
README.hardware.md README: Move to using markdown as the format 2021-06-16 16:33:18 +01:00
README.md Add README link to README.poky 2021-07-19 18:07:21 +01:00
README.OE-Core.md README: fix mail address in git example command 2023-09-04 10:27:46 +01:00
README.poky.md README: Move to using markdown as the format 2021-06-16 16:33:18 +01:00
README.qemu.md README.OE-Core/README.qemu: Move to markdown format 2021-07-20 08:51:06 +01:00
SECURITY.md SECURITY.md: add file 2023-10-19 11:31:13 +01:00

Poky

Poky is an integration of various components to form a pre-packaged build system and development environment which is used as a development and validation tool by the Yocto Project. It features support for building customised embedded style device images and custom containers. There are reference demo images ranging from X11/GTK+ to Weston, commandline and more. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK suitable for IDE integration.

Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of BSP layers which extend the systems capabilities in a modular way. Many layers are available and can be found through the layer index.

As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation, the 'meta-yocto' layer which has configuration and hardware support components. These components are all part of the Yocto Project and OpenEmbedded ecosystems.

The Yocto Project has extensive documentation about the system including a reference manual which can be found at https://docs.yoctoproject.org/

OpenEmbedded is the build architecture used by Poky and the Yocto project. For information about OpenEmbedded, see the OpenEmbedded website.

Contribution Guidelines

Please refer to our contributor guide here: https://docs.yoctoproject.org/dev/contributor-guide/ for full details on how to submit changes.

Where to Send Patches

As Poky is an integration repository (built using a tool called combo-layer), patches against the various components should be sent to their respective upstreams:

OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):

BitBake (files in bitbake/):

Documentation (files in documentation/):

meta-yocto (files in meta-poky/, meta-yocto-bsp/):

If in doubt, check the openembedded-core git repository for the content you intend to modify as most files are from there unless clearly one of the above categories. Before sending, be sure the patches apply cleanly to the current git repository branch in question.

CII Best Practices