This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 146862

Summary: yelp - "Could not load section" alerts for obviously existing stuff
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: yelpAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: hobbit, peterennis
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-19 17:30:31 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 136451    
Attachments:
Description Flags
a log from a "simple" yelp session
none
a log from a yelp session where attempts to read man pages were made none

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