Notes for apper - reproducible builds result

Version annotated: 0.9.2+git20161222-1
Identified issues:
Identifier: captures_build_path_via_assert
Description Absolute paths to source file names are embedded through assert(), which
embeds the value of the __FILE__ macro in the .data section, or via
filenames in debug symbols, which shows in the .text and .debug_str sections.
.
We have a pending patch to GCC to fix this in one central place.
.
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00182.html
.
If/when this is accepted, this issue should be fixed for all packages and
you should not need to fix it specifically in your package.
.
For more background information see:
.
• https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20160822/006788.html
• https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20160905/006984.html
• https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20160912/007076.html
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: Build path captured by RUNPATH attribute, asserts (.rodata), and debug symbols (.dynstr).
.
rpath issue fixed by -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
 

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