On Fri, Mar 22, 2019 at 05:42:37PM +0100, Sven Joachim wrote: >On 2019-03-21 20:45 +1100, Brendan O'Dea wrote: >> I suspect that it is related to reproducible builds, [...] >There has indeed been such a change in dpkg-source: > >,---- >| - Generate reproducible source tarballs by using the new GNU tar >| --clamp-mtime option in Dpkg::Source::Archive, to make sure no file >| in source packages has an mtime later than the changelog entry time. >`---- > >However, that was in version 1.18.10, uploaded July 2016. > >It seems that in previous versions of help2man help2man.PL was older >than debian/changelog, so you did not hit the problem.
Ah thanks. I assumed that this was more recent. Looking at some previous source packages, the max date is indeed clamped, but it just so happened that I updated the version in help2man.PL before making the changelog entry so didn't trip over this. Incidentally, I'm slightly puzzled at this behaviour for native packages. Under what circumstances would the source tar ball for a released package be re-built without changing the version? >> I'll try to find a way to revise this check that will be more robust to this >> kind of timestamp modification. Somewhat annoyingly, the "test" builtin has >> -nt and -ot options, but no way to test that timestamps are newer or equal >> (or >> even just equal). > >A negated test with the -ot option might help: > > ! test README -ot help2man.PL # maintainer sanity check Thanks, good suggestion but rather ungainly. I've cooked up a different solution for the next release which doens't depend on the mtimes. --bod
