misleading timestamps in binnmus

[Guillem Jover]

Hi!

On Tue, 2016-11-08 at 22:41:09 +0000, Ian Jackson wrote:
> I see the python2.7 source package does this:
> 
>  LAST_CHANGE := $(shell dpkg-parsechangelog -S Date)
>  export BUILD_DATE := $(shell LC_ALL=C date -u +'%b %e %Y' -d '$(LAST_CHANGE)')
>  export BUILD_TIME := $(shell LC_ALL=C date -u +'%H:%M:%S' -d '$(LAST_CHANGE)')
> 
> Is this a recommended recipe ?

I think this should be fine. There's also SOURCE_DATE_EPOCH, that
dpkg-buildpackage honors and otherwise sets now, which can be also
retrieved with «dpkg-parsechangelog -STimestamp», but that should not
be needed here anyway, because…

> AIUI a buildd doing a binnmu will not
> modify the debian/changelog file.

… the changelogs do get a new entry, otherwise everything would fall
apart. Something like this:

,---
zlib (1:1.2.8.dfsg-2+b3) sid; urgency=low, binary-only=yes

  * Binary-only non-maintainer upload for amd64; no source changes.
  * Recompile static libraries with PIE

 -- amd64 / i386 Build Daemon (x86-grnet-01) <buildd_amd64-x86-grnet-01 at buildd.debian.org>  Sat, 16 Aug 2014 15:12:11 +0100
`---

But I just noticed that the timestamp in this entry seemed suspect,
and it indeed is, as the last maintainer upload was this:

,---
zlib (1:1.2.8.dfsg-2) unstable; urgency=low

  * Drop zlib-bin package as minizip has now been packaged separately,
    delay due to lack of notice regarding upload (closes: #753070).

 -- Mark Brown <broonie at debian.org>  Sat, 16 Aug 2014 15:12:11 +0100
`---

> The result is that the file timestamps will be lies after a binnmu.  I
> think this is quite undesirable.  Less careful backup programs than
> mine wouldn't notice.  The results would then be a corrupted backup,
> which would break when restored.  There are probably other bad
> consequences.

So the actual problem is that the last timestamp gets reused for the
binNMUs, which seems totally bogus to me. This needs to be fixed in
whatever is injecting the binNMU entries on the buildds.

Thanks,
Guillem