Your message dated Fri, 04 Feb 2022 15:50:21 +0000
with message-id <[email protected]>
and subject line Bug#1004355: fixed in man-db 2.10.0-1
has caused the Debian Bug report #1004355,
regarding man-db modifies cache file contents but resets mtime timestamp
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1004355: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004355
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: man-db
Version: 2.8.5-2
(This report was written before you drew my attention to
https://bugs.launchpad.net/ubuntu/+source/man-db/+bug/1411633
which is a report of the same issue. I'm filing it anyway so we have
record of it in the Debian BTS and so that I have a record myself
of where and what this is bug. Thanks for tolerating this.)
My backup system, like many, relies on file mtimes to know when to
back files up. *Un*like most other systems, it does a cross-check: it
checks that the file *contents* (via checksum) are the same on the
backed-up host and as is recorded in the backup.
This seems to me to be a correct and cautious approach. On at least
one occasion it has saved me from a serious problem by giving me early
warning of a storage failure, by flagging up corruption in
luckily-unimportant files.
But it means that if a file is modified, but the mtime is reset, the
backups fail.
Empirically, this seems to happen with /var/cache/man/*/index.db.
Please could man-db not do this. Specifically, if it modifies the
file, I would like it to either not reset the time timestamp, or at
least not set the timestamp to the same value it had before.
Alternatively, possibly using a deterministic algorithm would work?
(I think https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760895
may be relevant.)
Thanks,
Ian.
--
Ian Jackson <[email protected]> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
--- End Message ---
--- Begin Message ---
Source: man-db
Source-Version: 2.10.0-1
Done: Colin Watson <[email protected]>
We believe that the bug you reported is fixed in the latest version of
man-db, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Colin Watson <[email protected]> (supplier of updated man-db package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Format: 1.8
Date: Fri, 04 Feb 2022 15:30:35 +0000
Source: man-db
Architecture: source
Version: 2.10.0-1
Distribution: unstable
Urgency: medium
Maintainer: Colin Watson <[email protected]>
Changed-By: Colin Watson <[email protected]>
Closes: 630799 691643 941622 970482 974174 998426 1003089 1004248 1004355
Changes:
man-db (2.10.0-1) unstable; urgency=medium
.
* Simplify some debhelper overrides slightly.
* debian/upstream/metadata: Update for upstream move to GitLab.
* Add section 0 to default search list (closes: #1004248).
* New upstream snapshot:
- Document MAN_DISABLE_SECCOMP and PIPELINE_DEBUG environment variables
in man(1) (closes: #941622).
- Add man-pages(7) reference to man(1) (closes: #974174).
- lexgrog now produces output in the user's locale (closes: #970482).
- Downgrade "malformed .lf request" warning to a debug message and
rephrase it somewhat, since .lf requests can use *roff arithmetic
expressions and we can't reasonably parse those (closes: #998426).
- Significantly improve mandb(8) and "man -K" performance in the common
case where pages are of moderate size and compressed using zlib
(closes: #630799, #1003089; LP: #1858777).
- Avoid modifying the database without changing its mtime, which had
been possible since 2.7.0 if mandb's purge phase found work to do but
the main phase didn't, and which confused some backup systems into
reporting possible filesystem corruption (closes: #1004355,
LP: #1411633).
- mandb now stores the mtime of link targets as the mtime of their
corresponding database entries, rather than sometimes storing the
mtime of the link instead (closes: #691643).
Checksums-Sha1:
bafe3f80fc81f241084601d2fa86237f1b17bfa0 2418 man-db_2.10.0-1.dsc
ee3bf8ae326f3e193722ba11a608097dd694bd1f 1888196 man-db_2.10.0.orig.tar.xz
717137ce1e2319daaab8812b3dc89cb7254055b3 833 man-db_2.10.0.orig.tar.xz.asc
e564cd5c5ca3451a143f328ee9c117cd2bed6abc 72972 man-db_2.10.0-1.debian.tar.xz
Checksums-Sha256:
23152ae5925ebb3bbeb17b8e5776a6c45c312d3ca215d11601858d59648e5e84 2418
man-db_2.10.0-1.dsc
0a8629022f7117dc7fc6473c6fdb14913b24b106059bb056abee87dbd6070c79 1888196
man-db_2.10.0.orig.tar.xz
01bdd84c2b3f106a31ad9d2c8926ba0ece57241eae0dc6b0cead640eb611543e 833
man-db_2.10.0.orig.tar.xz.asc
bec718ecc64bb05fa8d2f63f153768919b012cf1614da8734afa07ec164eb63b 72972
man-db_2.10.0-1.debian.tar.xz
Files:
b96773d05e3a92a32d6d17341afbfccf 2418 doc important man-db_2.10.0-1.dsc
96009cd422f2e62b01b8c4de0f5691f1 1888196 doc important
man-db_2.10.0.orig.tar.xz
d5c04220af019a6adef3f49c82964d4b 833 doc important
man-db_2.10.0.orig.tar.xz.asc
655c82e59f78ce0d50f3ea781fe871e7 72972 doc important
man-db_2.10.0-1.debian.tar.xz
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAmH9Rt4ACgkQOTWH2X2G
UAvmKhAAq0gntVMIt7i8RbrUqlJBtpwAvA7TqkQ44464isyoG2TM+yP8yPDlwp/7
oTBbZtmTzE6jK/7SDKHV+P/3Djh6mDSM9cKS62HU1MVKEPmybpqYFcfWFO79T68S
1pCNHHkff4lVMAFM370BmmZlhpLCMZFidbXsqzJQuB3NxutySmtI/MY/wy1wCSUq
0PB0v4YRPA5CKeWjo5LTCbGE9DvlUNVvvSA+HX0p3a1Go2aTfO/7cki4mtpn+P6V
e2VmEt9djAjfzEI9K2fMcyiJE6RhzpA+g2ZX4plo7Mm6kmx+XFTC2EV0yMDdVILe
ctncWpGFd6oROjAz3X0DH23a22l6UWdHQIsIuqq3bD5tZXKcXrcSPJzSdyO0YeBw
+AecHbsMYLtmG9N3KrF+H77EGTSQr1xdqkOimNkx5VdMq/LkDVxjQboRP/T1309Z
amYynIEQ+UwWYoGJSQ031RyfyysgLibPvvH0y/bg019zxux5WQNTqRsFLy092MZN
d6qdjJFVIb2RkwwYGGnNKXLXrBRVeKSl/Zv/KIrsxDLsSUnwV7Tmb/2z4Tz3ODCH
4cAIpdWz/9dSO8OhSvVMNHKGrGtNzL6+LFQ720P+qpZLaEchEdcEFZgvvt2+/zYw
KVCUn8QBkp/p3L3dFMmuvVTTANIQlDPkEqZd/VzPga2x/pTwyo0=
=v64e
-----END PGP SIGNATURE-----
--- End Message ---
