Notes for cyrus-imapd - reproducible builds result

Version annotated: 2.5.9-2
Identified issues:
Identifier: records_build_flags
Description Records $CFLAGS, which vary intentionally due to the «-fdebug-prefix-map=${BUILDPATH}=.»,
«-ffile-prefix-map=${BUILDPATH}=.» or «-fmacro-prefix-map=${BUILDPATH}=.» flags.
.
We have a patch pending to GCC to fix this issue centrally:
.
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00182.html
.
Though the patch is currently unlikely to be merged. 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.
.
There is also a work-in-progress patch to dpkg that could address this issue:
.
https://bugs.debian.org/985553
.
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: gcc_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.
.
dpkg-buildflags version 1.20.6+ sets -ffile-prefix-map by default
(and -fdebug-prefix-map in older versions) which fixes this issue
in many cases, but not all (see: records_build_flags).
.
There are patches submitted upstream to address this specific issue, but they
are unlikely to be merged at this point:
.
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00513.html
.
When this is accepted into GCC upstream, we could remove this note.
In the meantime, please do not remove this issue, nor mark it as deterministic,
nor untag these packages.
Comments: [The issue described by these comments was fixed upstream in https://github.com/cyrusimap/cyrus-imapd/pull/2931.]
.
The differences in /usr/lib/x86_64-linux-gnu/libcyrus.so.0.0.0 are 100% ordering differences:
each hexdump line (four 32-bit words) appears on both the left and right side of the diff,
but the lines are in a different order.
.
The dbgsym differences suggest that difference is caused by different ordering of chartables:
.
(first build)
00000000000342a0 chartables_iso_8859_3
0000000000034aa0 chartables_iso_8859_2
00000000000352a0 chartables_iso_8859_16
0000000000035aa0 chartables_iso_8859_15
00000000000362a0 chartables_iso_8859_14
0000000000036aa0 chartables_iso_8859_13
00000000000372a0 chartables_iso_8859_11
0000000000037aa0 chartables_iso_8859_10
00000000000382a0 chartables_iso_8859_1
0000000000038aa0 chartables_iso_2022_kr
00000000000792a0 chartables_iso_2022_jp
.
(second build)
00000000000342a0 chartables_iso_8859_3
0000000000034aa0 chartables_iso_8859_2
00000000000352a0 chartables_iso_8859_1
0000000000035aa0 chartables_iso_8859_16
00000000000362a0 chartables_iso_8859_15
0000000000036aa0 chartables_iso_8859_14
00000000000372a0 chartables_iso_8859_13
0000000000037aa0 chartables_iso_8859_11
00000000000382a0 chartables_iso_8859_10
0000000000038aa0 chartables_iso_2022_kr
00000000000792a0 chartables_iso_2022_jp
.
The only difference between these two sets is the location of chartables_iso_8859_1.
.
The static arrays are written by lib/mkchartable.pl in argv order [1], where argv is
the shell glob «lib/charset/*.t» [2], which expands differently in the "C" v. "fr_CH.UTF-8"
locales.
.
Hence, sort()ing the arguments in the Perl script should fix this issue:
https://salsa.debian.org/danielsh-guest/reproducible-patches/blob/master/cyrus-imapd-2.5.9-2.diff
https://salsa.debian.org/debian/cyrus-imapd/commit/0e1488be31999626abaec69286619af30f149dff#note_124081
.
[1] https://sources.debian.net/src/cyrus-imapd/2.5.9-2/lib/mkchartable.pl/#L77
[2] https://sources.debian.net/src/cyrus-imapd/2.5.9-2/Makefile.am/#L1262
 

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