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