Hi! On Tue, 2014-08-26 at 17:51:22 -0700, Niko Tyni wrote: > Package: dpkg-dev > Severity: wishlist > User: reproducible-bui...@lists.alioth.debian.org > Usertags: toolchain, timestamps > > Some build systems [1] embed the time stamp of source files into the > binary package. For the benefit of reproducible builds [2], it would > be nice if these time stamps would not reflect the current time on the > build system where possible.
I think the “correct” fix might actually lay there. See below. > Currently, dpkg-source will set the time stamp of a patched file to the > current time when unpacking. This is documented behaviour for the 1.0 > source format: > > The timestamp of all patched files is reset to the extraction time of > the source package (this avoids timestamp skews leading to problems > when autogenerated files are patched). > > but I don't see such guarantees for the case of 3.0 (quilt) packages. Right this is not spelled out, but it should have been documented to behave the same. I'll be fixing the man page. > For (at least) those, would it make sense to set the time stamp of the > patched file to the latest time stamp in debian/changelog (probably > excluding binNMUs, but those aren't in debian/changelog nowadays anyway) ? > > (An obvious alternative to this is the time stamp of the patch file itself > in debian/patches, but that has the disadvantage that the patch file > may often be older than the current upstream version if an old patch > applied fine without any modifications.) > > I can see that this could cause timestamp skew in packages if the Debian > packaging is older than files in the upstream tarball. This seems like > it's always a (minor) bug in the package, and dpkg-source could probably > notice that it's "rewinding" the time stamp backward and fall back to > using the current time instead. The problem is that I don't see how dpkg-source can always tell if it's “rewinding” in such case, it could tell if the new timestamp is older than the current one, but it might not be able to tell if the new timestamp is older than one from a file that depends (in make terms) on this file for example. This also gets more complicated when dealing with NFS mounts, which the current code is already handling correctly. Although some of these situations might show up from timestamp skews due to mismatched times from upstream, packager, or build systems for example, that's just a reality that I'm not sure we can ignore. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
