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 <rle...@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...@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