On Wed, Mar 11, 2015 at 10:01:07AM +, Chris Lamb wrote:
While working on the reproducible builds effort [1], we have noticed
that Pod::Man generates output that varies depending on the current
timezone.
The attached patch fixes this by using GMT (~UTC) dates instead
Thanks. Unlike Axel, I'm not very worried about this creating confusion
for users far away from UTC, given that only the date part is embedded.
However, I agree that modifying TZ in the build environment would be a
more general (and probably sufficient) fix.
However, I have other concerns. Sorry for taking so long to voice them.
I'd like to note that there are two somewhat separate issues
with building reproducible packages involving Pod::Man. Both of these
derive from its longstanding feature of embedding the date part of the
mtime stamp of its source file.
A) the local time zone affects the mtime - date conversion (this bug)
B) source files patched by the Debian packaging will have their
mtime set to the current time when the package is extracted, and
therefore the date in the manual page headers will vary with the
build date
While the provided patch fixes A) but not B), I expect the fix for B)
would fix A) as well.
According to codesearch.debian.net, we have 819 packages in sid that patch
*.pm or *.pod files (my search was \+\+\+ .*\.(pm|pod) path:debian/patches).
I would expect that most of these generate manual pages with Pod::Man.
I think the current reproducible builds test setup hasn't found these
yet because it is not comparing packages built on different days.
So B) seems worth fixing.
After trying unsuccessfully to get dpkg-source to set the mtime stamp
of patched files to the last debian/changelog entry (see #759404), we
ended up with a change in Pod::Man where it honours the POD_MAN_DATE
environment variable and uses that as the header rather than anything
based on mtime stamps (or timezones, for that matter.) This is properly
upstream and available in sid and jessie, see #759405.
A downside of this is that POD_MAN_DATE will affect all the manual pages
generated by Pod::Man and remove the potentially useful indications of
their recency. I can't really see how to avoid that, but possibly we
should set POD_MAN_DATE to something that isn't really a timestamp at
all, so as not to mislead readers. Given the check for a true value in
devise_date(), an empty string isn't an option, but a space or 'N/A'
come to mind.
So I argue that the best way to fix this bug in the long term is to
somehow set POD_MAN_DATE based on debian/changelog, as that fixes both A)
and B). The patch provided in this bug seems more like an interim fix,
but I'm certainly glad that it helps the current testbed deployment.
As Holger noted in the TZ discussion, one problem is where to set such
environment variables. I think debhelper is the easier and most natural
place, particularly as it has already collected other patches related
to reproducible builds. The few packages (like perl itself) not using
debhelper can perfectly well set POD_MAN_DATE themselves.
(As an aside,I'm wondering if it would make sense to standardize on
DEB_BUILD_OPTIONS=reproducible or something to trigger tweaks like this.)
--
Niko Tyni nt...@debian.org
___
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds
