KDEPIM 4.6 prob^Wimpressions

[Duncan]

Kevin Krammer posted on Wed, 29 Jun 2011 10:53:11 +0200 as excerpted:

I expected you might reply to this, Kevin, as I know you're around and 
worked on trying to get it working right.  No personal offense intended, 
of course, I just reported my experience.

But I'm glad someone is investigating.  Perhaps it'll result in a better 
experience for the next set of migrators.

> On Wednesday, 2011-06-29, Duncan wrote:

>> [Wonko/Alex's] experience mirrors mine to a large extent.  AFAIK
> we're both on Gentoo.
> 
> Quite likely, I think this is the only distribution which has enabled
> the transition in its main repositories so far.

I covered this in another post, but briefly, while it's in the main repo, 
it's ~arch keyworded, testing, comparable to cooker/rawhide/etc in other 
distros, and may well remain that way for some time.  Gentoo has both 
arch-stable and arch-testing, aka ~arch, in the same tree, but uses a 
keywords mechanism (denoted by the little ~ in front) to keep them 
separate.

>> 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).
> 
> Sounds like a packaging problem, none of the other applications depend
> on Korganizer.

korganizer is listed as a kmail-4.6.0 dependency, I didn't have it before.

Keep in mind that gentoo is a from-sources distro, so it's possible that 
kmail requires it only for building.  (gentoo does make the distinction 
between build-time and run-time deps, but I force build-time deps to 
remain installed after build, to avoid having to reinstall again for the 
next update.)

I'm guessing that it has to do with the same reason akonadi keeps 
complaining about my having nepomuk disabled, even tho as best I can see, 
it's mainly the organizer/alarms/etc functionality it wants, and I don't 
need that.  kmail probably links against that same akonadi functionality, 
so it must be there at build-time and possibly run-time, even if it's not 
actually used.

Or it could be as you suggested a bad dep, tho it's newly and 
deliberately added, so there was evidently something in the deps that was 
failing without it, perhaps just because the gentoo/kde folks didn't 
figure out how to link it to a USE flag option just yet.

>> The problem, it seems, was that I had kmail (1) set to use a different
>> directory for its mail.  [It] couldn't do a /simple/ thing like read
>> the old kmail config and see where the local mailstore was?
> 
> Of course the migrator does exactly that. It reads the folders entry in
> section General of the KMail configuration and uses this location for
> local folders.

> If the entry is not present (normal KMail setup), it will use the same
> default value KMail does, e.g. $HOME/.kde/share/apps/kmail/mail
> 
> What's the output of kreadconfig --file kmailrc --group General --key
> folders
> 
> on your system?

$>>kreadconfig --file kmailrc --group General --key folders
~/config/mail

(It probably doesn't matter here but just in case, XDG_CONFIG_HOME points 
to ~/config and XDG_DATA_HOME to ~/config/local/share for my user.  
KDEHOME is ~/kde .  I don't like hidden dirs, as at one point "before the 
turn of the century" and my subsequent switch to Linux so on MS, I 
deleted an "empty" dir that wasn't so empty after all!)

FWIW, while you imply it's a system setting (you ask what the result is 
on my system, not for my (normal) user), it appears to be a user setting, 
as my admin user (which never runs kde) has it unset, while my normal 
user has the results above, ~/config/mail.

And ~/config/mail is exactly where it was, too.  As I said in the 
previous post it's no longer there as I moved it to my media/backup 
partition, but it there for the first, automatic, import attempt. I only 
moved it after the auto-convert/import failed and I was getting ready to 
try again, manually.

On the remote chance that it's related...

My system is a(n older) dual Opteron dual-core, so four cores but as dual-
dual not as quad.  Further, my main partitions including / and /home are 
on quad-spindle kernel/md RAID-1.  Further, I have a particular program 
(pan) that starts with the kde session, that reads in probably about a 
gig of data as it starts up and creates its news-message threading tree.  
(I imagine you might be sympathetic, working as you do with mail 
messages, it uses a flat-file format the performance implications of 
which of course kmail is trying to avoid with this whole akonadi thing, 
so probably understand the stress that puts the i/o system under as it 
starts).

Plus, I'm running pre-release 3.0 git kernels.

So I wonder if it's possible, given the parallel access implications of 
both 4-core SMP and 4-spindle RAID-1, and the heavy I/O stress of both 
completing the kde startup and initializing pan's gig-of-data-in-small-
files, plus perhaps something in the pre-release kernel, that some sort 
of race condition developed, and either the config lookup or the actual 
check of the filesystem for that directory returned null at the point the 
migrator attempted to check it.

