Am 20.11.2015 um 14:13 schrieb Wolfgang Bauer: [about krandrstartup]
Some time ago, the file moved from krandr to kscreen, IIRC. kscreen is installed, the file is not present. And "startx" still needs it.
Nothing "moved". With KDE 4.11 (in openSUSE 13.1 already) kscreen replaced krandr for screen management. And KDE4's startkde (not startx) calls krandrstartup to apply the screen settings on startup, so kscreen contained a dummy script (it uses a daemon for applying the settings).
But as I wrote, that is no longer true for Plasma5. krandr is dead, and krandrstartup is no longer called by startkde.
Maybe. I can't login via GUI, though the GUI logon window starts up. It throws me back to the login window (after displaying the console for a fraction of a second) instead of starting my KDE session. So I switch to tty6 via Ctrl-Alt-F6, log in here, and start my GUI via "startx", not with "startkde". And startx does not start anything graphical, but breaks down telling me that /usr/bin/krandrstartup is missing. # rpm -qa '*kscreen*' | sort kscreen5-5.4.2-2.1.x86_64 libkscreen-1.0.5-2.1.x86_64 libkscreen1-1.0.5-2.1.x86_64 libkscreen2-plugin-5.4.2-1.1.x86_64
Would explain why you only see this problem just now, after upgrading... ;-) Not for me, if the relations between packages ("obsoletes", "requires" a.s.o.) are correct :)
Well, the question is when you installed updates the last time... ;-) If your system is outdated, the package dependencies would still be ok.
I started the thread on November 19, so that was the day I did the last updates.
Again, if you regularly updated your system, you should have Plasma5 instead of the KDE4 desktop since May, and that one doesn't have nor need krandrstartup. But if you didn't install updates, you shouldn't have had a problem with a missing krandrstartup either.
I did install all available updates, and I do have a problem with (ahem, without ;)) /usr/bin/krandrstartup.
There was a change in the KDE4 dependencies in the Leap development cycle to not require kscreen any more: https://build.opensuse.org/package/rdiff/KDE:Distro:Factory/kdebase4-workspace?linkrev=base&rev=1150
And kscreen (the KDE4 version) has been removed completely because it didn't build any more (or something like that, I don't know). And it's the KDE4 kscreen package (version 1.0.71) that contains krandrstartup which you need to start the KDE4 desktop, so you might have to install krandr manually now or create a dummy krandrstartup script yourself if you want to use KDE4. We probably could add one to the libkscreen package, but the actual configuration module would still be missing.
I installed krandr. Felix Miata proposed that in <56332B7A.2060802@earthlink.net> on October, 30. # rpm -f $(which startx) xinit-1.3.4-6.2.x86_64 # rpm -qf $(which startkde) plasma5-workspace-5.4.2-2.1.x86_64 startkde, started on tty6, gives me $DISPLAY is not set or cannot connect to the X server. The settings: # grep ^[^#] /etc/sysconfig/displaymanager DISPLAYMANAGER="kdm" DISPLAYMANAGER_REMOTE_ACCESS="no" DISPLAYMANAGER_ROOT_LOGIN_REMOTE="no" DISPLAYMANAGER_STARTS_XSERVER="yes" DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="no" DISPLAYMANAGER_AUTOLOGIN="" DISPLAYMANAGER_PASSWORD_LESS_LOGIN="no" DISPLAYMANAGER_AD_INTEGRATION="no" DISPLAYMANAGER_SHUTDOWN="auto" DISPLAYMANAGER_XSERVER="Xorg" KDM_USERS="" KDM_GREETSTRING="" DISPLAYMANAGER_KDM_LOCALARGS="" DISPLAYMANAGER_KDM_THEME="openSUSE" DISPLAYMANAGER_ROOT_LOGIN_LOCAL="yes"
The problem you described can only happen if you locked kdebase4-workspace and actively blocked the installation of Plasma5.
Obviously, it can occur under other circumstances too.
But that's not supported, you are on your own in that case, and it might stop working completely any time as you noticed.
# grep 'solvable_name:' /etc/zypp/locks solvable_name: gtk3-immodule-vietnamese solvable_name: gtk2-immodule-thai solvable_name: gtk2-immodule-vietnamese solvable_name: gtk3-immodule-amharic solvable_name: gtk3-immodule-inuktitut solvable_name: gtk3-immodule-thai solvable_name: gtk2-immodule-amharic solvable_name: gtk2-immodule-inuktitut solvable_name: yast2-nis-client solvable_name: apper solvable_name: ypbind Regards, Werner --