Notes for phonon - reproducible builds result

Version annotated: 4:4.9.0-4
Identified issues:
Identifier: build_id_differences_only
Description The Build ID differs, but there are no other differences.
.
Specifically, NT_GNU_BUILD_ID, .gnu_debuglink, and
/usr/lib/debug/build-id/* filenames differ, but there are no other
differences.
.
[On 'sope' seen also a difference in a .GCC.command.line section; compare 'records_build_flags'.]
.
If there _are_ other differences (or if diffoscope output is truncated),
don't tag with this issue, but look for the root problem, as explained
under build_id_variation_requiring_further_investigation.
.
When this occurs on unstable but not on testing, it's likely a form
of captures_build_path. If it uses the cmake buildsystem, very
likely to be cmake_rpath_contains_build_path.
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: Setting -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON to fix rpath triggers
build failure due to missing .cmake files, but resolves cmake
rpath issue in the binaries.
 

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).