KDEPIM 4.6 prob^Wimpressions

[Kevin Krammer]

On Wednesday, 2011-06-29, Duncan wrote:
> Kevin Krammer posted on Wed, 29 Jun 2011 10:53:11 +0200 as excerpted:
> > On Wednesday, 2011-06-29, Duncan wrote:

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

It is not very common that two applications have a dependency on each other, 
but being in the same module that could have happened for some reason.
It is just weird that this would be introduced now since the move to Akonadi 
is also about decoupling applications from some of their low level 
functionality, so e.g. KOrganizer can send mail without having to go through 
KMail or vice versa (KMail creating a calendar entry from a received 
invitation without having to go through KOrganizer).

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

No, this is unrelated. Neither does the calendar/alarm support for 
Akonadi/Nepomuk integration depend on KOrganizer, nor is the Akonadi/Nepomuk 
cooperation limited to calendar/alarm.

Actually the probably most used form of indirect Nepomuk usage is address book 
searches, e.g. for expanding distribution list or checking sender addresses 
against the addressbook in mail filters.
With this new version of KMail it will also be of interest for people who want 
to search for email ("search in folders" or based on matching criteria, not 
for the quick filtering thing on top of the message list).

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

It could indeed be a build dependency, though I am not sure if this would even 
be intentional.
Maybe someone at Gentoo know why they had to add this.

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

The two XDG variables shouldn't matter at this point, this is a "KDE internal" 
procedure.
And KDEHOME is handled by KDE's config framework internally (and correctly as 
your kdereadconfig output shows).

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

I didn't mean to imply that it was a system setting, I meant what is the 
output you are getting when you execute the command.
Of course, with KDE's config capabilities of merging config entries from 
different locations, this could actually be a global setting (e.g. 
"$HOME/Mail"), but in this case it is usually user local.

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

If kreadconfig returned the correct value than this is what the migrator will 
read as well (same keys used with the same API).
A cause of error could have been a stale kmail2rc from a previous attempt.

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

No, I don't think this is likely.

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

I am not sure if this would not always trigger for people who use just IMAP 
accounts, but ideally it could check for such anomalities in some way.
Unfortunately the migrator had initially been written to work like the ones 
for contacts and calendar which are much simplier in all aspects.

There was no time to rewrite the mail migrator from ground up to first check 
the whole setup and base decisions on that, so it works itself through the 
account setup one-by-one, reaching the local folders last.

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

Ah, so you were referring to the mail importer (executable kmailcvt), not the 
migrator (executable kmail-migrator).

Sounds like kmailcvt has a bug in its "import from KMail" tree then.

For a manual approach you might want to consider creating a KMail Folders 
resource (mixed_maildir) instead and pointing it to the KMail mail root 
directory (~/config/mail in your case).
This is what the migrator would do.

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

I am not sure if the importer has support for KMail index files. It probably 
should but that functionality had been buried deep inside KMail before and was 
only extracted for the creation of the MixedMaildir resource.

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

Sounds very much like a bug or limitation of the importer to me.
Don't know anything about that application short of that it does exist.

> LOL.  Reminds me of the Steven King story, the Langoliers.

Hehe, haven't seen that one in a long time. Didn't even know it was based on 
something by Steven King, certainly explains a lot.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20110630/929ec053/attachment.sig>
-------------- next part --------------
___________________________________________________
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.