Problem with kmail
Duncan
1i5t5.duncan at cox.net
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
kaddressbook.
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, 4.4.11.1.
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
kdepim-4.7.
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 4.4.11.1 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
installed!
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: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
More information about the kde
mailing list