Red Hat Bugzilla – Bug 464793
qt4 docs no longer show up in assistant
Last modified: 2008-10-02 19:16:51 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): qt4-doc-4.4.1-2.fc8 qt4-x11-4.4.1-2.fc8 How reproducible: every time Steps to Reproduce: 1. Set environment for qt4: QTDIR=/usr/lib/qt4 QTINC=/usr/lib/qt4/include QTLIB=/usr/lib/qt4/lib PATH=/usr/lib/qt4/bin:... 2. assistant 3. see empty contents panel Actual results: empty contents Expected results: qt4 docs Additional info:
Try qt4's assistant: assistant-qt4
well, the PATH mod above should get qt4's assistant, not sure if the lack of an EXPORT QTDIR ... PATH makes a difference or not. Either way, I cannot reproduce. This looks a lot like bug #454930 , but we fixed that. ??
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.
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.
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).
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 working.
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.
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.)
"Problem is minor loss of function, or other problem where easy workaround is present." => Severity is low.
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 symlinks).
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.
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).
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.