[kde-linux] KDE 4. Trying to get it working like I need it to.

[Duncan]

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:
> 
> sqlite-2.8.16-r4
> sqlite-3.6.18
> kdelibs-4.3.3
> akonadi-server-1.2.1
> akonadi-4.3.3
> 
> This is all the dbus related stuff:
> 
> dbus-glib-0.76 (0)
> dbus-qt3-old-0.70 (0)
> dbus-python-0.83.0-r1 (0)
> dbus-1.2.3-r1 (0)
> qt-dbus-4.5.3-r1 (4)
> 
> 
> If it matters,
> 
> gcc-4.4.2
> 
> 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 
logs, etc.

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 
without it.

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