Hi, Quoting Emilio Pozuelo Monfort (2016-11-10 07:04:55) > On 10/11/16 10:00, Ansgar Burchardt wrote: > > 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@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. ansgar is not just talking about the changelog which indeed lives in different files, depending on the host architecture. What if there are files that are shared by a M-A:same package but with content that depends on SOURCE_DATE_EPOCH? If we just generate a new date for every individual build, then these files will be different and the package not be co-installable anymore. Quoting Sven Joachim (2016-11-10 07:14:27) > Wouldn't this cause dpkg-deb to clamp the mtime to that date, precisely > the problem this thread is all about? yes, which is why we probably shouldn't set SOURCE_DATE_EPOCH to the same value again but find a different solution. One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every binNMU to a package. Any other ideas? Thanks! cheers, josch
Attachment:
signature.asc
Description: signature