My take is that it is a bug to use SOURCE_DATE_EPOCH to populate the timestamp inside a man page. This is just one of many symptoms that will arise from trying to use SOURCE_DATE_EPOCH in an upstream context.
It seems generally better if upstream derive timestamps inside artifacts from the source code for that artifact, or the last upstream release if tracking the source code is problematic. Then these timestamps will be stable during all future rebuilds of the same artifact. In this case, is the problem triggered by this line? https://salsa.debian.org/debian/autogen/-/blob/8b4268fa779deaba862a7938ee0d5f051860d8e7/debian/rules#L11 If so, the problem is not in upstream but in the packaging. A more relevant timestamp to use appears to be the last upstream release timestamp, or the timestamp from debian/changelog (sdate, not bdate). Using SOURCE_DATE_EPOCH here seems just wrong on a conceptual level. I mentioned this earlier: https://alioth-lists.debian.net/pipermail/reproducible-builds/Week-of-Mon-20250120/014989.html and gnulib provides a mechanism to derive a timestamp for source code: https://lists.gnu.org/archive/html/bug-gnulib/2025-05/msg00007.html /Simon
signature.asc
Description: PGP signature
