Alex Schuster posted on Thu, 07 Jul 2011 02:33:56 +0200 as excerpted:
> A little update on the KDEPIM situation. Kontact sort of works now, but
> it feels slower than before. Even changing between Kontact's different
> modules is slower now. I think about not using Kontact at all, but its
> individual components, with their windows grouped together (a really
> cool feature of KDE4 which I often use). Well, it's not _really_ bad,
> switching takes 1-2 seconds, but it used to be instantaneous before, and
> I like to quickly peek into Akregator and back to see if there are new
> messages.
FWIW, I use neither grouped windows (which don't seem to work with my
chosen window decoration, kde2) nor kontact. I don't use knode or
korganizer at all (along with kontact, not installed at all, except that
korganizer is a gentoo dep of kmail, as covered earlier in the
discussion, so it's installed), tho I do use kmail and akregator... but
as separate apps, generally opening the one I want from its tray icon.
So I won't say anything about kontact/korganizer/knode. And no IMAP,
they're all POP3 (plus a sysmail local maildir folder), so I won't say
anything about imap.
> What I liked about the old KMail was that I could open folders in tabs.
> The problem with this was that folders opened in tabs did not get
> checked for new mail, I hoped this would be fixed. But it seems this
> feature is gone now.
The feature "isn't dead, just resting!" =:^) Really. Unlike the parrot,
you can wake this one up (or resurrect it, if you prefer! =:^).
I didn't initially see the tabs either, and might have concluded they
were gone, but remember, the initial version of the new kmail was
designed to be very close to feature parity with the old one, no fancy
new features yet, just something very similar to the old one, but
akonadified. And tabs are a big enough deal to some that I couldn't
imagine them trying to bill a no-tabs version as feature parity.
The answer, at least here, is to remember that in the conversion, some of
the config might have been lost, too, and in this case, apparently was.
I had the tab-bar set to always show, previously, and when you mentioned
it and verified I didn't see it, I decided to check kmail settings. Sure
enough, I found the option I was looking for there in short order. As I
expected, it's under the appearance icon. Look on the message list tab,
second option down under General.
There it was, "hide tab bar when only one tab is open" was checked.
After unchecking it and hitting apply, the old and familiar tab bar was
visible once again, complete with the new-tab icon on the left and the
close-tab icon on the right.
But as I said I don't do IMAP, so haven't the foggiest if the tabs work
with it, tho I don't see why they wouldn't.
After figuring out about the tabs, I checked the other settings and had
to reset a few more, too, all under the appearance icon, I think.
> Seems like KMail does not know about any of my contacts.
> I do not understand at all how this works. I still have the contacts in
> my address book, so the migration has worked for them, but when I open
> the settings, they show the location as ~/.kde4/share/apps/kabc/stdvcf,
> and this directory is empty. So all this stuff is in Akonadi's mysql
> database now? What's the purpose of this empty directory?
mysql? That could well be your problem, both here and for some of the
others. But there's other alternatives. See below.
> Today I unsubscribed from the ubuntu-users list which I do not read
> anyway, and because of the 250M this folder takes on the IMAP server, I
> decided to delete it. I also wanted to verify if bug 239859 still
> happens, KMail used to crash when deleting IMAP folders while still
> having it open.
>
> Well, what do you think happened? Right, Kontact took ages deleting
> this, became unresponsive, after half an hour I killed the process.
> akonadi_imap_re still was quite busy. [etc]
> Finally, I got an error message, the folder could not be deleted. So I
> deleted it with Thunderbird, which did the job in seconds. KMail still
> showed the folder and its contents, but after a restart it is finally
> gone.
At least part of this is very likely mysql.
The problem, IMO, is that while mysql might be a very reasonable backend
for professional database administrators who have the knowledge to set it
up correctly, it's altogether unsuited for ordinary users, who would
vastly prefer that it just work, without them having to set it up for
best performance, etc -- which mysql pretty much requires. Further, it's
not a one-time thing, either. Due to mysql's version incompatibility
policies, there's also potential format update issues, etc, every time a
user upgrades from one stable series to the next. This sort of thing is
NOT something even most non-database-oriented /technical/ users (like us,
running kde on gentoo) wish to have to deal with, let /alone/ the average
"just so it works" user.
Since we're both Gentoo users I'll take a shortcut and address the
following only from a Gentoo perspective. Readers on other distros
should be able to extrapolate to what they see on their distro,
accordingly.
Here's the deal, akonadi-server has three backends to choose from, mysql,
postgres, and sqlite. On gentoo, you'll find the option exposed as
akonadi-server USE flags. (Actually, I /think/ I've read about a fourth
one as well, but it's extremely experimental, apparently /so/
experimental gentoo doesn't even bother with it.)
Early on, mysql was set as the default because that backend was the most
mature. sqlite had scaling and threading/reentrancy issues that had to
be worked thru first before that backend could be released as ready for
general use, and postgres... is apparently still experimental, but would
presumably suffer some of the same "expert dbadmin preferred" issues as
mysql, so really, sqlite is the only decently viable alternative for
normal users, but it wasn't ready initially, so the mysql backend was the
original default.
(FWIW, I'd argue that's yet another supporting fact for kde4 being
declared "ready for ordinary use" **WELL** before it was ACTUALLY ready
for ordinary use, the only reasonably mature akonadi backend when 4.4 was
released with its akonadified address book was one that's simply not
designed for ordinary joe-blow use, but oh, well...)
According to Gentoo's akonadi-server package changelog, on 07 Sep 2010,
akonadi-server-1.4.0-r1 (for non-gentoo readers, a -rN package version
suffix, where N is a sequential number, indicates a gentoo revision of
the upstream version) hit the tree, with the default backend switched
from mysql to sqlite. Of course, version 1.5.2 is now stable, with 1.5.3
being ~arch, and no 1.4 versions remain in the tree, so that was quite
some time ago in akonadi-server package evolution time, even for
stale^h^hble users, let alone ~arch users.
But in this case there's a rather irregular configuration caveat to deal
with as well. The problem is this. Most kde config items simply inherit
system defaults if a user doesn't change the config, and don't write the
system defaults in the user config so changed system defaults get
inherited by users who haven't specifically changed from system defaults,
themselves.
But for whatever reason, the akonadi-server config behaves differently,
or at least it did here, and the old mysql backend default was written to
the user config even tho I never changed it from the system default.
So when Gentoo's defaults changed to the now mature and more appropriate
sqlite backend, existing user defaults didn't follow, because they had
the previous mysql system default written to the user config! This is
the sort of policy behavior that gives sysadmins something to complain
about and complain I most certainly am!
So basically what I recommend is this:
1) If you have akonadi-server merged without USE=sqlite, set your use
flags appropriately and remerge it.
The merge has ewarns both during pkg_setup and pkg_postinst detailing the
changes, but unfortunately, people don't tend to read them as they
should. And even if they do, those ewarns don't really explain the
implications or give the backstory, as I did above. FWIW, as I both
follow the overlay git logs and pay special attention to any -rN
revisions, often checking the changelogs to see what triggered new gentoo
revisions without and upstream package bump, and having seen a bit of the
backstory elsewhere, PLUS having exactly ZERO love to lose for mysql due
to the various problems I've had with it, I knew about the changes BEFORE
I ever merged that revbump update, and made the recommended changes, very
likely while the package was building.
And I've has **FAR** **FAR** less problems with akonadi since!! There
were the update to akonadified kmail issues to deal with, but those
weren't really akonadi's fault, that I know of, and once I got over the
conversion issues, things have been running quite smoothly (at least as
far as akonadi goes) once again.
As mentioned, the akonadi-server package spits out instructions, but I
listed step 1, so I might as well finish.
2) With akonadi synced as best you can, shut it down and edit ~/.config/
akonadi/akonadiserverrc. (The path might be different if you set
XDG_CONFIG_HOME as I do here, my path is ~/config/akonadi/akonadiserverrc
as I have the var set to ~/config, no dot-dir!) In the %General section
(it's a short file so hard to miss), set the Driver= line to SQLITE3 .
3) Restart akonadi.
Note that I did this long ago, while only the address book was
akonadified, so it wasn't a big deal if something didn't work quite
right, I could (and I think I did have to) resetup the address-book
resource if necessary, and/or delete the several null-resources it setup
due to a bug at the time.
As you have the whole kmail setup akonadified now, a migration /might/ be
a bit more complex for you, tho they may have fixed some bugs since I did
my backend migration and it may go way smooth, too. I don't know.
What I *DO* know is that at least if you're not some mysql specialist who
has already highly customized their mysql settings, it's VERY LIKELY that
you'll find that stuff that was giving you problems before, "just works",
now. That was *VERY* *DEFINITELY* the case here.
So it might be a bit of hassle. For all I know you might have to deal
with the kmail conversion again. But based on my experience at least,
the payoff will be a MUCH more stable akonadi that for the most part
"just works", once you get whatever initial setup issues you have dealt
with.
> This morning, I had some similar message, but it told me about some
> conflicting flags on the IMAP server, and asked whether to keep version
> A, version B or both. I was in a hurry so I did not notice what the
> problem was exactly. I think I kept both.
I'm getting a very similar message every time a mail comes in. Kevin
says it's a known bug at this point, and it doesn't really matter which
one I keep. (If I keep both, I expect I'd end up with two copies of the
message, however.)
> Now, when I select this folder again, I get this message, every time:
>
> <server>: Remote id is empty or invalid.
>
> And the folder has no entries. Restarting KMail and Akonadi does not
> help. At least I can still view it with Thunderbird.
Sounds like that bit's IMAP, which of course I can't help with. But it
also sounds like database syncing issues, which might be backend
related. (I really DO hate mysql, as it really did give me way too many
headaches. But sort of like the blackbox proprietary graphics drivers,
when they/it is loaded, the behavior of the entire thing is suspect, so
even problems that don't have anything to do with it tend to get blamed
on it!)
> Oh, and after this last restart, the folder view shows one unread mail
> in the drafts folder. When I select this folder, there is only one mail,
> grayed out, it's the former draft of this mail I am just composing now.
> There are other drafts, but they only show up in Thunderbird, not in
> KMail.
Sounds like another db syncing issue and imap issue both. But FWIW, I
had a couple mails playing similar tricks on me with my second mail
import attempt (the first manual one), the one that crashed. Best I can
judge it /did/ leave something inconsistent in the database, possibly due
to that crash or possibly because the importer was importing mboxes as
single huge emails, potentially triggering all sorts of weird effects.
However, after I blew that away and reimported, second manual import,
third try including the auto-convert which didn't see the mailstore to
import, it worked fine.
AND, I've not has a single issue of that nature since. =:^)
> I logged out and in, and now my drafts are back. The other folder is
> still empty, but I do no longer get the 'Remote id is empty or invalid'
> when selecting it.
>
> Wow, this became longer than I thought. Now I just read that KDEPIM
> 4.6.1 has been released, let's see if this will improve things, I guess
> Gentoo will have it soon. If not, I will delete my account and re-create
> it, with IMAP and the mails not being local this should do no harm.
I'd do the switch to the sqlite3 db and do the recreate only after that,
if necessary. (I really DO hate mysql, with a PASSION!! Because it
obviously HATES me!)
> Maybe I should report some bugs on bugs.kde.org instead of writing here,
> but this would be a lot of reports. Maybe when I have more time than
> now. And then, I wonder if it is really only me seeing these problems.
> Shouldn't the KDEPIM devs see most of them already and hopefully do
> something about it?
Well, to the extent that they might be mysql issues... with the sqlite3
driver being the default now, perhaps they already have. =:^) (Is it
apparent yet how much I HATE mysql!?)
--
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.