Of course if it was pre-release kernel related, there's little chance of 
duplicating or of anyone else running into the problem, but might it be 
possible to double-check, if the value returns as unset, or especially if 
it's set, but then the system returns the directory pointed to as not 
existing?

I had chalked it up to only checking the default case, but as you've 
confirmed that it actually checks to see if the location is set, such a 
race condition is the next point of plausibility I can come up with, as 
remote as the possibility seems.

Or, if the auto-migration seems to have found no email dirs, just the 
account info, mail filters, etc (which did migrate), perhaps a button to 
try again.  Actually, when it went so fast, I sort of expected it to give 
me a try again button, or at least a warning that it couldn't find the 
old mail store, but it didn't.  Logically, there's probably something 
wrong if an existing setup has a half-dozen accounts setup and several 
dozen filters (thus indicating rather heavy usage), but no actual mail 
data.  Some sort of "this doesn't look right, do you want me to try 
again" dialog, seems reasonable.  Or failing that, at least a warning 
that accounts and filters were detected, but no data, so the user may 
wish to run the importer manually to try again, pointing out where in the 
menu it's located, etc.

>> 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!!
> 
> Can you elaborate what kind of importer tool you used here?
> One part of what the mail migrator tool does is to use a "KMail Folders"
> resource (mixed_maildir) to accomodate old KMail folder structures with
> mbox folders.
> (this resource has also read-only support for KMail1's index files,
> allowing it to attach meta data to message objects, e.g. tags, certain
> status flags).

I think that's what I was using.  (Reopening the importer to check...)

I rejected the top entry, kmail archive file, as that seemed wrong -- I 
didn't have an entire tree in a single archive file.

I rejected mbox initially as I was looking for something kmail specific.

All the others looked clearly wrong, except for kmail maildirs and folder 
structure, which is what I used.

It DID import the maildirs correctly, altho /most/ (but not all, which 
was strange...) of the messages showed up as unread, so that index file 
support apparently didn't work quite as intended.  

But then it crashed.  By that time I had switched to something else while 
letting the importer do its thing, so I didn't see what it was actually 
doing when it crashed, but a comparison of the tree as seen in a file 
manager as compared to that seen in kmail, suggested that it was on one 
of the mboxes.  And kmail would crash when I tried to open (or even 
select) one of the huge "emails".

By checking one of the other huge "emails", which it /had/ imported 
without crashing, I discovered that it was actually a whole bunch of 
mails, with all but the first one appearing as part of the first one.

And by checking the old filesystem tree, I found that these huge "emails" 
were entire mboxes, with the headers of the first message in the mbox 
being what kmail was displaying for the headers of the huge combined 
message.

BTW, I omitted mention of this bit in my previous mail, but when I moved 
the mbox files out of the way before the third import attempt (the second 
manual one), I missed one, which sure enough, got imported as a single 
huge mail, once again.  Fortunately, it wasn't the one that caused the 
crash, so the import of the maildirs completed successfully.  I then used 
the mbox importer to import them, and when one was missing, found that I 
had missed moving it.  Sure enough, kmail was showing it as a single huge 
mail, again.  But I was able to delete it and import the mbox, which 
worked fine.

>> 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.
> 
> Weird thing about time is that it advances continually while time
> available to individuals for certain tasks does not.
> This mistery has found its way into natural languages in form of phrases
> like "I don't have (enough) time for that" inspite time constantly
> making itself available.
> Scientists have not yet found where this time is drained to before
> reaching the expected recipient, though theories say it is dried, rolled
> into cigars and smoked by leechers elsewhere.
> 
> No, wait, that was fiction. Momo IIRC.

LOL.  Reminds me of the Steven King story, the Langoliers.  I don't 
normally do horror but do enjoy science fiction, and Steven King is 
enough of a SciFi crossover (presenting his idea of the down-side of 
science) that I do read/watch a bit of his work, occasionally.  As it 
happens, that was one of the last TV miniseries I caught before I ended 
up dumping TV for good some time late in the last century, before I 
switched to Linux, so the idea of something (the langoliers in his story) 
following behind the forward roll of time and eating up the dead earth 
left behind by the passing of time... has stuck with me as one of those 
last experiences, even tho I watched it over a decade ago, now, as I 
said, late last century. 

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