GNOME Bugzilla – Bug 113151
Yelp does not show the GNOME specific documentation
Last modified: 2004-12-22 21:47:04 UTC
Package: Yelp Severity: critical Version: GNOME2.2.0 2.2.0 os_details: Gnome.Org Synopsis: Yelp does not show the GNOME specific documentation Bugzilla-Product: Yelp Bugzilla-Component: general Description: Description of Problem: My yelp does not show the GNOME specific documentation as it used to. It displays man pages, info pages, but does not displays the GNOME desktop section (although the title "GNOME - Desktop" is still there). Steps to reproduce the problem: Just run Yelp. Actual Results: It says warning: failed to load external entity "" warning: failed to load external entity "" warning: failed to load external entity "" warning: failed to load external entity "" warning: failed to load external entity "" and then is starts showing only the info and man pages. Expected Results: It should display the GNOME Desktop section with all its items. How often does this happen? 99.9% of the time. There are VERY RARE times, though, that it works OK. Then it fails the next second. BTW, IT WORKS IF I'M LOGGED AS ROOT. Additional Information: ------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-05-16 17:33 ------- The original reporter (felipeocoelho@uol.com.br) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org. Reassigning to the default owner of the component, micke@codefactory.se.
Can't ask for more info from the reporter... This was also happening to me when there was a scrollkeeper problem, but I always solved it and wasn't because of yelp. Confirming that gnome 2.2 works fine. Should this be closed?
Reporter: is scrollkeeper-update running ok? (I'm seding mail manually to reporter)
No, it shouldn't be closed. Actually, I found more info about the bug. In fact, Yelp creates five temporary files in /tmp, and permissions on these files are owned by the user who executed Yelp. This means that if you run Yelp as root five times, you create five temporary files that CANNOT be overwritten when you run Yelp as a normal user - that's the nature of the bug. If you log as root and delete (or chmod 777) these files, everything is normal again.
Adding Malcolm, the scrollkeeper expert, to the cc list that we might have benefit of his wisdom.
needinfo -> reopen
OK, this is not good. The problem does indeed lie with scrollkeeper and it's a really serious design flaw (the whole /tmp file debacle). I am *not* going to fix this particular problem for the 0.3.13 scrollkeeper release (due out end of July), but that is just to keep the amount of churn in the new release down to a minimum. Fixing this is first thing on the list for the next release. Initially, the idea is to make the /tmp handling user-specific (scrollkeeper will use /tmp/scrollkeeper-jack/* for user 'jack', etc). That will solve the ownership problems. For GNOME 2.6, I will incorporate a patch from a guy at Wipro to improve scrollkeeper as a library and change Yelp to use scrollkeeper in that way (there are some performance problems that Mikael has pointed out previously to me w.r.t caching for localisations that need working on first). So the short version is that this cannot really be fixed in the very short-term, but it will be fixed in the medium-term (certainly by the time GNOME 2.4 final is out). I will reassign this bug to me, since it's really my problem.
*** Bug 106014 has been marked as a duplicate of this bug. ***
Malcolm, any news on this?
And should this really be moved to the scrollkeeper product?
I'll leave this open for now. There are two open scrollkeeper bugs about it and this is the problem that is holding up the 0.3.13 scrollkeeper release -- I need to make this work. Once 0.3.13 goes out the door, I shall close this so that the GNOME people know it is done.
OK, the scrollkeeper-0.3.14 has a fix for this problem. Everybody should do the upgrade dance.