On 2025-05-10 Bastian Germann <b...@debian.org> wrote: > Hi Andreas,
> Am 10.05.25 um 11:31 schrieb Andreas Metzler: >> It is a no-op, SOURCE_DATE_EPOCH is exactly >> the date from debian/changelog > If that is true, why does SOURCE_DATE_EPOCH change on a binNMU, which > was the reason for this bug? Hello Bastian, a binNMU essentially does dch --bin-nmu which adds a new entry to debian/changelog like this: autogen (1:5.18.16-6+b1) UNRELEASED; urgency=medium, binary-only=yes Seeing the binary-only=yes qualifier dpkg-buildpackage (or something related) takes care off splitting off this entry to a separate file like usr/share/doc/libopts25/changelog.Debian.amd64.gz in the *binary* package and keeps usr/share/doc/libopts25/changelog.Debian.gz unchanged. I have a googled a little bit and I think SOURCE_DATE_EPOCH used to be binNMU-compatible for autogen's usage because the actual software triggering the binNMUs added binary-only=yes changelog entries with the same timestamp as the previous source upload changelog entry. But that was broken otherwise: https://lists.debian.org/debian-devel/2016/11/msg00329.html I will use something equivalent the mtime of configure.ac instead. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
