Description of problem: After installing "KDE Plasma Workspaces", login into KDE, sends you back to login screen with an Xsession error (~/.xsession-errors): --- klauncher: error while loading shared libraries: *libQt5Svg.so.5*: cannot open shared object file: No such file or directory --- It seems that the qt5-qtsvg package is missing from dependencies. After installing it, the login works fine. Version-Release number of selected component (if applicable): How reproducible: I get a fedora 23 distribution (upgraded from fedora 21) Steps to Reproduce: 1. Install KDE Plasma: dnf groupinstall "KDE Plasma Workspaces" 2. Log in with KDE Plasma 3. Actual results: Back to login screen Expected results: Log in. Additional info: https://ask.fedoraproject.org/en/question/78733/fedora-23-installing-kde-plasma-as-a-second-desktop-environment-bug/
Do you happen to have hipchat or viber installed? https://fedoraproject.org/wiki/Common_F22_bugs#Some_third-party_application_rpms_bundle_Qt5_erroneously_.28hipchat.2C_viber.29 Else, can you post the output of: rpm -q --whatprovides 'libQt5Svg.so.5' and rpm -q --whatprovides 'libQt5Svg.so.5()(64bit)'
[root@new-host joomla]# rpm -q --whatprovides 'libQt5Svg.so.5' ningún paquete proporciona libQt5Svg.so.5 [root@new-host joomla]# rpm -q --whatprovides 'libQt5Svg.so.5()(64bit)' rstudio-0.99.447-1.x86_64 qt5-qtsvg-5.5.1-2.fc23.x86_64 [root@new-host joomla]# dnf info hipchat Última comprobación de caducidad de metadatos hecha hace 2 days, 16:23:48, el Fri Dec 11 22:31:20 2015. Error: No hay paquetes que se correspondan con la lista [root@new-host joomla]# dnf info viber Última comprobación de caducidad de metadatos hecha hace 2 days, 16:24:02, el Fri Dec 11 22:31:20 2015. Error: No hay paquetes que se correspondan con la lista
OK, looks like we have yet another broken 3rd-party rpm on our hands: rstudio rstudio *claims* to provide libQt5Svg, but it really only includes a bundled copy usable only by rstudio. Please report the problem to whoever provided that rstudio rpm. *** This bug has been marked as a duplicate of bug 1225749 ***
Posted to RStudio: https://support.rstudio.com/hc/en-us/community/posts/206291208-broken-3rd-party-rpm-on-our-hands-rstudio
Thanks!
Hi there, we include Autoreqprov: no in our RPM specfile to prevent this sort of thing. To be perfectly candid though our RPM is generated by cmake/cpack so it could have additional problems we aren't aware of. Can you see anything obviously wrong with the RPM that would give us a clue as to how to remediate this?
I'm wrong here, we include Autoreqprov: no in our server version however our desktop version doesn't do this. I'll fix this ASAP.
Thanks!!
The issue has now been addressed in our pre-release builds which can be downloaded from here: https://www.rstudio.com/products/rstudio/download/preview/. This will be rolled into our mainline public release within ~30 days.