Version annotated: |
3.4.0-1 |
Identified issues:
|
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).
|