Re: [kde-linux] KDE 4. Trying to get it working like I need it to.
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Date: Mon, 9 Nov 2009 13:05:02 +0000 (UTC)
Dale posted on Mon, 09 Nov 2009 05:12:48 -0600 as excerpted:
I log into KDE 4 whenever there is a update to something just to see
what is working and what issues still remain. This is hopefully going
to be the catch all thread for me. Right now, I have two things that I
want to work on. There are others but this is two biggies. I will say
that after this last update, it is looking pretty darn cool.
I'm using Gentoo. I have both KDE 3.5 and KDE 4 installed. After
yesterday, I have the latest updates that are available through Gentoo.
Here are the versions of some of the software that may help in this:
This is all the dbus related stuff:
If it matters,
Problem one, I used to use Konqueror as root to edit config files and
such. I have to be root to do this. I set Dolphin up to run as root
and it comes up fine. I even like the look so far. The last time I
tried this it wouldn't even open a folder, directory or whatever you
want to call it. It does after this latest update today. I assume that
got fixed. However, if I got to a directory like /etc ,which is owned
by root, and try to open a text file, I get a error. It won't let me
copy and paste so it is a screen shot. It basically complains about
Klauncher and dbus. Screen shot is attached as screenshot1.
[ screenshot (messagebox):
Title: Sorry - Dolphin
Message: KLauncher couldn not be reached via D-Bus. Error when callling
start_service_by_desktop_path: The name org.kde.klauncher was not
provided by any .service files
OK button only. ]
As you know, I run Gentoo as well. ~amd64, updated (deep newuse) a
couple times a week, revdep-rebuild done after update, emerge depclean,
then second revdep-rebuild if anything removed, to be sure. Same gcc,
newest available ~arch.
You "set Dolphin up to run as root", but didn't describe how. Did you
create a new menu item for it or change the current one, or are you
starting Dolphin as root using some other method?
What it looks like to me is that it's not starting a full root dbus
session (distinct from the user dbus session), so it's having problems
reaching it. In some cases that can be due to how it was started, and
may involve errors even launching the kde app (tho you say it doesn't,
now) as a user other than the one you're running X as.
FWIW, I don't tend to run much GUI as root, especially to edit system
config files and the like. For that, I use mc, an ncurses based dual-
pane filemanager type app (krusader would be the kde/graphical equiv),
run in a konsole window while in X/KDE or directly, when in text mode.
It just works better for me, because I get the same ncurses semi-GUI
interface regardless of whether I'm running in X or not, it doesn't
require any special d-bus permissions to run as root (I just start a
konsole session, sudo to a separate "admin" user that has less strict
sudo rights than my normal user rather than directly to root, and sudo
from there to root for individual commands as necessary). As such, I
wouldn't see the running-kde-apps-as-root issues you're dealing with,
since I don't normally run any kde apps as root.
If you wish to try something like that we can probably take that off list
and I can help you set it up. Or we can continue working on this,
probably on-list, but I'm simply saying since I don't do it the same way,
I may be of limited help...
Problem two, akonadi isn't working. I did Google for this and I
couldn't find a fix but it appears to be a common issue. It appears to
be a mismatch between software versions. This may be as simple as
someone who has it working posting what version they are using and me
matching that. It may be something else that is needed. This is the
error that it gives:
Akonadi Server Self-Test Report
I'm not yet running akonadi... probably won't until k-address-book (kab)
requires it in kde 4.4. So again, can't help you directly. However...
1) You don't mention where these tests are coming from. Are they the
FEATURES=test run at build/install time? Are they some GUI test run from
within KDE later?
2) I'm not sure if akonadi works properly with sqlite. Mysql is the
normal requirement. I do see that akonadi (which is NOT merged/installed
here, unneeded in my config) doesn't require mysql be installed as a
dependency, here. akonadi-server (which IS merged, required for various
bits...) has both mysql and sqlite USE flags, neither of which I have on,
but then I'm not actually using it that I know of, only building against
it as building against it is required by various kde components I have
installed, even if it's not actually used.
3) The tests do seem to indicate that your akonadi-server is configured
for sqlite, not mysql. As such, several of the mysql-only (early) tests
are skipped, some of the middle tests fail, and the later ones succeed
but perhaps only because it's not actually running to create the error
4) What I'd guess is happening here, is that you've setup kde in what
amounts to a "null-akonadi" config, which is basically what I've done as
well, only I'm not running this test and don't know where it is to run.
The null-akonadi config would be possible since akonadi isn't actually
required by much in kde4 yet. akonadi itself isn't required, but even
where it's not used, there are a few components that build against
akonadi-server, so it's required for these various components to link
against, even when akonadi itself isn't and may not be merged. In such a
config, akonadi tests wouldn't be expected to succeed, because it's not
actually installed, only the null-server bits are installed, just enough
for the kde components that require them to link against can be merged.
5) What logically follows is this question: You see akonadi failing, but
do you know for sure that you actually need it for anything? If not,
that's likely a USE flag based choice available in the Gentoo
installation, since many people don't actually need it at this point, and
thus don't care if it actually works. Of course, if there's some bit you
need that you know is failing without a running akonadi, then we go from
there, but I know that I don't need it for anything, here. kmail, which
will require akonadi from kde 4.5, doesn't need it yet, and kab
(kaddressbook), which will require it from 4.4, doesn't need it with 4.3
either. Some of the koffice bits require akonadi-server, but at least
the bits I have installed here, don't require akonadi itself. Of course,
starting with kde 4.4, I /will/ require it for kab, which will require it
with 4.4 (unless I just nix kab at that point), and for 4.5, I /will/
require it regardless, as kmail itself will require it then and I'm
unlikely to nix kmail... unless the switch to akonadi breaks it and I
have to. But those are some time off. With kde 4.3.x including 4.3.3, I
have nothing merged /here/ anyway that actually requires a usable
akonadi, so I don't worry about it.
Related but slightly OT...
At present I'm not using the semantic desktop stuff, either, and it too
is "null-installed". That is, soprano is installed, but using a USE flag
config that deliberately does NOT install a working backend. The problem
is that there are only two working backends ATM, redland, which is
*SLOW*, and sesame2 is Java based and thus requires a working Java
backend. While most of Java is now freedomware licensed, that's a recent
enough development that there's still some issues with it, and with the
only reasonably full implementation that's fully freedomware compliant,
iced-tea. I /do/ finally seem to have iced-tea working correctly with
icecat (fully freedomare version of firefox), but that's only as of a
month or so ago, and wasn't the case back with kde 4.3.0. Since the
EULAs required for sun's and blackdown's non-freedomware versions aren't
a viable option here and iced-tea wasn't working, that meant sesame2
wasn't a viable option, leaving only the redland backend that everybody
equally calls *SLOW*, making it not worth installing either.
Luckily, the semantic-desktop stuff isn't yet integrated so deeply into
kde4 that it's absolutely required, yet, and while soprano seems to be a
non-optional dependency for linking purposes, it doesn't require an
actually working backend, Gentoo gives one the option of not installing
one and not enabling the semantic desktop bits, and I've been fine
The latest is that there's now a third backend option, I forget the name,
but it's a much faster C based backend, 100% freedomware, AFAIK.
However, I don't expect that'll be actually integrated into the kde 4.3
serious, only for 4.4 or possibly not until 4.5 (tho the blogs via kde-
planet say it's usable in kde-trunk right now). I'm looking forward to
that. It's also possible that now that I finally have a working iced-
tea, sesame2 would work, but I'm not going to worry about trying it ATM.
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
More info: http://www.kde.org/faq.html.
- Prev by Date: Re: [kde-linux] KDE 4. Trying to get it working like I need it to.
- Next by Date: Re: [kde-linux] KDE 4. Trying to get it working like I need it to.
- Previous by thread: Re: [kde-linux] KDE 4. Trying to get it working like I need it to.
- Next by thread: Re: [kde-linux] KDE 4. Trying to get it working like I need it to.