KDEPIM 4.6 prob^Wimpressions

[Duncan]

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.