Description of problem: kdevelop setup loops forever indexing documentation. Version-Release number of selected component (if applicable): kdevelop-2.1.5-12.1 & htdig-3.1.6-3. How reproducible: Always. Steps to Reproduce: 1. Run kdevelop setup 2. Click the button to index the documentation. 3. Actual results: System loops forever (well, *days* at least). Expected results: Should just index the documentation. Additional info: Close inspection of the htdig.conf file ~/.kde/share/apps/kdevelop/tools/htdig.conf and consideration of the version of htdig included with RHEL 3.0 there is no hope of the bundled htdig.conf file working. Furthermore there exists the possibility that trying to index the documentation may actually destroy the system (because /proc is indexed for example) making the process *dangerous* to put it mildly. Therefore I am tempted to up the priority of this bug because is can break stuff. On the other hand, this bug has been around for YEARS ( being ignored by RedHat? ). WORKAROUND (not the same as with RH8 or RH9) ============================================ In the ~/.kde/share/apps/kdevelop/tools/htdig.conf file locate the line: start_url: file://usr/share/htdig/index.html Replace with: start_url: http://localhost/usr/lib/qt-3.1/doc/html \ http://localhost/usr/share/doc/kdelibs-devel-3 Next locate the line: #limit_urls_to: file:// and replace with: limit_urls_to: ${start_url} Next locate the line: local_urls: file://= and replace with: local_urls: http://localhost/=/ Also, you must select not to index the KDE libs, and manually add the path because the package is looking for it in the wrong place. The location should be: /usr/share/doc/kdelibs-devel-3/ Both these bugs have existed at least as far back as RedHat 8.0, but because the version of htdig is older than the one with say RedHat 9.0, the fix is differnt. Basic issue is htdig-3.1.6-3 doesn't understand "file://" type URLs whereas htdig-3.2.0 at least does. It would REALLY be a good idea if RedHat could bundle a "ready-to-work" htdig.conf file, at least with the Enterprise offering, because this sort of stuff should just work right out of the box. The fact that the file is so dangerous as it stands makes the issue even more urgent.
*** This bug has been marked as a duplicate of 111204 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.