diff options
Diffstat (limited to 'documentation/test-manual/reproducible-builds.rst')
| -rw-r--r-- | documentation/test-manual/reproducible-builds.rst | 25 |
1 files changed, 8 insertions, 17 deletions
diff --git a/documentation/test-manual/reproducible-builds.rst b/documentation/test-manual/reproducible-builds.rst index 5977366c9e..91f94a5c74 100644 --- a/documentation/test-manual/reproducible-builds.rst +++ b/documentation/test-manual/reproducible-builds.rst @@ -19,13 +19,13 @@ Why it matters ============== The project aligns with the `Reproducible Builds project -<https://reproducible-builds.org/>`_, which shares information about why +<https://reproducible-builds.org/>`__, which shares information about why reproducibility matters. The primary focus of the project is the ability to detect security issues being introduced. However, from a Yocto Project perspective, it is also hugely important that our builds are deterministic. When you build a given input set of metadata, we expect you to get consistent output. -This has always been a key focus but, :yocto_docs:`since release 3.1 ("dunfell") -</ref-manual/migration-3.1.html#reproducible-builds-now-enabled-by-default>`, +This has always been a key focus but, :ref:`since release 3.1 ("dunfell") +<migration-guides/migration-3.1:reproducible builds now enabled by default>`, it is now true down to the binary level including timestamps. For example, at some point in the future life of a product, you find that you @@ -68,17 +68,6 @@ things we do within the build system to ensure reproducibility include: - Filtering the tools available from the host's ``PATH`` to only a specific set of tools, set using the :term:`HOSTTOOLS` variable. -.. note:: - - Because of an open bug in GCC, using ``DISTRO_FEATURES:append = " lto"`` or - adding ``-flto`` (Link Time Optimization) to ``CFLAGS`` makes the resulting - binary non-reproducible, in that it depends on the full absolute build path - to ``recipe-sysroot-native``, so installing the Yocto Project in a different - directory results in a different binary. - - This issue is addressed by - :yocto_bugs:`bug 14481 - Programs built with -flto are not reproducible</show_bug.cgi?id=14481>`. - ========================================= Can we prove the project is reproducible? ========================================= @@ -103,10 +92,12 @@ run:: oe-selftest -r reproducible.ReproducibleTests.test_reproducible_builds This defaults to including a ``world`` build so, if other layers are added, it would -also run the tests for recipes in the additional layers. The first build will be -run using :ref:`Shared State <overview-manual/concepts:Shared State>` if +also run the tests for recipes in the additional layers. Different build targets +can be defined using the :term:`OEQA_REPRODUCIBLE_TEST_TARGET` variable in ``local.conf``. +The first build will be run using :ref:`Shared State <overview-manual/concepts:Shared State>` if available, the second build explicitly disables -:ref:`Shared State <overview-manual/concepts:Shared State>` and builds on the +:ref:`Shared State <overview-manual/concepts:Shared State>` except for recipes defined in +the :term:`OEQA_REPRODUCIBLE_TEST_SSTATE_TARGETS` variable, and builds on the specific host the build is running on. This means we can test reproducibility builds between different host distributions over time on the Autobuilder. |