Notes for shasta - reproducible builds result

Version annotated: 0.8.0-2
Identified issues:
Identifier: dynstr_section_longer_by_two_bytes_which_are_NULs
Description The .dynstr section on the right build is longer by two bytes.
The value of those two bytes is 0x00 0x00.
.
stlink=1.7.0+ds-1 is currently in both bullseye and sid; is reproducible on
the former but not on the latter; and has this issue. The issue could be
caused by a difference in some build dependency between the two suites (for
some common build dependency of all packages having this issue); or by
a difference in the variations tested in the two suites.
.
The only difference in variations (per current "Variations tested" page) is
the build path variation.
.
If the package uses the cmake buildsystem, this is likely a form
of cmake_rpath_contains_build_path issue.
.
So, is there any any chance that this issue is caused by the build path
variation? Perhaps the number of extra bytes is 2
because the build path in build #2 is two bytes longer than in build
#1?

Identifier: cmake_rpath_contains_build_path
URL https://gitlab.kitware.com/cmake/cmake/issues/18413
Description When an executable is linked with a shared library from the same project,
RPATH will contain the build path. Even if this is stripped on installation,
the build-id will remain unchanged.
.
With CMake 3.14+, packages can set `-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON` to
fix the issue. This is done automatically when using the currently
experimental debhelper compat level v14.
https://cmake.org/cmake/help/latest/prop_tgt/BUILD_RPATH_USE_ORIGIN.html
.
When working with older CMake versions, the `CMAKE_SKIP_RPATH` option can be
enabled instead, but it may be required to also set `LD_LIBRARY_PATH` while
running tests.
Comments: Very similar to dynstr_section_longer_by_two_bytes_which_are_NULs (hence
tagging this package with that issue), but the two added bytes aren't last.
.
With -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON the chrpath --replace call
fails because the replacement path is longer than the relative path.
 

Our notes about issues affecting packages are stored in notes.git and are targeted at packages in Debian in 'unstable/amd64' (unless they say otherwise).