dcopKBfbsS should be a pseudo random file name, namely part of the file name is generated unique among temporary files and would ideally would have enough entropy to avoid pre-cognitive security problems (Sometimes
kbuildsycoca rebuilds a cache of data about the systems configuration, probably for kded.
The ICE connection has been refused
DCOPs test to make sure it is in a sane state is failing, hence it knows it can not provide the communications routing it was defined for and choses to abort rather then screw people over.
DCOP is a core service of KDE so kdeinit which is used to fork off processes while starting a kde session, so it makes sense for it to die loudly.
There is no /home/disappearedng/.DCOPserver_home.lan __0 file or it contains no valid connections because the connection was refused.
The kbuildsycoca warnings for the mime types would suggest that either they are not setup correctly or your syscoca is out of sync.
And the rest just pops a cork loudly since it can't properly execute a kde session, leaving X without much hope of being useful.
So... Out of curiosity:
0/ Have you ever had a working kde install on this install
0B/ if so, what has changed since it last worked?
1/ Is this purely local or is any element of your (if any) network at play? Such as having the home directory mounted over nfs, using an X Display that is not connected locally, blah blah, etc
2/ is it possible to use another window manager or does it too (or X) fail?
3/ Is your X.Org configuration valid.
__________________
My Journal
Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''.
|