Bug 1122316
| Summary: | KDE doesn't start qdbus problem | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | EMR_Fedora <erecio> |
| Component: | qt | Assignee: | Rex Dieter <rdieter> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 20 | CC: | dvratil, extras-orphan, itamar, jreznik, kevin, ltinkl, rdieter, rnovacek, smparrish, than |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | qt-4.8.6-10.fc19 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-07-29 02:08:21 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
EMR_Fedora
2014-07-22 23:11:59 UTC
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. |