KDEPIM 4.6 prob^Wimpressions

[Duncan]

Alex Schuster posted on Tue, 28 Jun 2011 23:24:58 +0200 as excerpted:

> I did the big KDE 4.6.3 -> 4.6.4 upgrade. Along came the change to
> KDEPIM 4.6. I feared for the worst, and indeed, it didn't work too well.

Your experience mirrors mine to a large extent.  AFAIK we're both on 
Gentoo.

Put it this way, I can see why they were reluctant to release kdepim 4.6, 
even years after the intended initial release (it was supposed to be 
ready for kde 4.0, originally, from what I've read) and over a year plus 
after the "slid"-but-still-only-address-book-ported release of 4.4.  I 
had been hoping all the extra time had it now fully stable, conversion 
tested, etc, but honestly, while it's *NOT* as bad as early kde4, at 
least this feels like beta software, not alpha, and I've NOT seen anyone 
INSISTING that it's stable and ready for normal use when plain experience 
demonstrates otherwise, and forcing upgrades due to dropping support of 
the previous, yet, as happened with kde4, it *DOES* still feel beta, even 
after all these years trying to make it work.  But in a way that's OK, at 
least here, as I've always considered myself an early adopter and 
routinely do adopt upgrades at the beta stage.

Here, I don't use the kontact suite (nor have kontact itself installed) 
at all, only some of the separate bits.  No korganizer, tho it was a 
forced install with the update, no kalarm, no knode (I run pan instead).  

I do run akregator, which apparently has NOT been "akonodified" (yet?), 
and I do, at least for the moment, run kmail (I eventually got the 
mailstore upgrade done to my satisfaction but I'm honestly wondering if 
it's worth the continuing hassle of akonadi), with a local "sysmail" 
maildir and with a number of pop3 remote accounts on two different 
servers, no imap at all.

The first-run kmail backing store upgrade went entirely haywire.  It 
warned that the import might take awhile, then took almost no time at 
all, as if it couldn't actually see the old mail location at all, and I 
ended up with an entirely empty set of default folders, nothing more, 
altho the account information itself DID apparently transfer OK, and of 
course the address book was still there as it had already transferred 
with 4.4.

The problem, it seems, was that I had kmail (1) set to use a different 
directory for its mail.  What?  After ALL this extra time, much of it 
spent, we were told, on getting the conversion right, it couldn't do a /
simple/ thing like read the old kmail config and see where the local 
mailstore was?  This does NOT seem like the smooth experience I expected 
after a year's extra delay, much of it focused on the converter.  More 
like the experience one might expect from a beta.  Oh, well, I'm used to 
running betas and dealing with this sort of stuff, no problem, if it can 
import properly once I point it at the right place.

But since it hadn't imported it anyway and because there was a warning i 
the importer about reimporting the in-place running working dir possibly 
creating an endless loop (that's how I interpreted it anyway), I took the 
step of moving the old mail store off of home, to my large media and 
backup partition, leaving more room in home and an empty previous working 
location, just in case.  That did seem to make things easier, or at least 
less confusing for me, trying to keep straight which was the new data and 
which was the old data and ensure that I wasn't going to somehow trigger 
this loop.

Meanwhile, I had deliberately not entered my kwallet passwords so the 
remote pop3 accounts, which it DID import properly, couldn't download new 
messages to local storage that wasn't setup correctly yet.  With about 
six accounts spread over two servers, the periodic kwallet popups and 
manual entry popups when I canceled that, for each of them, got 
irritating, but there wasn't much I could do about it as I wanted any 
incoming mail left safely on the remote server until I was sure the local 
storage wasn't screwed up.

The second (maildir) import attempt went better, but crashed half way 
thru, apparently because some of the old mail folders were in mbox 
format. (I had tried switching to maildir some years ago, and that was 
the default, but found no way to switch the default folders as I couldn't 
delete the old mbox folders in kmail after I'd copied everything to the 
new maildir folders, so the defaults stayed as mbox, and continued to 
accumulate some mail, altho filters moved most on receipt to sorted 
maildir folders.  And, I had missed a couple non-defaults as well, 
including my family mail folder, which was still in mbox format.)

The *$#!$& maildir importer was trying to import the mboxes, including 
the huge family mbox, as *SINGLE* *HUGE* *MULTI-GIG* mails, one for each 
mbox!!

Again, that sort of mistake is acceptable for a beta, but NOT what I 
expected from an importer that had been the focus of a year's delay, to 
"get it right", ESPECIALLY when they're importing their own previous data 
store and *KNOW* that the previous version could well have a mix of mbox 
and maildir format, due to switches between the default formats over the 
years and the fact that it continued to work with both.  Further, a 
situation like mine where someone had tried to convert to maildir but 
couldn't delete the old default mboxes when kmail was running, so 
couldn't convert at least THOSE dirs, could certainly have been predicted.

Meanwhile, akonadi/kmail was for some reason giving me warnings (similar 
to those you saw) about missing folders for some of the stuff, even when 
I could see them plain as day, browse them, etc, in kmail!

But just as I feared after seeing the warnings, quitting kmail and 
akonadi, then restarting, often left the things disappeared.

Again, extremely rough beta quality.  DEFINITELY not the sort of 
experience a regular user should need to worry about, and DEFINITELY not 
the sort of experience one might be lead to expect knowing they spent an 
extra YEAR PLUS focusing on this stuff.

One can only shudder at what the experience must have been like BEFORE 
the extra year of work... <shudder>

Meanwhile, after some manual rooting around viewing the old backing-store 
in a file manager and various files, particularly the mbox files, in a 
text editor, I figured out that the maildir importer was indeed trying to 
import the mbox files as single HUGE mails, figured out which ones they 
were and deleted the huge "mails" that it had managed to import into 
kmail, and used the mbox importer to try to import them correctly.

Then I tried moving the kmail folders from their import locations to 
where I really wanted them in kmail, resetting the filters to match the 
new locations, etc.

Then I restarted kde, and found out much of the work disappeared on 
restart, apparently due to those missing folder warnings I had been 
getting.

But I'd evidently learned enough in the process that try #3 went far 
better.  After deleting the mess and restarting kmail/akonadi, and 
manually moving the mbox files out of the maildir structure in the old 
backing-store, so I could import the maildirs without the importer trying 
to treat the mboxes as a single HUGE email, then separately import the 
mboxes, it worked.  This time without actually moving them to where I 
wanted, yet, I shut kmail/akonadi down and restarted it, THEN moved the 
dirs around, shut down and restarted kmail/akonadi again, and pointed all 
the filters at the correct folders, shutdown/restart again, several times 
now to make sure it's working reproducibly without errors, *THEN* tackle 
the remote accounts.

The remote accounts had their own problems.  Apparently kmail and akonadi 
were fighting over who got and stored the passwords, which I had to 
reenter in kwallet as the akonadi setup couldn't simply use or auto-
import the existing kwallet stored username/password info.

Eventually, I figured out more or less by trial and error that things 
worked better if I ignored the mail password queries and setup the 
accounts first in akonadi.  One would THINK somewhere in the setup 
there'd at least be a dialog explaining that setting up akonadi's 
accounts first would work better, ESPECIALLY after all the extra time 
they've had to work on this and get it right, but... well, I'm a beta 
testing type of guy, so I could and did cope with it.  But I shudder to 
think about an ordinary user trying to deal with all this!

Meanwhile, even after getting everything setup apparently correctly, the 
thing **STILL** can't manage grabbing mail right the first time after a 
reboot or kde or akonadi restart.  The problem appears to be that akonadi 
isn't designed to properly handle two remote pop3 servers at the same 
time.

So when I first grab mail, it pops up the kwallet password dialog as 
expected, and I put in my password.  It syncs the (one account on) one 
pop3 server and local sysmail, but the multiple accounts on the second 
pop3 server sit there, if I let them, for hours, syncing slider going 
back and forth, back and forth, but nothing else happening.

If I hit the checkmail again, or when the periodic check comes due for 
the whole set, it blocks, waiting for those frozen mailchecks that never 
complete.

I must manually cancel the frozen mailchecks and trigger a new global 
mailcheck, after which I get a SECOND kwallet password popup, which if I 
enter my kwallet password, now grabs the password info for the accounts 
on the SECOND pop3 mail server and checks them successfully.

Only after performing this kabuki dance at EVERY kde/akonadi restart, 
putting in the kwallet password to get the passwords for the accounts ont 
he first pop3 server, opening kmail and canceling all the mail fetches 
for the second pop3 server accounts that will never get anywhere because 
they're waiting on a kwallet dialog that never appears, manually hitting 
fetchmail again, and entering the kwallet password a second time so 
akonadi/kmail can access the accounts on the second pop3 server, does it 
all work correctly.  I must do this EVERY time I restart the computer, kde 
or akonadi.

And while I'm getting no errors now, and mail seems to come in, the whole 
experience, all the bugs, all the beta-quality stuff and missing 
attention to details triggering stupid stuff like the kabuki dance I have 
to go thru every time I restart kde/akonadi, even after YEARS of work, 
all of that, has left me wondering at the stability of the whole setup.  
What's so wrong with plain maildir and mbox, after all?  Both are common 
standards used across many clients, and it certainly seemed more stable 
with that, than all this does, even after YEARS of work to "get it right".

And I've left out all the stuff about properly configuring akonadi 
resources (what you appear to be dealing with), etc, along the way.

Oh, and the fact that despite the fact I don't need it, I now have 
korganizer, and despite the fact that I don't need nepomuk calendar/alarm/
search integration and in fact turned nepomuk off as a result, now I get 
multiple notifications at every boot about stuff I deliberately turned 
off because I don't need or want it, with no visible way to turn off the 
stupid warning notifications for stuff that's useless to me!

I really, honestly, have a hard time believing it's all worth it.  I had 
wondered about switching from kmail before, with all this stuff on the 
horizon, but despite the minor hiccups switching to the akonadified 
addressbook, for the most part it still "just worked", without getting in 
my face, and I decided I should at least give the new stuff a try, once 
it came out.

Well, I've given it a try now, and I honestly can't see how all that 
hassle was worth it!  Plus, I'm now living in constant fear of the 
dreaded akonadi can't-find-the-folder errors and the like, wondering if 
my mail's actually safe, or not.  If it can lose whole FOLDERS, if the 
converter can't tell the difference between mbox and maildir and imports 
mbox as single HUGE mails as a result, if it can't ask ONCE for the 
kwallet password, or at LEAST ask twice in a row if it must, without me 
having to manually cancel about a half-dozen mailchecks that will never 
complete and retrigger a mailcheck so I can enter the kwallet password a 
second time... even after an extra year plus to get it right... what sort 
of faith can I have that it's not going to lose mail on me?  Answer, no 
faith.  At least the previous setup "just worked", only needed one kwallet 
password popup, and had a demonstrated reasonable reliability I didn't 
have to worry about.  That's definitely NOT the case with this new, 
"fancy" thing!

Which leaves me wondering just what mail client I should think about 
trying next.  Why couldn't they have left what was working just fine, 
well enough alone?

Will I still be on kmail a year from now?  I honestly don't know.  
Despite the forces of inertia now that it seems to be at least sort-of 
working, I'd put the chances lower than they've ever been before, at 
perhaps 40-50%.  And if there's just one major "event"...  The question 
I'm asking myself is will it take such an "event"... or I be proactive 
and get off the platform, before such an "event" happens?

It's really, **REALLY** a shame that it has reduced to THAT level, from 
what kmail /was/ and still could be, a quite good solution for me 
(possibly because I only do pop3, no imap, I know) that I had no reason 
to contemplate moving from, but what can I say?

I'm *NOT* looking forward to looking for another mail client, but it 
seems I'm being forced into it, much as MS forced me into switching to 
Linux with the line they crossed with "anti-features" in eXPrivacy.  Of 
course, I can only hope the result will be so good!  Certainly today, I 
can only thank MS for giving me that final push toward the land of 
freedomware!  If I'm lucky, perhaps in a year or two I'll be saying the 
same about the push the kmail/kdepim guys gave me toward whatever new 
mail client I might find. <shrug>

Or maybe I'll tempt fate and stick around, and if I'm lucky, no such 
"event" will happen, and the kmail experience will gradually improve once 
again, much as has the kde experience.  The question is, am I willing to 
tempt fate on whether an "event" will happen, or not?  Because that's 
exactly the level of faith I have in the stability of the current setup.  
Were it not for that, I'd certainly stick around for it to get better, 
just as I did for kde4 itself, and I expect it will, just as it did for 
kde4.  But even then, I'm not sure the stability is there; even if they 
fix all the UI issues and introduce lots of fancy new features, an 
"event" could yet happen, a year, two years from now.  And honestly, I'm 
*NOT* impressed by how kmail/akonadi/the-converter handled the "events" 
that happened in the conversion, when I had no new mail to get lost in 
the process, as I will a couple years from now.

I guess time will tell...

-- 
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.