Bug 464793 - qt4 docs no longer show up in assistant
qt4 docs no longer show up in assistant
Product: Fedora
Classification: Fedora
Component: qt4 (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-09-30 11:01 EDT by Tom Horsley
Modified: 2008-10-02 19:16 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-01 06:13:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tom Horsley 2008-09-30 11:01:27 EDT
Description of problem:

Sometime in one of the recent qt4 updates, assistant lost track of the
qt4 documentation. It no longer shows up in contents. The only doc I can
see in assistant is the assistant doc itself.

Version-Release number of selected component (if applicable):

How reproducible:
every time

Steps to Reproduce:
1. Set environment for qt4:
2. assistant
3. see empty contents panel
Actual results:
empty contents

Expected results:
qt4 docs

Additional info:
Comment 1 Rex Dieter 2008-09-30 11:08:11 EDT
Try qt4's assistant: 

Comment 2 Rex Dieter 2008-09-30 11:12:26 EDT
well, the PATH mod above should get qt4's assistant, not sure if the lack of an
makes a difference or not.

Either way, I cannot reproduce.

This looks a lot like bug #454930 , but we fixed that. ??
Comment 3 Kevin Kofler 2008-09-30 11:15:42 EDT
WORKSFORME with the exact same version of qt4 (4.4.1-2.fc8) as the submitter.

I also tried the exact instructions given (but with "export", otherwise the environment variables don't actually get set!), they also work, but note that just running assistant-qt4 is the way it's intended to be invoked. The path hackery works (and it will invoke Qt 4's assistant because /usr/lib/qt4/bin is being prepended to the path), but it isn't really supported.
Comment 4 Tom Horsley 2008-09-30 11:57:31 EDT
When in doubt, reinstall :-). I've just removed all qt4 packages and
I'm downloading and reinstalling fresh copies. If that doesn't work, I
guess I'll have to do some strace runs to see where it is looking
for doc files.
Comment 5 Tom Horsley 2008-09-30 12:23:39 EDT
Reinstall didn't work, and I can't really explain what I'm seeing in strace.
This appears to be the relevant bit:

stat64("/home/tweety/.local/share/data/Trolltech/Assistant/../../../../../../../usr/share/doc/qt4/qch/assistant.qch", 0x937475c) = -1 ENOENT (No such file or directory)
lstat64("/home/tweety/.local/share/data/Trolltech/Assistant/../../../../../../../usr/share/doc/qt4/qch/assistant.qch", 0xbfd52c20) = -1 ENOENT (No such file or directory)
stat64("/home/tweety/.local/share/data/Trolltech/Assistant/../../../../../../../usr/share/doc/qt4/qch/designer.qch", 0x937475c) = -1 ENOENT (No such file or directory)
lstat64("/home/tweety/.local/share/data/Trolltech/Assistant/../../../../../../../usr/share/doc/qt4/qch/designer.qch", 0xbfd52c20) = -1 ENOENT (No such file or directory)
stat64("/home/tweety/.local/share/data/Trolltech/Assistant/../../../../../../../usr/share/doc/qt4/qch/linguist.qch", 0x93747cc) = -1 ENOENT (No such file or directory)
lstat64("/home/tweety/.local/share/data/Trolltech/Assistant/../../../../../../../usr/share/doc/qt4/qch/linguist.qch", 0xbfd52c20) = -1 ENOENT (No such file or directory)
stat64("/home/tweety/.local/share/data/Trolltech/Assistant/../../../../../../../usr/share/doc/qt4/qch/qmake.qch", 0x9374fe4) = -1 ENOENT (No such file or directory)
lstat64("/home/tweety/.local/share/data/Trolltech/Assistant/../../../../../../../usr/share/doc/qt4/qch/qmake.qch", 0xbfd52c20) = -1 ENOENT (No such file or directory)
stat64("/home/tweety/.local/share/data/Trolltech/Assistant/../../../../../../../usr/share/doc/qt4/qch/qt.qch", 0x937562c) = -1 ENOENT (No such file or directory)
lstat64("/home/tweety/.local/share/data/Trolltech/Assistant/../../../../../../../usr/share/doc/qt4/qch/qt.qch", 0xbfd52c20) = -1 ENOENT (No such file or directory)

There really is a perfectly valid /home/tweety/.local/share/data/Trolltech/Assistant directory,
and there really is a bunch of perfectly valid
/usr/share/doc/qt4/qch/*.qch files.

And if I count up the ../, as near as I can tell, these should be
valid path names, but they all get ENOENT.

Anyone have any ideas? (It isn't just assistant that can't access the
names spelled that way, I can't ls -l them either).
Comment 6 Tom Horsley 2008-09-30 12:31:05 EDT
Wait! I figured it out. The /home on my system is really a symlink
to /caliban/home. The ridiculous relative paths are really attempting
to reference /caliban/usr/share/doc/qt4/qch/qt.qch which really
doesn't exist.

If I install another symlink /caliban/usr -> /usr it all starts
Comment 7 Kevin Kofler 2008-09-30 13:13:51 EDT
Hmmm, so the problem here is Qt abusing relative paths? If they create the relative path ignoring symlinks, they also have to canonicalize it ignoring symlinks, not rely on the OS canonicalization which does not ignore symlinks.
Comment 8 Kevin Kofler 2008-09-30 13:26:10 EDT
I think it's best if you report this to the upstream Trolltech (or "Qt Software, a division of Nokia" as they call themselves now ;-) ) task tracker. It doesn't seem to be Fedora-specific. (And IMHO it is a bug, your workaround shouldn't be needed.)
Comment 9 Kevin Kofler 2008-09-30 13:27:10 EDT
"Problem is minor loss of function, or other problem where easy workaround is present." => Severity is low.
Comment 10 Tom Horsley 2008-09-30 14:09:26 EDT
OK, I've reported this to trolltech, and I've got my extra symlink now,
so I can finally see the docs anyway. We'll see if they call it a bug
(I've noticed they have real problems with symlinks in lots of their
products - qmake can get horribly confused by source files that are
Comment 11 Tom Horsley 2008-10-01 05:43:50 EDT
The Qt tracker number for this is 229374 which can be looked up
at: http://trolltech.com/developer/task-tracker.

By the way, I've noticed that search doesn't work either. No doubt
there are some other symlink fixes I need to get it going, but
I haven't figured out what yet.
Comment 12 Tom Horsley 2008-10-02 16:52:18 EDT
Just to put the final nail in this, I got this back from trolltech:

This is a known issue and has been fixed in 4.4.2. Before you test it
with 4.4.2 or above, you need to make sure that you clean
$HOME/.local/share/data/Trolltech/Assistant/ first, since the
collection file already saved the wrong path.

(Cleaning out that path also fixed my search problems).
Comment 13 Kevin Kofler 2008-10-02 19:16:51 EDT
OK, good to know, so it has already been taken care of. I'm going to build 4.4.3 for F8 now, it was already built for F9.

Note You need to log in before you can comment on or make changes to this bug.