Your message dated Mon, 15 Sep 2014 16:50:19 +0200
with message-id <[email protected]>
and subject line Re: Bug#759404: dpkg-source: base timestamp of patched files
on debian/changelog
has caused the Debian Bug report #759404,
regarding dpkg-source: base timestamp of patched files on debian/changelog
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
759404: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759404
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg-dev
Severity: wishlist
User: [email protected]
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.
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.
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.
I seem to recall a related discussion somewhere, but I can't find it.
Feel free to close this bug if the idea is obviously bad somehow.
[1] at least Perl ones, where pod2man generates a date header in manual
pages. I intend to make this date overridable somehow, probably with
an environment variable, but changing dpkg-source would be a more
general fix
[2] https://wiki.debian.org/ReproducibleBuilds
Thanks for your work & greetings from DebConf14,
--
Niko Tyni [email protected]
--- End Message ---
--- Begin Message ---
On Sun, 2014-08-31 at 05:32:26 +0200, Guillem Jover wrote:
> The more I think about this, the more I'm getting the impression this
> does not sound like a good idea. As mentioned initially, I think it
> would be better to possibly fix any tool that might be generating such
> variable files instead.
Ok, closing now. But please, feel free to reopen if you can think of
counter arguments to the problems I mentioned in the bug report!
Thanks,
Guillem
--- End Message ---
