After installing an update to qt-mobility (1.2.2-0.12.20140317git169da60c.fc20) many KDE apps (dolphin for example) fail to open before restart. After restarting, the graphical login screen loads, password is entered, KDE Plasma begins loading normally, but then jumps back to the login screen. Logging in through the terminal, and trying to startx also fails. Reproducible: Always Steps to Reproduce: 1. Install Fedora 20 KDE Spin 2. Update qt-mobility to 1.2.2-0.12.20140317git169da60c.fc20 3. Try to launch dolphin 4. Restart, then try to login Actual Results: Dolphin fails to open. Upon restarting, graphical interface fails to load. Expected Results: Normal use of apps and GUI. This is my first bug report, so I'm not entirely sure what additional information may be useful. I will try to check back frequently and post any requested information.
Are you sure you only updated Qt mobility? From your description, it sounds like the X server crashes, which is usually caused by broken video drivers.
David, mind posting the contents of your ~/.xsession-errors ? (Ideally in a bug downstream @ bugzilla.redhat.com , since this is most likely not an upstream kde bug )
@Christoph Feck When this first happened I was able to "fix" the problem with a yum history rollback. On the next successful login there were 10 packages to update that had been rolled back. I started installing each update one at a time, testing if apps were working, and rebooting after each one. When I applied the update for qt-mobility that is when apps stopped working and I could no longer successfully login to the GUI on reboot. @Rex Dieter I'll see if I can do some more tests to determine if it is KDE specific. If not, then I'll post to bugzilla.redhat.com.
I have found the problem and a way to solve it. First, let me say that it was not a KDE issue and this bug report can be closed. I thought it may have been since I had only tested KDE apps at the time I first posted this. After installing gnome and having the same issues I did some more digging. After installing the qt-mobility update I tried launching apps from the terminal to see what error messages may come up. The ones that would not launch all gave the same error: Error while loading shared libraries: libproj.so.0 cannot open shared object file: No such file or directory I then enter yum provides libproj.so.0 and found the missing package: proj-4.8.0-5.fc20.x86_64 (since I'm using 64bit Fedora). After installing the package, everything works fine. It does some weird that it was not included as a dependency for the qt-mobility, since it does seem necessary for it to work. Does anyone think this is worth in a bug downstream @ bugzilla.redhat.com?
There is a dependency on the library. I suspect you may have something else installed that claims to provide that library, but really doesn't. Can you provide the output to these on your box? $ rpm -q --requires qt-mobility-location | grep proj $ rpm -q --whatprovides 'libproj.so.0()(64bit)' $ repoquery --whatprovides ''libproj.so.0()(64bit)'
@Rex It appears you are correct. Looks like Google Earth claims to provide the library. [Entropy@david-w-pearson ~]$ rpm -q --requires qt-mobility-location | grep proj libproj.so.0()(64bit) [Entropy@david-w-pearson ~]$ rpm -q --whatprovides 'libproj.so.0()(64bit)' google-earth-7.1.2.2041-1.fc20.x86_64 proj-4.8.0-5.fc20.x86_64 [Entropy@david-w-pearson ~]$ repoquery --whatprovides 'libproj.so.0()(64bit)' proj-0:4.8.0-5.fc20.x86_64
Ah ha, bad, naughty google-earth is to blame here. Mind filing a bug @ bugzilla.redhat.com against qt-mobility then? Id be willing to include some workarounds in the meantime. (Any idea where one can bug/nag about google-earth packaging bugs? They should be made aware of this)
Posted, https://productforums.google.com/forum/#!category-topic/earth/problems-and-errors/linux/goVrpKx5OeU
And followup, qt-mobility update with workaround for google-earth packaging bug, https://admin.fedoraproject.org/updates/qt-mobility-1.2.2-0.14.20140317git169da60c.fc20
Sorry, looks like I was hasty to blame google's google-earth-stable packaging. $ rpm -q google-earth-stable google-earth-stable-7.1.2.2041-0.x86_64 $ rpm -q --provides google-earth-stable google-earth = 7.1.2.2041 google-earth-stable = 7.1.2.2041-0 google-earth-stable(x86-64) = 7.1.2.2041-0 David, where did you get that version of google-earth?
(Sorry for the spam), I think I found it included in postinstaller repo, and reported the issue there, https://sourceforge.net/p/postinstaller/discussion/general/thread/22ddc07f
Yes, it was from the postinstaller repo. I had meant to post about that sooner, but I got caught up in work stuff. Thanks for all the help!
Google Earth updated ;) A simple problem with autoreq and autoprov (Similar to Spotify and Brackets) http://www.rpm.org/max-rpm-snapshot/s1-rpm-depend-auto-depend.html su yum clean metadata yum update