Your message dated Mon, 15 Sep 2008 05:02:55 +1000
with message-id <[EMAIL PROTECTED]>
and subject line Re: doc-base's trigger seems to sometimes cause dhelp to
reindex the entire cache
has caused the Debian Bug report #497139,
regarding doc-base's trigger seems to sometimes reindex the entire cache
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.)
--
497139: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497139
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: doc-base
Version: 0.8.16
Severity: important
Hi
I'm not sure why, but sometimes doc-base seems to cause dhelp to reindex the
entire cache.
This means a simple daily upgrade sometimes takes 2+ hours on my Pentium 4
desktop. (I'm not
sure which package is to blame, this could easily be a bug in dhelp or a
debhelper script).
Reading package fields... Done
Reading package status... Done
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
(Reading database ... 516305 files and directories currently installed.)
Preparing to replace libselinux1-dev 2.0.65-2 (using
.../libselinux1-dev_2.0.65-4_i386.deb) ...
Unpacking replacement libselinux1-dev ...
Preparing to replace libselinux1 2.0.65-2 (using
.../libselinux1_2.0.65-4_i386.deb) ...
Unpacking replacement libselinux1 ...
Processing triggers for man-db ...
Setting up libselinux1 (2.0.65-4) ...
(Reading database ... 516305 files and directories currently installed.)
Preparing to replace nano 2.0.7-3 (using .../archives/nano_2.0.7-4_i386.deb) ...
Unpacking replacement nano ...
Preparing to replace debtags 1.7.6 (using .../debtags_1.7.7_i386.deb) ...
Unpacking replacement debtags ...
Preparing to replace yelp 2.22.1-3 (using .../yelp_2.22.1-6_i386.deb) ...
Unpacking replacement yelp ...
Preparing to replace reprepro 3.5.2-2 (using .../reprepro_3.5.2-3_i386.deb) ...
Unpacking replacement reprepro ...
Processing triggers for doc-base ...
Processing 679 changed doc-base file(s)...
Registering documents with dwww...
Registering documents with dhelp...
Experience says this will take 2+ hours for dhelp + swish++ to finish indexing
679 documents.
If I ^C interrupt it I get
^CDhelp::IndexerError: Couldn't index
/usr/share/doc/HOWTO/en-html/Caudium-HOWTO/index.html using /usr/bin/index++
--config-file /usr/share/dhelp/swish++.conf --index-file
/var/lib/dhelp/documents.index --incremental -
(/usr/lib/ruby/1.8/dhelp.rb:466:in `index'
/usr/lib/ruby/1.8/dhelp.rb:410:in `_register_docs'
/usr/lib/ruby/1.8/dhelp.rb:334:in `register'
/usr/sbin/dhelp_parse:113:in `main'
/usr/sbin/dhelp_parse:110:in `each'
/usr/sbin/dhelp_parse:110:in `main'
/usr/lib/ruby/1.8/commandline/application.rb:250:in `run'
/usr/lib/ruby/1.8/commandline/application.rb:269:in `__set_auto_run'
/usr/sbin/dhelp_parse:91)
Registering documents with scrollkeeper...
Processing triggers for man-db ...
Processing triggers for menu ...
Note that /usr/share/doc/HOWTO/en-html/Caudium-HOWTO/index.html is in
doc-linux-html, which
isn't part of today's upgrade, and was last upgraded on 2008-07-31.
Thanks for your work in Debian.
Andrew V.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages doc-base depends on:
ii dpkg 1.14.20 Debian package management system
ii libmldbm-perl 2.01-2 Store multidimensional hash struct
ii libuuid-perl 0.02-3+b1 Perl extension for using UUID inte
ii perl 5.10.0-13 Larry Wall's Practical Extraction
doc-base recommends no packages.
Versions of packages doc-base suggests:
ii dhelp 0.6.12 online help system
ii doc-centra 1.8.2+nmu1 web-based documentation browser
ii dwww 1.10.15 Read all on-line documentation wit
ii khelpcente 4:4.0.0.really.3.5.9.dfsg.1-5 help center for KDE
ii scrollkeep 0.3.14-16 A free electronic cataloging syste
ii yelp 2.22.1-3 Help browser for GNOME 2
-- no debconf information
--- End Message ---
--- Begin Message ---
On Sun, 14 Sep 2008, Esteban Manchado Velázquez wrote:
> On Sun, Sep 14, 2008 at 04:34:50AM +1000, Andrew Vaughan wrote:
> > [cc-ed to dhelp's maintainers in case they have any suggestions as to
> > how to debug this/what might be causing this].
>
> I don't really know the doc-base source code, but I was having a
> quick look now, and this seems like it can help debugging (run after
> something like that has happened; probably running it now it could help):
>
> sudo install-docs --dump-db files.db | perl most_recent.pl
> # Show 100 most recently changed documents
> sudo install-docs --dump-db files.db | perl most_recent.pl 100
>
Thanks. That shows that doc-base thinks that all of the files were modified
at roughly 1221144558 (== Fri 12 Sep 2008 00:49:19 EST).
Using this timestamp, I've managed to track this down.
It turns out that the real problem is a bad interaction between doc-base and
the backup software dar. Dar defaults to preserving atime when it reads a
file, but that changes ctime, causing doc-base to think every file has
changed whenever I do a full backup. (This behaviour is documented, and
dar does provide an option to preserve ctime, so no point reassigning).
> In any case, please keep me in the loop. I've had similar problems
> with dhelp before, and I'm starting to think that I should just *not*
> reindex documentation (just register the documents) when doc-base calls
> dhelp with more than, say, 20 files. The rationale: I still want people
> to be able to search for documentation for things that they just
> installed (instead of having to wait a whole week), but then if someone
> installs more than 20 packages, it's probably some upgrade or something
> that she doesn't really want documentation for (in the next couple of
> days anyway).
I'm not sure that will work. apt-get/aptitude is likely to split a large
upgrade into multiple dpkg runs, many of which could have < 20 doc-base
files.
I think it would be better to find a faster way of building the index.
Roughly 150 mins for 677 files seems too slow. (I do a full backup, with
compression, across a 100Mb network, 16+GB in, 8+GB out, in about 100 mins.
Thanks for your help
Andrew V.
--- End Message ---
