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...@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
signature.asc
Description: signature
