Sagara Wijetunga wrote:
> James Tyrer wrote:
>> Sagara Wijetunga wrote:
>>
>>> Hi all
>>>
>>> I have compiled only following KDE components from sources on
>>> Tomahawk Desktop (which is based on FreeBSD 7.2):
>>> Oxygen-Icons-4.3.4 kdelibs-4.3.4 KdeLibs-experimental-4.3.4
>>> KdePimLibs-4.3.4 kdebase-workspace-4.3.4 KdeBase-4.3.4
>>> kdebase-runtime-4.3.4
>>>
>>> The startkde cannot start KDE and the plasma-desktop crashes.
>>>
>>>
>> Have you made any progress? If you are still having trouble, I
>> will try further troubleshooting with you.
>>
>
> Appreciate very much.
>
>> Please use KDEHOME=/$HOME/.kde4 with a user account and post the
>> current error messages.
>>
>> I have to say that I have not used BSD so there might be some
>> obscure issue that you might do better asking about on a BSD list
>> (e.g. is there one for the Tomahawk Desktop).
>>
>>
>
> I have earlier discussed this issue with the kde-freebsd@xxxxxxx
> list, their opinion is, this is a dbus, policykit and consolekit
> related configuration issue and recommended me to discuss here in
> this list.
>
> Btw, before I come to this list, there was a Xorg crash issue, to
> resolve that issue I have upgraded the Xorg from 7.4 to 7.5. Now X
> doesn't crash. After the Xorg upgrade, I have recompiled all packages
> that depend on Xorg. But due to a bug in our package dependency
> tracking, 3 packages were missed. They are: glitz, netpbm and strigi.
> After the bug is fixed, I have recompiled those 3 packages.
>
> Now that improved the situation quite a lot.
>
> Earlier when run startx under root, the interrupt processing load
> shot up to 85%. Under a normal user interrupt processing load was
> 34%. After those packages recompiled, interrupt processing load is
> now either 1.0% or less.
>
> Earlier KDE used to create an additional /$HOME/.kde directory. Now
> KDEHOME=/$HOME/.kde4, creates only the /$HOME/.kde4.
>
> When run startx, I get a nice graphical screen but crashes after a
> while. I can press Alt-F2 and run xterm. The konsole is not stable,
> sometime stay, sometimes goes off.
>
> The latest startx error log is included below. It still shows dbus
> reply timeout errors. This I think we should identify and fix first.
The timeout error:
> Error message was: "org.freedesktop.DBus.Error.NoReply" : " "Did not
> receive a reply. Possible causes include: the remote application did
> not send a reply, the message bus security policy blocked the reply,
> the reply timeout expired, or the network connection was broken." "
>
Does appear to be a problem.
There doesn't appear to be any cause listed for the Plasma crash.
> Is the dbus-cxx (http://freshmeat.net/projects/dbus-cxx) required? We
> have not installed this package. If required, in a working system,
> what other packages depend on dbus-cxx?
No, that isn't needed.
I have these packages installed:
DBus
DBus-Glib
HAL
HAL-Info
PolicyKit
EggDBus
polkit
ConsoleKit
I don't really know if they are all really dependencies for KDE, but
they are what is normally installed on a system using D-Bus/HAL/PolicyKit.
You can follow the BLFS install instructions for these which should be
about the same for BSD or any *NIX.
http://www.linuxfromscratch.org/blfs/view/svn/
If you installed KDE-4 in a directory other than "/usr" or "/usr/local"
you need to add the directory to the list in:
/etc/dbus-1/session-local.conf
and that is most of what I know about D-Bus/HAL. It is a real issue
with me since it is supposed to make thing just work, but it is not a
simple install, is certainly not simple to configure, and there isn't a
GUI configuration application for it. :-( Version 1.3.0 came with a
tutorial: .../dbus-1.3.0/doc/dbus-tutorial.html. I have minor issues
with removable media devices so I am going to try to read it when I get
around to it.
So, you could check your install and configuration against the BLFS
instructions and perhaps see if the tutorial is any help.
The other suggestion for debugging would be to start X with only an X
terminal and then execute:
echo $DBUS_SESSION_BUS_ADDRESS
If you don't get an answer, then:
eval `dbus-launch --sh-syntax --exit-with-session`
and check it:
echo $DBUS_SESSION_BUS_ADDRESS
With D-Bus up and running, execute:
<full_path>/startkde >kde.log 2>&1
This should give you a shorter log with only KDE issues.
There are also tools for D-Bus: dbus-*. Read the man pages
--
James Tyrer
Linux (mostly) From Scratch
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
