John Woodhouse posted on Thu, 19 May 2011 13:53:41 -0700 as excerpted:
> I use kmails filters to sort incoming emails. All are working except for
> one and that's the one that sorts on the basis of from being in my
> address book.
>
> Curious thing is that when I start typing an address that is in my
> address book it auto completes correctly so that aspect seems ok. Also
> suggests that my address book import worked as well.
>
> However if I use tools - address book I see 2 marked "default address
> book" and "address book". Both contain the same thing.
>
> (Just noticed that if I click on each of these it looses the right hand
> pane's content for both and it wont come back on either.)
>
> Any ideas ?
>
> As far as bugs are concerned there may be 3 counting the awol pane.
>
> John
>
> Suse 11.4 64bit KDE 4.6.0 Issue 6
kmail's current relationship with the address book isn't exactly the
best. The address book was ported to akonadi in kde 4.4, with what was
then planned to be a rather temporary workaround (intended for the six
months of 4.4 only, until 4.5) bridging it into the not yet akonadified
kmail-1, as 4.5 was supposed to introduce the fully akonadified kmail-2.
However, as a lot of people predicted when it became known that they were
trying to base a mail program on an sql database, actually getting it
stable, and as importantly, getting the conversion utilities to work
/reliably/ on what could well be a decade or more of mail for some people,
was rather harder and has taken rather longer than they anticipated. 4.5
came and went. 4.6 came, and with 4.6.3 we're more than half the way thru
the 4.6 cycle, and a reliably stable kmail2 has yet to appear.
Of course that can be considered a very good thing, since the kdepim folks
*COULD* have just crammed it down kde users throats, regardless of it
still being broken, huge gaping holes in functionality, let alone stablet,
much like the kde plasma folks and to some extent the rest of the kde4
platform folks did with kde4 as a whole, giving the users little
alternative as they were yanking support for the previous /stable/
version, while *INSISTING* the current version was "ready for ordinary
use", even as the bug reports stacked up with "oh, that feature isn't in
kde4 yet", so they *KNEW* the thing wasn't even feature complete let ALONE
stable, even as they were INSISTING it WAS stable, and yanking support for
the REAL stable version while they were at it!
But at least the kdepim folks seem to have taken the lesson, and if
anything, might arguably be going overboard the other way with the
akonadified kmail2, not calling it stable until it is *REALLY* stable, and
perhaps more importantly, until the conversion scripts don't eat people's
mail for lunch! FWIW, I'm one of those folks with over a decade's worth
of mail to convert, so I'm grateful they ARE being careful -- as it's MY
mail that could well be eaten for lunch otherwise!
But that doesn't change the fact that we're now close to a year and a half
into a "temporary" situation with the address book already ported but kmail
not, that was supposed to be done in six months. They've done some work
to improve the situation over that time, but it's still far from ideal,
and there are still quite some bugs.
Meanwhile... there are likely some things you can do to help the
situation.
1: Check your akonadi backend and consider switching from the mysql backend
to the sqlite3 backend, if possible and supported by your distribution.
Mysql might be a very good database to use... for professionals that are
familiar with databases and know how to tweak them to get the best out of
them. It's *NOT* a particularly good database for desktop users who "just
want it to work", without somebody handling the various tweaks necessary
to get it to run properly and without complaint, and taking care of
upgrades that tend to break various bits of older databases. (FWIW, amarok
has had similar problems with their mysql database backend... but they
don't have an alternative, one of the reasons I'm now a /former/ amarok
user!)
Unfortunately, earlier in akonadi development, the sqlite backend wasn't
yet multi-threading stable and mysql was the more mature backend, despite
its complexity.
The problem is that while I believe kde upstream and most distributions
have now switched to the in-the-meantime matured and far less troublesome
sqlite3 backend by default, it so happens that this setting is a per-user
setting, and most existing users from the kde 4.4 era will still have the
mysql backend set as their database, until/unless they've specifically
changed it themselves.
Unfortunately, apparently, the GUI tools for changing the backend haven't
been properly updated either, because they too are a apparently stuck in
kde 4.4 era kdepim mode due to the kmail2 delay. Thus, it's a manual text-
based config file edit procedure.
First, verify the system default as set by your distribution. If they're
still defaulting to mysql, you may wish to check with them before changing
it. With luck, however, they'll have it set to use the sqlite3 backend.
To check, find the system default akonadiserverrc file. Here (Gentoo),
it's /usr/share/config/akonadi/akonadiserverrc, but that might differ
depending on where your distribution puts kde or if you compiled it
yourself.
The content of mine is just the two lines:
[%General]
Driver=QSQLITE3
Again, if yours still says mysql, check with your distro before changing
anything! But, if yours is as above, then check what your user setting
is. (The third alternative is a postgresql driver, but AFAIK it's still
experimental. Still, in theory it's possible your distro uses it, so you
could see it set there.)
The user akonadiserverrc file should be
$XDG_CONFIG_HOME/akonadi/akonadiserverrc . If XDG_CONFIG_HOME is unset,
the default is ~/.config, so the file will very likely be
~/.config/akonadi/akonadiserverrc .
This file will probably have a few lines more than the system file has.
But the important thing for us is again, what that Driver= line says. If
it still says MYSQL or similar, do consider changing it to be the same as
the system setting. (As usual when editing config files directly, you'll
want to do this when the stuff you're configuring is shut down. Editing
it right after booting, before starting kde, is probably best, as I recall
issues with the mysql instance not shutting down when I quit kde. But
doing it after a reboot before starting kde, at least as the user you're
editing, should solve that problem.)
FWIW, after switching to the sqlite driver, things have worked **MUCH**
better for me here. The problems I used to have with the mysql driver
version, akonadi not starting correctly, akonadi/mysql not stopping when I
logged out of kde, etc, now gone! =:^) With the exception of the cleanups
in steps two and three below (which I believe to be left over from either
the initial conversion or from mysql bugs), everything has marvelously
"just worked" since, definitely NOT the case when I was using the mysql
driver.
OK, back in kde...
2: Check your contacts resources.
Open kcontrol (umm... systemsettings that are mostly kde specific user
settings, NOT system settings, so I continue to use the more accurate kde3
term, kcontrol), common appearance and behavior, kde resources. Select
contacts from the dropdown.
You may have one or more entries. If you click add, the first page of the
add-resource wizard gives you a list of the possible types and an
explanation for each. You can then click cancel if you don't really want
to add a resource. You'll want one contact resource set as standard --
the one that new/changed entries are written to if no other resource is
specified (as such, this resource needs read and write access, check
permissions if necessary).
It may be that you have additional entries here, thus the two views of the
same thing in the address book. The old address book type was apparently
file (a vcf/v-card-file). The new one is of course akonadi. While I have
kmail filters, none of them are address book based so I'm not sure on
this, but I suspect it may not understand the akonadi resource. You /may/
have better luck, therefore, using the old vcf file resource, setting it
as standard, etc. Or perhaps kmail doesn't actually work with any. That
might be functionality that's broken due to the above extended temporary
state. As I said I don't actually use address book based filters, so I've
no way of knowing for sure.
But FWIW, I have only one resource configured here, the old-style vcard
file type. My file paths are a bit customized here, but I believe the
default location for it is $KDE_HOME/share/apps/kabc/std.vcf , with the
default location for $KDE_HOME if that variable is unset being ~/.kde as
set by kde upstream, tho many distributions use ~/.kde4 instead.
BTW, it might be a good idea to go clean up that dir. Note that kde keeps
a number of backups, file.vcf_X, where X is a number. They should all
have recent dates. However, you may ALSO have several stale file.vcf__X
(two underline chars instead of one). These will likely be far older if
you check the dates. If so, it should be safe to delete them as they
really are stale. Similarly with the lock subdir -- I had a number of
very old lockfiles, probably from the conversions when I first switched
from kde3, that I deleted.
3: Check your akonadi config.
This bit has a gui, apparently designed to be part of kcontrol, but it
isn't. Which is good as part of the gui hasn't been updated for the new
sqlite3 driver mentioned above, and would be confusing without
explanation. However, it's possible to run the gui manually, /if/ you
know about it. (FWIW, there's a few other such "hidden" kcms, kcontrol-
modules (kde still uses kcm term in the filenames, even if it changed the
gui name to the inaccurate systemsettings) lurking around too, sometimes
used in various app-configs themselves -- konqueror's settings dialog is
mostly kcms -- sometimes without any obvious direct gui method of running
them.)
To start the gui, run from krunner or a konsole window or whatever:
kcmshell4 akonadi
On the server config tab:
If you're using the sqlite3 driver as I described above, the database
driver dropdown will be blank. If you're using the mysql or postgresql
driver, they'll be listed. This is the bit that I said hadn't been
updated for the new driver. =:^( Otherwise switching drivers would have
been a simple matter of choosing from the dropdown instead of having to do
that manual textfile editing, above.
Below that is some postresql driver settings that I won't say anything
else about since I've never used that driver or postgresql at all.
At the bottom, it lists current status and has buttons to test, stop and
(re)start akonadi. These should be safe to use. Just don't change the
driver and hit apply. =:^)
If you run the test, it'll give you some diagnostics. Green check is
passed, blue check is skipped (here, the mysql tests as I'm using the
sqlite3 driver instead, and the protocol version check), red X means there
*MIGHT* be a problem.
You can click each one to get a description at the bottom. If the error
logs X, the description has a link to the file that should be clickable.
I have Xs for previous control and server error logs, but viewing them
simply shows a message about quitting because the dbus session bus went
down. That's not a problem, thus the *MIGHT* above. Of course, if that's
in your CURRENT error log, it very likely IS a problem, but then you
probably have other issues going on as well as kde is pretty broken
without dbus.
I also have an X for nepomuk search service not registered, but that's not
surprising since I have it shut off in kcontrol (under workspace
appearance and behavior, desktop search). I may have to turn nepomuk back
on (but leaving strigi off) for akonadified kmail2, and indeed, having it
off might be a problem for your address book filters too, but as I don't
have any of those and in general find the semantic desktop stuff more
irritating than useful, I've seen no problems with nepomuk off, here.
It's certainly not needed for current kmail's main functionality, I know
that.
Back on the resources config tab:
I had a whole bunch of duplicated resources here, possibly due to multiple
paths to the same objects due to symlinks. I went thru and cleaned them
up at one point, but opening this kcm again as I write this reply, I
either didn't clean up all the dups that time due to being extra cautious,
or the system again found them. So I just cleaned up the dups once again.
I know the huge number of duplicated resources I originally had must have
been due to an earlier bug, possibly due to the problems with the mysql
backend. That certainly couldn't have helped akonadi to function well.
However, the far fewer dups I had this time may well be a simple akonadi
kcm bug -- it is after all still basically a 4.4 version kcm, not updated
to current because all of kdepim has been stick waiting for kmail2. We'll
see if they come back. Meanwhile, the actual on-disk file (and its
backups) is still there, and still accessible from the single address book
resource I kept.
After doing all these cleanups, it's probably a good idea to shut down kde
and restart it again, just to be sure. After doing that, hopefully your
kmail address filters will work properly.
If not... I do really expect kdepim 4.7 to come out with kmail2, as
stable, with the rest of kde 4.7, in late july, according to the posted
schedule.
FWIW, 4.7 feature-freeze is supposed to have happened already, with beta-1
supposed to have been tagged today (19th May) for release next Wednesday
(25th). Seeing if kdepim is in it and what any beta reviews have to say
about it could be a good hint as to whether they plan to release it with
4.7 or not. In theory, they could release a late 4.6 kdepim, but I just
don't see it. I believe they'll wait for 4.7.
FWIW, kde schedules page on techbase (courtesy of someone else posting the
link earlier, which I bookmarked! =:^) :
http://techbase.kde.org/Schedules
--
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 mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
