Red Hat Bugzilla – Full Text Bug Listing
|Summary:||yelp - "Could not load section" alerts for obviously existing stuff|
|Product:||[Fedora] Fedora||Reporter:||Michal Jaegermann <michal>|
|Component:||yelp||Assignee:||Ray Strode [halfline] <rstrode>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-05-19 17:30:31 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Michal Jaegermann 2005-02-02 01:57:49 EST
Description of problem: Trying to navigate in yelp by clicking with a mouse on titles in a left-hand window often brings alerts. For example: GNOME 2.8 Desktop User Guide |-> Basic Skills |-> Mouse Skills and you are getting an alert about "The section âgosbasic-2'" while a material in question clearly exists and, in this particular case, is even displayed on a screen. Also links work or do not work depending on their mood. For example "Preferences" section of gnome-terminal manual shows at the very beginning six links and none ot them works; while a bit further down "See Section 3.4" link behaves as expected. OTOH none of subsection titles in "Preferences" section shows up on a left-hand side panel. Running yelp from a terminal window produces a constant stream of warnings and complaints. Like that: ...... (yelp:5120): Yelp-WARNING **: Could not locate section orig for mlockall.2.orig (yelp:5120): Yelp-WARNING **: Could not locate section orig for fs.5.orig Unmatched element: partintro Unmatched element: partintro ...... Note: this was tested on x86_64 machine and I do not know in this moment if i386 installation indeed behaves the same. Version-Release number of selected component (if applicable): yelp-2.9.3-1
Comment 1 Matthias Clasen 2005-04-21 16:51:16 EDT
Can you try again with recent rawhide, and reopen if you still see problems ? The behaviour of yelp on x86_64 was recently improved by a mozilla rebuild
Comment 2 Michal Jaegermann 2005-04-22 16:26:01 EDT
Created attachment 113575 [details] a log from a "simple" yelp session Hm, maybe there is some improvement. I am not sure about that as I am not using that tool too often and my memories may be somewhat vague. But even the most "trivial" session of yelp generates multiple complaints and mouse clicks in a "content" panel end up with "does not exist" alerts for things displayed on a screen - exactly in a manner described in the original report. Attempts to read man pages with a help of yelp invariably result in a very loooong wait. I have seen occasions when after this wait a formatted man page eventually showed up but with other ones you can stare at a blank screen, showing only "Loading..." on a yelp title bar, and after ten minutes nothing changes.
Comment 3 Michal Jaegermann 2005-04-22 16:27:06 EDT
Created attachment 113576 [details] a log from a yelp session where attempts to read man pages were made
Comment 4 Michal Jaegermann 2005-04-22 16:28:37 EDT
I should have been clear. Logs from comment #2 and #3 were done with yelp-2.9.3-5
Comment 5 Michal Jaegermann 2005-04-22 16:46:00 EDT
I tried few more man pages with yelp and some of them seem to show up on a screen in a reasonable time. The one which takes a longer while is 'ImageMagick'. Another one which looks like that it will never show up is 'col'. These are not results of any systematic investigation or checking how manpages are written in detail. I just clicked on few samples in random and these above were the first two I attempted to read. :-) Besides if this is supposed to be a "universal documentation reader" then a support for an 'info' format is missing.
Comment 6 Michal Jaegermann 2005-04-22 17:03:13 EDT
As far as I can see 'yelp-2.9.3-5' behaves exactly like described in all comments above on x86 installation too; so this is not something architecture dependent. Moreover after selecting for the first time on x86 a "Man Pages" link I got an alert about "missing section", or something to that extent. Unfortunately I am unable to reproduce that again but a 'col' manpage does not show up on x86 either.
Comment 7 Ray Strode [halfline] 2005-04-24 14:22:06 EDT
Hi, I'm going to put this on an fc4 tracker bug so that it doesn't get forgotton about.
Comment 8 Ray Strode [halfline] 2005-04-25 14:47:11 EDT
Are you only seeing this behavior with man pages or do you see it with other help documents in yelp, also?
Comment 9 Michal Jaegermann 2005-04-25 15:34:36 EDT
> Are you only seeing this behavior ... Depends what you understand by "this behavior". :-) The original report of spurious alerts is still valid and obviously it is not about man pages. What I added in the last paragraph of comment #2 I observed only with man pages although I did not carry thorough enough investigations to be sure that this will not happen elsewhere. On the first look this makes an impression that yelp is trying to parse man pages by itself, instead of leaving that task to tools which spent years doing it, and spectacularly fails. But this is only a rough guess and it may be totally wrong. On the second thought I should have possibly open a manpages issue as another bug instead of tacking it as an aside in another report. Oh, well ...
Comment 10 Matthias Clasen 2005-04-26 02:54:30 EDT
The case of nonworking man pages is upstream in http://bugzilla.gnome.org/show_bug.cgi?id=163404
Comment 11 Matthias Clasen 2005-04-26 03:02:44 EDT
The problem of nonworking links is upstream in http://bugzilla.gnome.org/show_bug.cgi?id=170074 (this one has a patch)
Comment 12 Matthias Clasen 2005-04-30 23:48:10 EDT
*** Bug 156474 has been marked as a duplicate of this bug. ***
Comment 13 Ray Strode [halfline] 2005-05-19 17:30:31 EDT
This bug should be fixed in tomorrow's rawhide.
Comment 14 Michal Jaegermann 2005-05-20 18:00:41 EDT
Oh, I see. Problems with manpages were "solved" by dropping that support entirely. At least as far as I can find. Pretty effective if somewhat radical. :-) The trouble from the original report indeed looks like not there anymore. OTOH starting yelp-2.10.0-1 in a terminal window brings quickly the folllowing: I/O warning : failed to load external entity "/home/michal/.gnome2/yelp-bookmarks.xbel" (yelp:10611): GLib-CRITICAL **: g_strrstr_len: assertion `haystack != NULL' failed (yelp:10611): GLib-CRITICAL **: g_strrstr_len: assertion `haystack != NULL' failed Unmatched element: partintro Unmatched element: partintro The last two lines seems to a "property" of 'GNOME 2.8 Desktop User Guide'. No idea if that document or yelp is really at fault. A bit of a random mousing around brings other surprises. For example: under "Application->Games" one can find 'Klotski' manual and in it a section which starts with: Playing GNOME Klotski * Section 3.1 - To Start GNOME Klotski * Section 3.2 - The main window * Section 3.3 - Starting a new game * Section 3.4 - Moving blocks These section titles seem to be links but clicking on those does not have any visible effect. Somewhat further in a text, in Section 3.2, one can find the following sentence You can drag the blocks around with the mouse as described in Section 3.4 - Moving blocks. with a tail of that looking again like a link. Clicking on it does change a screen position; but not to Section 3.4, as one could naively expect, but to the top of that page. Once again - no idea what is truly to blame.
Comment 15 Ray Strode [halfline] 2005-05-23 01:39:25 EDT
Hi Michal, Can you file a new bug with the summary "yelp jumps to top when following links to elsewhere on the current page" and the body containing the part of your comment that starts with "A bit of a random mousing around..." This bug is already overloaded with a few separate issues and is already closed, so it would better to start fresh I think. Thanks