Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

Hello, I emerged htdig.

htsearch is a script that emerge installed in /home/httpd/cgi-bin/htsearch

running the script manually it tells me, that there does not exist the
application htsearch.

the help indices are made with the installed /usr/bin/rundig

the default path for the database was set by KDE to /opt/www/htdig/db/
(which does not exist)

Setting this in KDE It does simply nothing when I click onto "make indices". 

In Kdevelop the behaviour ist the same.

This bug has not been touched in 90 days or more.

I've verified this bug on kde-3.1.5, with htdig-3.1.6-r4.

The paths have changed. htsearch is now at /var/www/localhost/cgi-bin/htsearch
and the db is now at /var/htdig/db/

The KDE behaviour (of doing nothing) is the same.

I want to comment that the bug is already in KDE 3.2.

but now running htsearch yields:
/home/httpd/cgi-bin/htsearch
Enter value for words: 2
DB2 problem...: /usr/share/htdig/synonyms.db: No such file or directory
DB2 problem...: /usr/share/htdig/word2root.db: No such file or directory
Content-type: text/html

but the files htsearch obviously wants are present in /var/htdig/db/

It seems to be a path configuration Problem

O.k., that's not a kde bug and the inherited eclass is deprecated, too. Web
folks?

so, is there any solution that gets htdig search in the kde helpcenter to run?
if so, somebody please post it.

Created an attachment (id=35091) [details]
htdig-3.1.6-r5.ebuild

I'm attaching a new version of the ebuild that uses webapp.eclass instead of
webapp.apache. However, this does _not_ solve the KDE documentation issue,
which I don't have time to track down. 

The sample htdig.conf file in the kdevelop ebuild needs to be updated with new
paths. 

I have googled a bit trying to find a solution, and these links might prove
useful:
http://www-linux.gsi.de/linux-doc1/kdevelop/README-htdig.Debian
http://www.kdevelop.org/forum/read.php?f=2&i=7534&t=7415
http://htdig.sourceforge.net/files/contrib/other/htdig-3.1.2-bugfixes.patch

There's quite a bit of potentially interesting stuff on the htdig mailing list
as well. 

rundig -vvv and htmerge -v gives some useful debugging output

KDE folks, could we get your help with this?

Ok, what can we do?

Basically, I can reproduce the bug, and KDE error messages aren't all too
descriptive. I don't have access to a KDE installation, so if you could poke
around a bit and see what is going on, that would be great. Sorry I can't help
more atm. Be sure to use -r6 of htdig.

I've been having this bug now with kde-3.4.

well i figured out that kde tries to index files with the "help://" protocol.
That didn't work with htdig-3.1.6.

I installed htdig-3.2.0b6 from source, and htdig worked in the shell and in the khelpcenter while building the index.

But the search function still doesn't work. The only thing it finds is man pages. Maybe I didn't install htdig right? I tried to make an ebuild too, but it installed a few paths wrong.

htdig itself works, so this must be a KDE issue. I'm at my wits end with this,
so I'm giving up.

I've never had a fully working htdig installation before, so I may be missing 
some functionality when I say that everything works (now or later), please 
doublecheck me. 
 
I installed the htdig-3.2.0_beta6 ebuild in portage (on an ~amd64 system).  
I've also had to change /usr/kde/3.4/bin/kghc_htsearch.pl to read:  
my $htsearchpath="/usr/bin/htsearch"  
Instead of /srv/.... which doesn't exist on Gentoo. 
  
khelpcenter can now build indexes and search. However, the results pages aren't  
rendered correctly: I'm getting something like the html source displayed  
(starting with "Content-type: text/html"), but then it renders links to result  
topics correctly, except that there are four non-loaded images before every  
such link (i.e. there are the khtml 'image not loaded' icons).  
 
To sum up, there's this rendering issue, and there's kdevelop's documentation 
search, which I haven't gotten to work yet. 

(Really no reason this should be a blocker) 

web-apps people:   
   
To summarize one particular issue here: khelpcenter uses htdig for local html  
indexing, and displays the output of htsearch. Because there's no webserver,  
htsearch's 'result ranking' stars aren't displayed, because they have an  
src="/htdig/star.gif".  
  
khelpcenter already uses a custom htdig config file, so we can change that   
(and the template files) as necessary. The problem is that htdig's star.gif  
is installed under e.g. /usr/share/webapps/htdig/3.2.0_beta6/htdocs-secure/, so  
our config file would be broken on the next htdig version upgrade.  
  
Is there a way to handle this at runtime, or should we just keep a copy of  
star.gif and suchlike somewhere under $KDEDIR and reference it from our htdig 
configfile?  

Those files are also under /var/www/YOUR_HOST/htdocs/htdig. Fex, if you have
USE="-vhosts", then check /var/www/localhost/htdocs/htdig

It seems like we're close. Where does khelpcenter keep its htdig config file?

Normally it keeps it in   
~/.kde/share/apps/khelpcenter/index/kde_application_manuals.conf, but we should  
be able to install a systemwide one as   
$KDEDIR/share/apps/khelpcenter/index/kde_application_manuals.conf.  
  
So what should the config file say in order to work with both -vhosts  
and +vhosts systems? 

Ok, I finally got to this. I just committed 3.1.6-r8 and 3.2.0_beta6-r1 that no
longer use webapp.eclass. This should clear up any potential issues with db
location.

search in khelpcenter appears to work fine after changing the paths in
/usr/kde/3.5/bin/khc*.pl . I will attach a patch to bug #120830 .

searching in kdevelop appears to work out of the box. For the record, all
htdig-related files used by kdevelop are in
~/.kde/share/apps/kdevdocumentation/search . The only (very minor) issue is
that in kdevelop the stars aren't rendered as images and show up as text
instead.

As soon as 120830 is ready, I believe we're done here?

120830 is fixed in 3.5.7 and, in fact, it works fine now. The stars (which are
still rendered as text) are hereby declared a feature, not a bug. ;-)

So this is finally fixed. Thanks to all involved!