Notes for r-base - reproducible builds result

Version annotated: 3.4.0-1
Identified issues:
Identifier: timestamps_in_gzip_headers
URL https://wiki.debian.org/ReproducibleBuilds/TimestampsInGzipHeaders
Description gzip stores a timestamp by default in its header.
Identifier: user_hostname_manually_added_requiring_further_investigation
Description Packages which intentionally capture the username or hostname into a custom format,
but aren't obviously using any tool or system which has this as a core issue.
Interesting because they could be fixed by fixing these things at build time.
Identifier: captures_shell_variable_in_autofoo_script
Description Something looking like autotools is capturing SHELL for use at
runtime, which should probably be fixed to /bin/sh anyway.
.
Autotools also capturing the build path.
Identifier: timestamps_in_manpages_generated_by_help2man
URL https://bugs.debian.org/787444
Description Manpages generated with help2man embed the month and year by default.
This has been fixed in help2man version 1.4.71, released in 2015,
so typically only occurs when using an embedded copy of help2man.
Identifier: captures_build_path
Description Captures build path, e.g., /build/1st/foo-42.0 v. /build/foo-42.0/2nd
.
Until early 2024 we varied the build path when testing packages from unstable
and experimental, which we have stopped doing now as the build path is recorded
as part of the environment and thus can be used when rebuilding.
.
This issue is kept here for the time being.
.
This issue is only for miscellaneous issues which need individual fixes,
please create new issues for specific issues, e.g. gcc_captures_build_path.
.
Here follows some general tips for packages using the standard GNU toolchain:
.
If using autoconf, make sure you call ./configure via a relative and not absolute path.
.
If your issue is related to using the `__FILE__` macro, or the recording of
--debug-prefix-map flags in non-GCC non-debugging output, this is what is
fixed by our patch mentioned above; 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: different_encoding
Description Files were built with different encoding (non-UTF-8 vs. UTF-8).
Identifier: randomness_in_r_rdb_rds_databases
Description R creates .rdb files and .rds with some randomness. They are a serialisation of some
sorts, related to lazy loading of modules?
Randomness seems to come from using absolute paths in .rd[bs] files.
.
Is not related to https://bugs.debian.org/774031 / r_base_appends_built_header_to_description_files
.
We have a pending patch to fix most of these (463/478) packages at the time
of writing) upstream in R:
.
https://stat.ethz.ch/pipermail/r-devel/2017-April/074138.html
.
When this is accepted into R upstream, commit 28d4af25 may be
(un-)reverted to remove these packages. In the meantime, please do not
remove this issue, nor mark it as deterministic, nor untag these packages.
.
The remaining ~15 packages are not completely fixed by this patch, so this
issue should remain, even when our upstream patch is accepted. These
packages will need to be investigated and fixed individually, see our blog
post on how to do that:
.
https://reproducible-builds.org/news/2017/05/03/reproduciing-r-packages/
Bugs noted: 862112
Comments: Previously had paths_vary_due_to_usrmerge, but this appears to have
been fixed in bullseye.
 

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