[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#29654: closed (Manual database index.db embeds tim

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#29654: closed (Manual database index.db embeds timestamps)
Date: Sun, 17 Dec 2017 21:33:01 +0000

Your message dated Sun, 17 Dec 2017 22:32:27 +0100
with message-id <address@hidden>
and subject line Re: bug#29654: Manual database index.db embeds timestamps
has caused the debbugs.gnu.org bug report #29654,
regarding Manual database index.db embeds timestamps
to be marked as done.

(If you believe you have received this mail in error, please contact

29654: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29654
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Manual database index.db embeds timestamps Date: Sun, 10 Dec 2017 23:47:13 +0100 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
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

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

--- End Message ---
--- Begin Message --- Subject: Re: bug#29654: Manual database index.db embeds timestamps Date: Sun, 17 Dec 2017 22:32:27 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
Ruud van Asseldonk <address@hidden> skribis:

> Unfortunately, I am unable to pull that commit. Guix pull output:
> Updating from Git repository at
> 'https://git.savannah.gnu.org/git/guix.git'...
> Building from Git commit b8396f96bfeadfa63e7ad2afc2ab5a37f37f5f81...
> The following derivation will be built:
>    /gnu/store/m8wcw35f4d33rzf54zzcrg0g80m0zi4r-guix-latest.drv
> copying and compiling to
> '/gnu/store/2g14x91l9wh4wv8zsvnkfblrrdfcysg4-guix-latest' with Guile
> 2.2.2...
> loading...     17.1% of 659 filesBacktrace:
>           12 (primitive-load "/gnu/store/9pgqmhjclkayr5bdhqfk69sbn84?")
> In ./guix/build/pull.scm:
>     127:8 11 (build-guix _ _ #:system _ #:storedir _ #:localstatedir ?)
> In ./guix/build/compile.scm:
>     158:6 10 (compile-files _ _ ("/gnu/store/2g14x91l9wh4wv8zsvn?" ?) ?)
>    107:11  9 (load-files "/gnu/store/2g14x91l9wh4wv8zsvnkfblrrdfcys?" ?)
> In ice-9/boot-9.scm:
>   2792:17  8 (resolve-interface (guix man-db) #:select _ #:hide _ # _ ?)
>   2718:10  7 (_ (guix man-db) _ _ #:ensure _)
>   2986:16  6 (try-module-autoload _ _)
>    2316:4  5 (save-module-excursion #<procedure 44847e0 at ice-9/boo?>)
>   3006:22  4 (_)
> In unknown file:
>            3 (primitive-load-path "guix/man-db" #<procedure 40e90a0 ?>)
> In ice-9/eval.scm:
>    196:43  2 (_ #f)
> In ice-9/boot-9.scm:
>    2795:6  1 (resolve-interface _ #:select _ #:hide _ #:prefix _ # _ ?)
> In unknown file:
>            0 (scm-error misc-error #f "~A ~S" ("no code for modu?" ?) ?)
> ERROR: In procedure scm-error:
> ERROR: no code for module (gdbm)

My bad, fixed in 16613d230b3d9a9cf307c5c5d3899eb0a0c93b0e, which makes
GDBM is “soft dependency” (we only need it when building the manual
database, not when building Guix itself, after all.)



--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]