Kmail - which parts of this are bugs

[Duncan]

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.