Problem with kmail

Duncan 1i5t5.duncan at
Tue Dec 13 17:41:58 GMT 2011

Harald Baumgartner posted on Mon, 12 Dec 2011 16:56:48 +0100 as excerpted:

> kde 4.7.2 kmail 1.13.6
> addressbook adding contact works, but inserting a Emailadresse works,
> too. Click Ok, but after ~5 seconds the emailaddress disappear
> .xsession-errors:
> akonadi_kabc_resource_7(2131)/kio (KDirWatch)
> KDirWatchPrivate::removeEntry:
> doesn't know "/home/hmb/.kde/share/apps/kabc"
> akonadi_kabc_resource_7(2131)/kio (KDirWatch)
> KDirWatchPrivate::removeEntry:
> doesn't know "/home/hmb/Documents"
> login/logout/reboot - nothing helps.			Any idea?

I'm not the most ideal responder to this question as I recently switched 
to claws-mail, but I waited a day and no one else responded (with 
anything that hit gmane's list2group service, where I read/respond, at 
least), so here's mine.

The most obvious bit first.  Do those mentioned directories exist and are 
they readable and writable by your user?

Other than that, I don't have a direct response, but there's some kmail 
development status information that may be helpful to you... or not.

Here's the deal.  Both kmail and kaddressbook ship as part of kdepim, 
from kde, which splits up the main kde software release into a number of 
separate modules, kdelibs, kdepim, kdegraphics, kdegames, the former 
kdebase which is now itself split into kde-baseapps, kde-workspace and 
kde-runtime, etc.  Each of these modules ships as one tarball and 
contains a bunch of apps and libraries with related functionality, with 
the entire set depending on the first one, kdelibs.

kdepim thus contains a bunch of related "PIM functionality" apps and 
libraries that can run together in the groupware suite called kontact, or 
separately as individual apps such as kmail, knode, akregator, korganizer, 
etc.  Thus, kmail and kaddressbook are really part of kdepim, which 
ORDINARILY ships as part of the larger kde software collection, version-
synced accordingly, so with kde 4.7.2, there's a kdepim-4.7.2 tarball 
along with the kdelibs-4.7.2 it depends on, etc.

So far, so good, but here's where it starts getting complicated.  With 
kde4, the kdepim devs decided to rewrite all the kdepim apps to share 
common code.  A number of these apps, plus kopete, use contact info, for 
instance.  Why not share the same contact management code between all of 
them?  And the standard Internet message format used for mail is also 
used for news (nntp), so why not share the code for managing it between 
knode and kmail, plus of course the groupware kontact?

It was thus that the database-backed akonadi middleware framework was 
born, the common framework all these apps were to share after they were 
rewriten to use it.  But it took some time to get akonadi off the ground, 
up and running in a mature enough way to support the rewriting of all 
these other apps to use it.  Thus, kde 4.0 thru 4.3 had a maturing 
akonadi, but none of the kdepim apps used it yet.

With kde and kdepim 4.4, kaddressbook became the first app to be 
"akonadified".  The plan at that time was for kmail to be next, with 4.5, 
so a number of temporary code shims were developed to let the not yet 
akonadified kmail continue to function against the newly akonadified 

Except that the kmail rewrite, with the new akonadified version called 
kmail2, took longer than expected, and even after kmail2 was working well 
as a new installation, for those with an existing kmail-1 installation, 
there was the whole kmail-1 -> kmail2 conversion process to deal with, 
and that didn't go as smoothly as expected either.  Of course, people 
rightly get a bit upset when perhaps a decade of mail gets lost in an 
"upgrade", so it was vitally important to get the conversion process 
right, as well.

So kdepim wasn't ready with the new kmail2 when 4.5 code-froze, and 
instead, a kdepim-4.4 update was shipped, with just a few changes to the 
"glue code" so it would continue to work well with the new 4.5 kdelibs.  
The last kde 4.4 release was 4.4.6, IIRC, but when kde 4.5 came out they 
bumped the kdepim version to 4.4.7... and continued bumping it as needed 
thru, ultimately,

Meanwhile, kde 4.5 came and went, and 4.6 was introduced.  With kde 
4.6.0, kdepim was getting closer, but wasn't ready yet, so it continued 
on the 4.4 series.

Along about kde 4.6.3, kdepim was finally ready with a testing version, 
which came out as kdepim-4.6.0 and included the first public release of 
kmail2.  IIRC it was released almost exactly the same time as kde 4.6.3.  
Later, there was a kdepim-4.6.1, but both kdepim-4.6 releases were 
primarily for users who wished to test -- the kdepim folks had found and 
fixed the bugs they could testing on their own, so they needed more 
testers, particularly for the existing kmail conversion code.

So with 4.4 kdepim akonadified kaddressbook, with the goal of having the 
akonadified kmail2 ready by 4.5 and only temporary glue code supporting 
the interaction between kaddressbook and kmail (1).  But the akonadified 
kmail2 wasn't ready for 4.5, and there was no kdepim 4.5 release; they 
continued to ship updates to the kdepim-4.4 series.  Those kdepim-4.4 
series updates continued thru kde 4.6, altho two experimental kdepim 4.6 
versions were released.  That brings us up to kde 4.7 with most users 
still using a kdepim 4.4 series release.

With kde 4.7, kdepim resynced its releases with the rest of kde, so there 
was a kdepim 4.7.0 when kde 4.7.0 released, and a 4.7.1, 4.7.2, 4.7.3 and 
just recently the last 4.7 series release, 4.7.4, with kdepim releasing 
its versions synced with the rest of kde, shipping kmail2 as part of 

But while the upstream kdepim declared 4.7 ready for ordinary users, many 
distros played it a bit more cautiously and continued to ship kdepim 4.4 
which by this time, while it's getting a bit stale and has a few issues 
with that intended-to-be-temporary glue code, is a quite well understood 
set of software.

That's where you come in as you're running kde 4.7.2, but with kmail-1 
still, which means you're still running the kdepim 4.4 series, probably 
kdepim as it was the last version in that series, but released 
some time ago now.

Which means that you're still using the "temporary" glue code that was 
originally intended to keep kmail-1 working with the akonadified 
kaddressbook for just six months, only it's two years later!

That also explains the apparent lack of progress in kdepim apps including 
kmail for two years, while the rest of kde continued to change and 
(hopefully) improve.  The kdepim that many are using is two-year-old 
code, with just enough glue to keep it working with the rest of kde that 
has been updating all this time!

But meanwhile, the kdepim devs have moved on, and no more kdepim-4.4 
series updates are planned.  Already with kde 4.7, there's a few bugs 
developing, and it's possible that you're running into one of them here 
-- I've not kept track of them to know.  While the kdepim folks had 
declared kdepim-4.7 ready for ordinary use, they understood the 
reluctance of distros to ship it, and while no more 4.4 series updates 
are scheduled, they did cooperate with the distros to develop distro-
applied patches for some of the bugs, at least.

But with the upcoming 4.8, 4.8.0 scheduled for release near the end of 
January and 4.8-beta2 (aka 4.7.90, which I'm running BTW) out now, all 
upstream focus is now on the current kdepim series and no further support 
for distros continuing to ship the old 4.4 series is expected.  With bugs 
already showing up due to the mismatch, most distros will again sync 
their kdepim releases with the rest of kde, beginning with the new year 
and kde 4.8.

Which means existing kmail users are facing a flag-day upgrade to a now 
current kdepim and kmail2 early next year.

That's the history and existing situation as fairly and objectively as I 
can portray it, but as I mentioned above, I myself recently switched to 
claws-mail, after being a kmail user for nearly a decade, since 2002, kde2 
era, so it should be rather obvious that while I understand why the kdepim 
folks are doing what they're doing, it didn't work for me and I switched 
to something else.

Clear back when kde 4.4 was released with the then newly akonadified 
kaddressbook, like a lot of others I had my doubts, especially with the 
whole database backend thing.  But kmail had been good to me for over 
half a decade (~7 years, at that point), and between not wanting to do an 
unnecessary switch and wanting to give the kmail folks a fair chance to 
prove their wisdom, I waited, living with the inconvenience of that 
temporary glue code and a not really being updated kmail (and akregator 
as well, another part of kdepim that I used) thru 4.4, 4.5, and the early 
4.6.  When kdepim 4.6.0 came out, I decided to try it.

The kdepim 4.6.0/kmail2 upgrade process wasn't bug-free, it wasn't really 
expected to be at that point, especially on a mail corpus nearly a decade 
old from kmail, plus the import from MS Outlook Express that I'd done in 
2002, going back another half decade or so, but after a couple attempts, 
I managed to get pretty much everything converted.  But the going wasn't 
smooth even after that, and I lost the conversion and had to do it over.  
No big deal.  It's early release.

Then kdepim-4.6.1 came out and I upgraded to it.  By this point I had 
akonadi more or less configured so I wasn't losing my imports any more, 
but there were continuing problems processing new incoming mail.

But the real irritant for me wasn't so much that, as the whole weigh-down 
effect of akonadi on my system in general, and some weird notifications 
that came up at every boot because I had nepomuk turned off for 
performance reasons, and akonadi wanted it turned on so it could sync 
stuff like korganizer calendars and other stuff I didn't even have 

To be fair, I understand that some of the issues have been corrected by 
now.  However, a week or two before 4.7.0's release (I was running 4.7-
rc2, minus kdepim as they hadn't done release candidates and only synced 
with 4.7.0 itself, so it couldn't have been earlier than that), I finally 
had enough.

Compounding the problem for me was the fact that while Gentoo (my distro 
of choice) allows compile-time choices such as building kde without the 
semantic-desktop support (nepomuk, etc), which I had installed but turned 
off, the way Gentoo handles it, anything kdepim (including akregator, 
which at that time wasn't akonadified) pulls in kdepim-common-libs, which 
in turn pulls in akonadi, which in turn forces USE=semantic-desktop and 
thus nepomuk, etc, for all of kde, and since I had it turned off anyway, 
I really wanted to be able to uninstall and not have to worry about 
upgrading nepomuk, etc, for the coming 4.7 upgrades.

So began my search for a new mail client.  I don't like groupware so 
evolution wasn't my style, and don't have nor want gnome installed which 
cut out a few others (IIRC balsa was in this group).  While as any good 
Gentooer I'm not afraid of a text login, console-based email isn't my 
style either, so that cut out more.  And my ISP doesn't support IMAP, 
only POP3 and webmail (which I don't use either), so a couple IMAP-only 
mail clients went by the wayside as well.

But I do have gtk2 installed, for firefox and pan among other apps, which 
made sylpheed and claws-mail (originally the experimental branch of 
sylpheed, as sylpheed-claws, back in 2002 when I had looked at it before, 
of course knowing FAR less about Linux at the time...) natural 
possibilities with few additional dependencies.

Claws-mail ended up being pretty close to the perfect match!  As with the 
kmail upgrade, converting my nearly decade and a half (~9 years of kmail 
plus the OE import going back another 5-ish... I had beta-tested IE/OE4 
before MSWormOS 98 came out, and have mail going back to then) of mail 
from kmail didn't go without a hitch, but it wasn't much worse than the 
kdepim 4.6.0 conversion had been, either, and that was kmail -> kmail!  
(The conversion script I used to convert to claws-mail mh-format was a 
bit dated and needed a bit of hacking, but so did the kmail upgrade.  
I've since seen ideas from a few others for the conversion, including 
installing an IMAP server temporarily.  YMMV.  Of course if you're 
already using an IMAP server, it should be much easier.)

Similarly with the addressbook conversion.  It wasn't painless as I had 
to hack the script a bit to do it, but I got it done.  Some people might 
instead choose to simply import addresses from their mail archive once 
it's converted, thus avoiding the second conversion, but I had some 
contacts, relatives and such, that I didn't want to lose that I've never 
actually mailed, so I used the conversion script, even if it took a bit 
of hacking.

I use about 50 mail filters to despam (no separate despammer like spam-
assassin) and sort my mail into different folders based on who its from, 
the email address it comes in on, etc, and I had to convert those by hand.

So it wasn't a painless process by far, but other than the mail filter 
bit, it was more or less comparable to the kmail -> kmail upgrade, which 
had its own bugs.

Meanwhile, claws-mail is actually more customizable than kmail, including 
hotkey configurability and external command hooks, and unlike the 
akonadified kmail2, it's at least as fast as kmail-1 if not faster.  As 
most gtk based apps, it uses the color scheme kde exports if you've 
checked that option in kde's color settings, so it doesn't look 
unreasonably out of place on a kde desktop.  In general, I've been very 
happy with claws-mail, and if anything, wish that I'd switched to it back 
when I started having doubts when kaddressbook went akonadified in 
kdepim-4.4.  Except then, I'd have not been able to say that I gave the 
akonadified kmail a fair chance, which I /can/ say, now.

So I worked hard at the conversion to claws-mail, delaying my upgrade 
from kde-4.7-rc2 to 4.7.0 by a couple days to get it done, and then 
upgraded to kde 4.7.0, kmail-less for the first time in ~9 years!

Unfortunately, I was still running akregator as my feed reader at the 
time, and while it hadn't been akonadified (yet, they plan on it as they 
plan on akonadifying all of kdepim!), it did use kdepim-common-libs, 
which in turn still pulled in akonadi, so I wasn't able to get rid of it 
just yet.  But eventually I found a replacement for it too (the story 
there I won't go into as this reply is already long enough), and 
uninstalled it.

That allowed me to uninstall everything kdepim related, including akonadi, 
which then allowed me to turn off USE=semantic desktop, and uninstall 
nepomuk, virtuoso, redland, rasqal, soprano, etc.

Now I'm running kde4 without one of the supposedly prime features of 
kde4, semantic desktop, and you know what?  It's **MUCH** faster.  
Somewhere in all that akonadi/soprano/nepomuk/redland/rasqal/virtuoso 
junk, was something that was DRASTICALLY slowing down the system, even 
with what I could turn off turned off.  Maybe it was the combination of 
all of them, I don't know.

What I DO know is that getting rid of them, the system felt as if I'd 
just added a couple of extra CPU cores or bumped the speed by a half a 
gigahertz or so!  I can rather identify with those MS users who suddenly 
find out how much performance either the anti-malware scanners or all the 
malware they got was sucking from the system, when the remove it!

And for the first time since kde3, I'm actually more satisfied with kde4 
than I was with 3.5.9 and 3.5.10.  I find it rather ironic that it's only 
after killing all that semantic-desktop junk that's supposedly one of the 
prime kde4 features, and switching away from the now akonadified kmail, 
that it happened, but I'm quite happy indeed with what's left of kde4, 
now, including the desktop, all the effects, etc.  No more semantic-
desktop millstones around MY system's neck, thank-you-very-much!

That's my experience and opinion, FWIW.  Now back to you.  You're on kde 
4.7, but still using kmail-1, which means you're still running the kdepim 
4.4 series.  But presumably with this spring's upgrade, you'll be 
upgrading to kde 4.8, and with it, most likely kdepim 4.8 and thus the 
akonadified kmail2.  For all I know you won't have any problems with the 
upgrade and will really like kmail2.  But, now's your opportunity.  If 
you've been thinking about trying something other than kmail, now's the 
time to do it, so you don't have to worry about the coming kmail upgrade 
at all.

Alternatively, forewarned is forearmed.  You know the upgrade is coming, 
and can reserve some extra time now to deal with any problems it might 
bring with it.  The upgrade does leave your existing mail store in place, 
so that shouldn't be a problem, but as with any format upgrade, it's a 
good idea to make backups AND AS IMPORTANTLY test that you can restore 
from those backups, if it comes to it.  Also, because the existing mail 
store continues to exist and akonadi actually continues to store the raw 
form message in it, it just has a database version of the data as well, 
you can expect the combined mail store and database usage to about double 
the disk-space required for mail.  That's not too bad on today's sized 
disks, but it can be a factor for some.

Either way, you have some changes ahead.  Which way you go is your 
decision, and continuing with kmail or switching to the kontact groupware 
suite may well be your best choice.  But because of the switch to 
akonadified kmail2, even that's a major change, which you know about now, 
so can be prepared. =:^)

Hope it's helpful, even if it's not really much of a direct answer for 
your current problem.  At least you have some idea of the general 
situation and can better plan for the coming changes, now. =:^)

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:
More info:

More information about the kde mailing list