Description of problem: After latest release of 32-bit version of qt/qtchooser, qt4.conf is missing from /etc/xdg/qtchooser/qt4.conf. qt4.conf should be a symlink to qt4-32.conf. This causes an error message when starting KDE as something like "could not start dbus. can you qdbus?" Version-Release number of selected component (if applicable): [exr003@pcsdw29 qtchooser]$ rpm -qf qt4.conf file /etc/xdg/qtchooser/qt4.conf is not owned by any package [exr003@pcsdw29 qtchooser]$ rpm -qf qt4-32.conf qt-4.8.6-9.fc20.i686 How reproducible: Install latest package via yum Actual results: xaw dialog comes up saying "could not connect to dbus. can you qdbus?" Then you get dropped back out to the login screen. Expected results: Login to KDE Additional info: on a 64-bit system: 4.8.6-9 the qt4.conf symlink is properly owned by the qt package in question above.
workaround: make a symlink from qt4.conf to qt4-32.conf
* moving it to a more appropriate sub component, since thinking about it, it's probably a qt packaging issue than a dbus issue.
Triaging to qtchooser
actually qt owns these. Indeed looks like the 32bit case is not handled properly
We do not recommend using qtchooser to begin with, it only causes problems such as this and has little to no practical benefits. (If it weren't for Rex Dieter's insistence, we wouldn't be shipping qtchooser at all. Everyone else in the team is against it, including me.)
(Our packages are set up in such a way that qtchooser is neither necessary nor useful.) As for this bug, I guess fixing it requires using alternatives or a similar hack for qt4.conf. (Wasn't qtchooser supposed to be a better alternative to alternatives? Now it turns out that it needs alternatives to work properly. That thing just sucks and does not bring us anything.)
2 approaches I see (which aren't necessarily mutually exclusive): * as Kevin suggested, use alternatives to provide /etc/xdg/qtchooser/default.conf * intelligently set QT_SELECT env var in /etc/profile.d/qtchooser.sh somehow, ** possibly parse the output of `/usr/bin/qmake-qt4 -query QT_INSTALL_PREFIX`. I'm not sure if %__isa_bits == 64 implies %_lib == lib64 is a safe assumption, but: /usr/lib/qt4 => qt4-32 /usr/lib64/qt4 => qt4-64 (or come up with some other better idea).
The more I think about it, alternatives seems the better approach, esp since we ought to provide more than just default.conf (qt4.conf and qt5.conf too in multilib situations). I'll get to work implementing that.
qt5-qtbase-5.3.1-5.fc20,qt-4.8.6-10.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/qt5-qtbase-5.3.1-5.fc20,qt-4.8.6-10.fc20
qt-4.8.6-10.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/qt-4.8.6-10.fc19
Package qt5-qtbase-5.3.1-5.fc20, qt-4.8.6-10.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing qt5-qtbase-5.3.1-5.fc20 qt-4.8.6-10.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-8906/qt5-qtbase-5.3.1-5.fc20,qt-4.8.6-10.fc20 then log in and leave karma (feedback).
qt5-qtbase-5.3.1-5.fc20, qt-4.8.6-10.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
qt-4.8.6-10.fc19, qt5-qtbase-5.3.1-5.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.