[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#925136: help2man: FTBFS in unstable (dh_clean fails)



On 2019-03-21 20:45 +1100, Brendan O'Dea wrote:

> On Wed, Mar 20, 2019 at 10:21:39AM +0100, Gianfranco Costamagna wrote:
>>Looks like README needs a newer timestamp wrt help2man.PL file?
> [...]
>>dpkg-buildpackage: info: host architecture amd64
>> fakeroot debian/rules clean
>>test README -nt help2man.PL  # maintainer sanity check
>>make: *** [debian/rules:40: clean] Error 1
>
> Well this is odd, it seems that there has been a change in dpkg-source which
> breaks this particular sanity check (intended to ensure that I've run the
> maint-prep step since updating the version in help2man.PL).
>
> I suspect that it is related to reproducible builds, since the timestamps that
> ended up in the tarball have been changed to the changlog timestamp (in fact
> there are no files in the tarball with later dates).

There has indeed been such a change in dpkg-source:

,----
|     - Generate reproducible source tarballs by using the new GNU tar
|       --clamp-mtime option in Dpkg::Source::Archive, to make sure no file
|       in source packages has an mtime later than the changelog entry time.
`----

However, that was in version 1.18.10, uploaded July 2016.

It seems that in previous versions of help2man help2man.PL was older
than debian/changelog, so you did not hit the problem.

>  ~/debian/help2man-1.47.9 $ ls -l README help2man.PL
>  -rw-r--r--   1 bod            bod           540 2019-03-18 19:16 README
>  -rwxr-xr-x   1 bod            bod         23166 2019-03-18 19:13 help2man.PL
>  ~/debian/help2man-1.47.9 $ tar tvJf ../help2man-1.47.9.tar.xz help2man-1.47.9/README help2man-1.47.9/help2man.PL
>  -rw-r--r-- 0/0             540 2019-03-18 19:10 help2man-1.47.9/README
>  -rwxr-xr-x 0/0           23166 2019-03-18 19:10 help2man-1.47.9/help2man.PL
>  ~/debian/help2man-1.47.9 $ dpkg-parsechangelog -S Date
>  Mon, 18 Mar 2019 19:10:35 +1100
>
> I'll try to find a way to revise this check that will be more robust to this
> kind of timestamp modification.  Somewhat annoyingly, the "test" builtin has
> -nt and -ot options, but no way to test that timestamps are newer or equal (or
> even just equal).

A negated test with the -ot option might help:

	! test README -ot help2man.PL # maintainer sanity check

Cheers,
       Sven


Reply to: