fails to open valid links

Bug #138770 reported by Matthew East on 2007-09-10
20
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Yelp
Fix Released
Medium
yelp (Ubuntu)
Medium
Ubuntu Desktop Bugs

Bug Description

Binary package hint: yelp

Yelp fails to open a number of valid links, giving an error "The requested URI is invalid".

An example is "ghelp:desktop-effects" (from the yelp front page) - the document /usr/share/gnome/help/desktop-effects/C/desktop-effects.xml is present and correct

Another example is any document called from a terminal with a relative path, e.g.:

yelp /home/matt/example/example.xml - works
yelp example/example.xml - doesn't work

Albert Damen (albrt) wrote :

I can confirm this in Gutsy, yelp version 2.19.90-0ubuntu3

Changed in yelp:
status: New → Confirmed
Pedro Villavicencio (pedro) wrote :

Thanks for your report.

Changed in yelp:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: Confirmed → Triaged
Don Scorgie (don-scorgie) wrote :

2 separate problems.

First, the desktop effects: Is there a desktop-effects omf file? I can't find one on my (gutsy) system. This means Rarian / Yelp doesn't know where to look. (technically, it shouldn't have worked in previous yelps, but for a strange quirk in libgnome)

Second, the relative paths. This is a known upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=396892

On 12/09/2007, Don Scorgie <email address hidden> wrote:
> 2 separate problems.
>
> First, the desktop effects: Is there a desktop-effects omf file? I
> can't find one on my (gutsy) system. This means Rarian / Yelp doesn't
> know where to look. (technically, it shouldn't have worked in previous
> yelps, but for a strange quirk in libgnome)

My understanding was that the ghelp link should point to
/usr/share/gnome/help rather than requiring an omf file. There are
several documents we install which don't have omf files... Is that
seriously not going to be supported anymore?

--
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF

Don Scorgie (don-scorgie) wrote :

> My understanding was that the ghelp link should point to
> /usr/share/gnome/help rather than requiring an omf file. There are
> several documents we install which don't have omf files... Is that
> seriously not going to be supported anymore?

Not having omf files has several drawbacks:
1. The docs won't appear in the TOC (not a concern for Ubuntu)
More importantly: The documents won't be searched (using basic search). This has never worked (and probably never will).

There are several other problems (involving installing new packages and using the default libgnome). These problems (IMO) are severe enough that solving them isn't worth while.

We [1] are trying to move away from using ghelp: URIs in general for various reasons involving it not being a registered protocol, as well as the above. Instead, the use of identifiers will be encouraged (e.g. sending a dbus signal asking for the identifier "org.gnome.epiphany").

There are a couple of options at this point:
a) the omf's can be created.
b) I can cook up a (quick and dirty) yelp patch to check the existance of the file path if the current ghelp method falls through

Each has an advantage and a disadvantage:
a) + The correct solution
     - Requires a (small) bit of work for translators
b) + Quick and easy (for people that aren't me)
     - Docs still won't appear in search results

The work for translators isn't too much as only the title and URI will need translated. The description can be basically anything (as it's never shown), but adding the omf's to the build system may be a bit of work (?)

So, I leave the decision up to you. Any alternatives I haven't thought of are also welcome.

[1] and, obviously by we, I mean I

Matthew East (mdke) wrote :

Hi,

On 13/09/2007, Don Scorgie <email address hidden> wrote:
> There are a couple of options at this point:
> a) the omf's can be created.
> b) I can cook up a (quick and dirty) yelp patch to check the existance of the file path if the current ghelp method falls through

Thanks for such a clear explanation. a) is totally the best option.

I'm interested in this dbus business, perhaps we can sort that out for
the next release, and wash scrollkeeper out of our system.

--
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF

Changed in yelp:
status: Unknown → New
Albert Damen (albrt) wrote :

The desktop-effects link is now working.
An omf file has been installed: /usr/share/omf/desktop-effects/desktop-effects-C.omf provided by ubuntu-docs 7.09.2.
Yelp is still 2.19.90-0ubuntu3

Sebastien Bacher (seb128) wrote :

The bug seems to be fixed, closing, feel free to reopen if you think there is still an issue though

Changed in yelp:
status: Triaged → Fix Released
Matthew East (mdke) wrote :

The second type of link (docs called with relative path), which is the subject of the upstream report, is still broken in current gutsy.

Changed in yelp:
status: Fix Released → Confirmed
Changed in yelp:
status: Confirmed → Triaged
toobuntu (toobuntu) wrote :

still a problem in karmic

$ apt-cache policy yelp
yelp:
  Installed: 2.27.4-0ubuntu1
  Candidate: 2.27.4-0ubuntu1
  Version table:
 *** 2.27.4-0ubuntu1 0
        500 http://us.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

Changed in yelp:
status: New → Fix Released
Matthew East (mdke) wrote :

This is fixed in Lucid.

Changed in yelp (Ubuntu):
status: Triaged → Fix Released
Changed in yelp:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.