[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


Reply to: