[buildd-tools-devel] Bug#843773: misleading timestamps in binnmus

[Emilio Pozuelo Monfort]

On 10/11/16 10:00, Ansgar Burchardt wrote:
> On Wed, 2016-11-09 at 10:04 +0100, Sven Joachim wrote:
>> On 2016-11-08 22:30 -0200, Johannes Schauer wrote:
>>> It seems that sbuild indeed re-uses the timestamp from the last
>>> debian/changelog entry in the binNMU changelog entry.
>>
>> This has been done in an early attempt to make binNMUs co-installable 
>> in a multiarch world:
>>
>> ,----
>>> sbuild (0.62.2-1) unstable; urgency=low
>>> [...]
>>>     - Improve binNMU handling to permit binNMUs for multiarch
>>> packages
>>>       (Closes: #620112).  Currently, binary NMUs use the current
>>> date
>>>       in the new changelog entry, but co-installable packages
>>> require
>>>       an identical changelog.  To avoid this, take the date from
>>> the
>>>       previous changelog entry to ensure the same date for all
>>> binNMUs.
>>> [...]
>>>  -- Roger Leigh <rleigh at debian.org>  Tue, 05 Apr 2011 10:46:49
>>> +0100
>>
>> `----
>>
>> Which did not help, because the changelog is not actually identical
>> anyway.
> 
> The date from the last sourceful upload should probably still be used
> for any date/time information included in generated files to ensure
> they are identical on all architectures (or at least to try to do so).
> 
> If you change the date in the binNMU entry, SOURCE_DATE_EPOCH should
> probably be set to the date of the last sourceful upload (instead of
> just using the most recent changelog entry).

There are many differences among different architectures, see e.g.:

lame (3.99.5+repack1-9+b1) sid; urgency=low, binary-only=yes

  * Binary-only non-maintainer upload for amd64; no source changes.
  * Rebuild against ncurses 6.0.

 -- amd64 / i386 Build Daemon (x86-csail-01)
<buildd_amd64-x86-csail-01 at buildd.debian.org>  Thu, 11 Jun 2015 12:33:22 +0200

But that is not a problem as the entry is added to changelog.$arch for this reason.

Cheers,
Emilio