Marius Bakke <mba...@fastmail.com> skribis: > Ludovic Courtès <l...@gnu.org> writes: > >> Leo Famulari <l...@famulari.name> skribis: >> >>> On Thu, Jun 16, 2016 at 11:39:27AM -0400, Leo Famulari wrote: >>>> On Thu, Jun 16, 2016 at 01:33:46PM +0200, Ludovic Courtès wrote: >>>> > The problem is described in >>>> > <git://git.debian.org/git/reproducible/notes.git>: >>>> > >>>> > --8<---------------cut here---------------start------------->8--- >>>> > timestamps_in_documentation_generated_by_podman: >>>> > description: | >>>> > The module Pod::Man includes timestamps in its embedded manpages: >>>> > >>>> > http://sources.debian.net/src/perl/latest/cpan/podlators/lib/Pod/Man.pm/?hl=1700#L977 >>>> > They should be based on the mtime of the original file. >>>> > url: >>>> > https://wiki.debian.org/ReproducibleBuilds/TimestampsInManpagesGeneratedByPodMan >>>> >>>> According to the information on this page, we should set POD_MAN_DATE >>>> while building. Should we make the perl-build-system export this >>>> variable? Set to SOURCE_DATE_EPOCH? >>> >>> I noticed that Pod::Man is supposed to respect SOURCE_DATE_EPOCH, as of >>> the upstream module version 4.03 (released 2015-12-06). Does anyone know >>> how to check the version of the module bundled into perl? >> >> For the record, even though Pod::Man supposedly honors SOURCE_DATE_EPOCH >> as of Perl 5.24, we still have this problem: >> >> --8<---------------cut here---------------start------------->8--- >> $ diff -r >> /gnu/store/hczskszmhm2l65vy8nv990lzc5dk3ln9-perl-algorithm-c3-0.10{,-check} >> diff -r >> /gnu/store/hczskszmhm2l65vy8nv990lzc5dk3ln9-perl-algorithm-c3-0.10/lib/perl5/5.24.0/x86_64-linux-thread-multi/perllocal.pod >> >> /gnu/store/hczskszmhm2l65vy8nv990lzc5dk3ln9-perl-algorithm-c3-0.10-check/lib/perl5/5.24.0/x86_64-linux-thread-multi/perllocal.pod >> 1c1 >> < =head2 Wed Jan 11 22:20:36 2017: C<Module> L<Algorithm::C3|Algorithm::C3> >> --- >>> =head2 Wed Jan 11 22:20:34 2017: C<Module> L<Algorithm::C3|Algorithm::C3> >> --8<---------------cut here---------------end--------------->8--- > > Isn't this fixed by be12f4e27505edd87c4aa457fec43dd0fee23b79 from > 'core-updates'?
Oh, probably! I had forgotten about it, thanks for the heads-up. Ludo’.
