Hide Forgot
Description of problem: When open subscription manager manual doc from menu "Help->Getting Started" the manual doc not shows up. Version-Release number of selected component (if applicable): RHEL6.6-server64-20140716.0 subscription-manager-gui-1.12.4-1.el6.x86_64 subscription-manager-firstboot-1.12.4-1.el6.x86_64 subscription-manager-1.12.4-1.el6.x86_64 python-rhsm-1.12.4-1.el6.x86_64 How reproducible: always Steps to Reproduce: 1.Open subscription-manager-gui 2.Open online doc with menu "Help->Getting Started" 3. Actual results: Nothing happens and the CLI will get "Error showing url: Operation not supported" Expected results: The manual should open without any error. Additional info:
So this seems to be a regression in glib2 from when it got rebased from 2.26 to 2.28. During the 2.28 development cycle, the way URL handlers were processed was changed. See: https://bugzilla.gnome.org/show_bug.cgi?id=631410 That change means url schemes registered via gconf (via the gvfs module) no longer get consulted. yelp registers the ghelp: uri scheme using gconf. We can "fix" it by making yelp use the new scheme: - updating /usr/share/applications/gnome-yelp.desktop to have x-scheme-handler/ghelp on the MimeTypes line (and running update-desktop-database /usr/share/applications) but there's probably more widespread breakage. Instead, I think the most conservative move would be to revert the change by shipping a reversed patch of https://git.gnome.org/browse/glib/commit/?id=9b262f1c5fe5a6fd879f17cd7b80d8c54e33d80c in the spec file. Bastien, Colin, do you guys agree that's the right course of action?
well a straight up reversal of the patch won't work, since it was partially reverted a few commits after it was introduced: https://git.gnome.org/browse/glib/commit/?id=fb94859e84c0b7859a0a5425d461b18e67ea9ac7 But, assuming Bastien/Colin agree, I think reverting the part that hasn't yet been reverted makes sense.
It's the right course of action if you want to keep the exact same API between RHEL6 releases. Reverting https://git.gnome.org/browse/glib/commit/?id=fb94859e84c0b7859a0a5425d461b18e67ea9ac7 won't be enough though. You'll need to make sure that the glib code to read the scheme handler from mime-types is also removed so that the extension point is always used.
Colin said he's on board with this plan, too, so clearing needinfos.
It's messier than that though - the higher up we rebase, the more we need to do *both* - if say Evolution is installing desktop file mime types, we need to support that too.
ugh, so i guess the answer for that is if g_desktop_app_info_lookup_get_default_for_uri_scheme() returns NULL then fall back to the new way. Thankfully the new way is only 5 lines of code.
*** Bug 1126901 has been marked as a duplicate of this bug. ***
*** Bug 1115903 has been marked as a duplicate of this bug. ***
I don't know this area of the code very well; Bastien, would you have time to look at this?
*** Bug 1142427 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1538.html