Description of problem: The Oxygen style is a part of the main kdebase-workspace package, which makes it not multilib. As a result, i686 apps cannot use the Oxygen style. Version-Release number of selected component (if applicable): 4.6.2-6.fc15 How reproducible: always Steps to Reproduce: 1. install skype 2. export QT_PLUGIN_PATH=$QT_PLUGIN_PATH:/usr/lib/kde4/plugins/ 3. run skype Actual results: Skype attempts to use Oxygen style and fails, the result looks ugly. Expected results: Skype uses Oxygen style. Additional info: Perhaps the QT_PLUGIN_PATH could be expanded to include /usr/lib/kde4/plugins as well once the packaging is rearranged.
To be clear, as discussed on IRC, the main kdebase-workspace actually is multilib at this time, however it probably shouldn't be and it's full of multilib conflicts.
I'll take a look.
Changelog: * Sun May 15 2011 Rex Dietr <rdieter> 4.6.3-5 - kde4/plugins/styles/oxygen.so is not multilib (#704840)
I'm afraid testing will need to wait until KDE 4.6.3 is in one of the repos; trying to fetch all the packages from koji seems like a neverending dep hell ;).
It'll be in kde-testing from http://kde-redhat.sourceforge.net/ shortly. Will be submitting 4.6.3 to updates-testing official real soon now.
> Changelog: > * Sun May 15 2011 Rex Dietr <rdieter> 4.6.3-5 > - kde4/plugins/styles/oxygen.so is not multilib (#704840) I don't think this is going to fix the whole problem. There's still the bug that kdebase-workspace.i686 (as opposed to -libs) ends up in the x86_64 repo even though it's full of multilib conflicts. Or is that because of the Oxygen style being whitelisted somewhere? I think at least these files: /usr/lib/libkickoff.so /usr/lib/libpowerdevilcore.so /usr/lib/libpowerdevilui.so /usr/lib/libsystemsettingsview.so belong to -libs. There are also some /usr/lib/libkdeinit4_*.so files, I'm not sure what the multilib heuristic does on those. (They should really be blacklisted for multilib.) > Will be submitting 4.6.3 to updates-testing official real soon now. FYI, you can submit 4.6.3 to F15 testing now, I don't think we have any remaining blocker or NTH bugs open against 4.6.2.
I can confirm that kdebase-workspace-4.6.3-5.fc15.x86_64 fixes the problem, but only partially. I still need to run $ export QT_PLUGIN_PATH=$QT_PLUGIN_PATH:/usr/lib/kde4/plugins/ Would it be feasible to add this to plugin path automatically?
We used to patch qt to unconditionally do that, but it caused some bad side-effects. I've an idea for something a little safer. 1. patch qt to append /usr/lib/qt4/plugins if not already present 2. patch kde (kdebase-workspace/startkde) to append /usr/lib/kde4/plugins if not already present
As discussed on irc, 1. makes little/no sense, this is all about QT_PLUGIN_PATH (in startkde) Though, I had hoped to be able to handle the Qt outside of KDE case, but that's more of a corner-case.
%changelog * Sat May 21 2011 Rex Dieter <rdieter> 4.6.3-7 - multilib QT_PLUGIN_PATH (#704840) F15 build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3085590
This indeed helps, thanks.