[kde-freebsd] Re: start kde fails after reboot

[Gua Chung Lim]

Hi All,

> Weird... There was also a library lookup failure in your log, apparently
> related to nepomuk.
> 
> If you log into twm or whatever currently works, then open a terminal
> and run kdeinit4 and/or some KDE4 program, do they work?
In xterm...

gua at bsdhost:~% /usr/local/kde4/bin/kdeinit4
kdeinit4: Shutting down running client.
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
KDE Daemon (kded) already running.
kbuildsycoca4 running...
kbuildsycoca4(2057)/kdecore (services) KServicePrivate::init: The desktop entry file  "/usr/local/share/applications/kde/koffice.desktop"  has Type= "Application"  but no Exec line 

kbuildsycoca4(2057) KBuildServiceFactory::createEntry: Invalid Service :  "/usr/local/share/applications/kde/koffice.desktop" 
kdeinit4: Fatal IO error: client killed
kdeinit4: sending SIGHUP to children.
klauncher: Exiting on signal 1
kdeinit4: sending SIGTERM to children.
kdeinit4: Exit.
gua at bsdhost:~%

And nothing else happens. I have also tried the others e.g. kdevelop or kcalc.
They all don't work.

> Open the file
> ~/.kde4/share/config/kwinrc
> 
> You will find ( if it is enabled ) a [compositing] section
> In it you should find a line "Enabled = True"
> Change it to "Enabled = False"
> 
> Then log out then back in.
I have tried it. It still doesn't work.

This is my analysis. If I'm wrong, please tell me.
Right after installing from ports, it works fine.
I logout from KDE4 and I IMMEDIATELY reboot.
After reboot, the binaries are still there.
And those binaries, for sure, are not changed across reboot.
But the subsequent startx fails.
So IMHO, there must be something logically changed during reboot.
It maybe shutdown process or booting process e.g. rc.shutdown.
But all those scripts are default and I did not touch them.
I can only trigger it back to the good state by ``make deinstall''
and ``make install''.
During this experiment, I do not touch anything.
I use the same tarballs in distfiles, with same gcc, same system and same libs.
So recompiling from ports will likely to produce EXACTLY the same binaries.
The binaries before and after ``make'' processes are the same.
So there must be some triggers hidden in those Makefile(s).
It could not be env variables.
csh forks make, I DON'T think ``make'' can even change env of its parent (csh).
And I don't think root env variables can affect env of normal users.
(I startx as a normal user not root.)
It's now far beyond my knowledge.

Any inputs will be highly appreciated.

Thank you.

-- 
Gua Chung Lim