On Wed, Mar 11, 2015 at 10:01:07AM +0000, 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
