unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Ruud van Asseldonk <dev+guix@veniogames.com>
To: 29654@debbugs.gnu.org
Subject: bug#29654: Manual database index.db embeds timestamps
Date: Sun, 10 Dec 2017 23:47:13 +0100	[thread overview]
Message-ID: <c5553a2e-4a7d-f712-f35a-2279b137fe87@veniogames.com> (raw)

The manual database file index.db embeds mtimes of the files it refers
to, making it not reproducible. This is an issue for building
reproducible profiles (as produced by `guix pack` for example).

The number that are not reproducible can be seen with `accessdb
index.db`, which will output something like

$version$ -> "2.5.0"
acme-client -> "- 1 1 1512941854 498178709 B - - gz secure ACME client"

And when built again on a clean installation:

$version$ -> "2.5.0"
acme-client -> "- 1 1 1512942998 296814690 B - - gz secure ACME client"

I asked the man-db maintainer about this, who replied:

> Those are timestamps, seconds and nanoseconds respectively.  You should
> get reproducible output if you make sure the mtimes of manual pages are
> reproducible.  (man-db needs to keep track of mtimes so that it knows
> when a database is out of date.)  If the manual pages come straight from
> the source package, this should be straightforward; if they're
> generated, you'll need some strategy to ensure that they're generated
> with a reproducible mtime.

Now the strange thing is, when I check the profile directory, both the
man file symlinks, and the files they refer to, have the mtime set to
epoch. I suspected that the mtime would be reset after the manual
database had already been built, but inserting calls to utime after
`(symlink manpage dest-file)` in the `manual-database` procedure, did
not resolve the issue.

The mtime that ends up in index.db does correspond to a recent time, and
for larger databases the timestamps can differ among entries, but so far
I have only seen them differ in the nanoseconds. The seconds timestamp
looks like the timestamp at which the database was generated. So either
the mtime of the input files is not epoch when man-db runs, or man-db is
somehow setting the mtime of every entry to the current time as it adds
them.

I looked at the man-db source and I did not find anything that looked
like it was storing current times as mtimes in the database, although I
did not look very carefully. I suspect that the mtimes of the files to
scan are actually wrong. It should be possible to confirm this by
introducing a delay when creating the man files, and when making the
symlinks, and seeing if the delay shows up in the database.

Help with diagnosing this further, or ideas about what could be going on
and how to resolve it, would be appreciated. I am willing to work on a
fix, but I am not very familiar with Guix yet.

Kind regards,

Ruud van Asseldonk

             reply	other threads:[~2017-12-10 23:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-10 22:47 Ruud van Asseldonk [this message]
2017-12-15 21:30 ` bug#29654: Manual database index.db embeds timestamps Ludovic Courtès
2017-12-15 21:54   ` Ludovic Courtès
2017-12-16  0:35   ` Ricardo Wurmus
2017-12-16 23:51     ` Ludovic Courtès
2017-12-17  0:04       ` Ludovic Courtès
2017-12-17  0:26         ` bug#29654: GDBM output is not deterministic Ludovic Courtès
2017-12-17  9:19           ` Sergey Poznyakoff
2017-12-17 16:27         ` bug#29654: Manual database index.db embeds timestamps Ludovic Courtès
2017-12-17 19:51           ` Ruud van Asseldonk
2017-12-17 21:32             ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c5553a2e-4a7d-f712-f35a-2279b137fe87@veniogames.com \
    --to=dev+guix@veniogames.com \
    --cc=29654@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).