KDEPIM 4.6 prob^Wimpressions
1i5t5.duncan at cox.net
Wed Jun 29 21:40:30 BST 2011
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
>> 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
> 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
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
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
> on your system?
$>>kreadconfig --file kmailrc --group General --key folders
(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
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
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
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
>> 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.
More info: http://www.kde.org/faq.html.
More information about the kde