On 13/10/15 18:29, Axel Beckert wrote:
> Dear Bill,
>
> [...]
Hi guys,
I want to hijack this bug report to discuss the how the said tag
works. Note that *three* timestamps are considered here:
1) mtime *inside* .gz file (via RFC 1952, referred as to gz_mtime below)
2) mtime *of* the .gz file (in the filesystem, referred as to fs_mtime below)
3) last changelog timestamp (referred as to changelog below)
The current condition for "package-contains-timestamped-gzip" is:
(gz_mtime != 0) and (fs_mtime - changelog >= 0) (1)
The idea is to catch files that where gzipped during the build
process. I'm not sure why I didn't use:
(gz_mtime != 0) and (gz_mtime - changelog >= 0) (2)
but certainly *now* it won't work very well since
dh-strip-nondeterminism updates any non-zero gz_mtime to changelog
timestamp (side note: I'm not sure that gz_mtime should be overwritten
by d-s-n if gz_mtime < changelog).
There are still two problems with (1) anyway:
1) the source may have a perfectly stable and reproducible gzip
file, but install it during the build without preserving
fs_mtime (as Bill mentioned); this will cause a false positive
2) related and worth noting: I believe that tar's --clamp-mtime
is/will be used to, well, clamp fs_mtimes of files in the
packages; this means that the strict version of (1):
(gz_mtime != 0) and (fs_mtime - changelog > 0) (3)
will not fix the previous issue (it will cause the tag to be
*never* emitted)
It seems that gzip files will have this enforced:
(gz_mtime == 0 or gz_mtime == changelog)
and
(fs_mtime <= changelog)
Basically it looks as if dh-strip-nondeterminism/toolchain strips/will
strip so much that this tag may not be useful anymore.
Let me know what you think.
Cheers,
Tomasz
Attachment:
signature.asc
Description: PGP signature