KDEPIM 4.6 prob^Wimpressions
1i5t5.duncan at cox.net
Thu Jun 30 20:37:32 BST 2011
Kevin Krammer posted on Thu, 30 Jun 2011 09:00:45 +0200 as excerpted:
> 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:
>> >> No korganizer, tho it was a forced install with the update
>> > 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
>> Keep in mind that gentoo is a from-sources distro, so it's possible
>> that kmail requires it only for building.
> 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
It's not uncommon to see in a gentoo kde ebuild, that it must extract
(not build, just extract) not only the package it's building from the big
module tarball, but one or more others as well. This is common enough
that the kde eclasses (eclasses are package or functionality specific
procedure libraries common to a number of versions and possibly multiple
packages, in this case kde specific) have special handling for this.
In fact, they have KMEXTRACTONLY, which only extracts the listed subdirs
in the module tarball, without compiling or installing, and KMCOMPILEONLY,
which extracts and compiles but does not install. (KM is short for KDE
module.) There's also KMEXTRA, which does the whole thing, extract,
compile and install, as part of the package.
And indeed, the kmail ebuild makes use of all three, with extract-only
listing akonadi_next, calendarsupport, korganizer, kresources... Compile-
only lists messagecomposer, messagecore... calendarsupport (they aren't
supposed to list a subdir in both, but it appears they did with
calendarsupport... I wonder if that's why they ended up depending on
korganizer to get it to work??). Extra (full build) lists kmailcvt,
But here, for whatever reason (maybe the bug above, calendarsupport
listed in both extractonly and compileonly?), they make korganizer a full
dependency, thus forcing build and install of korganizer first, before
kmail can be built and installed.
FWIW, here if you want to take a look at the actual ebuild (tho it looks
much nicer with syntax color hiliting, this isn't an implication that I
expect it, only if you'd find it interesting to see what an actual
implementation looks like). It's quite high-level and shouldn't be too
complicated for an outsider to get a general picture from, anyway.
And here's the first-level inherited eclass, kde4-meta.eclass, if you
want, tho this has a lot more (basically bash) code. It does further
inherits but you can change the link manually to get them, if desired.
> 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).
Indeed. But adding that ability means the code to create that calendar
entry must be in kmail too, or "borrowed" from korganizer in the form of
a dependency, which is how I'm interpreting this, assuming it's not the
double-specified bug above or simply a mistake of some sort.
> 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).
That's actually a question I had, but hadn't asked (or tried) yet,
whether email searches, etc, now require nepomuk. I'll probably enable
it for that at some point, but the basic functionality that I use
normally, doesn't require it, and there's still a bit of weirdness going
on (every time a mail comes in, I get a warning about two copies... I
suspect I have two different resources pointed at the same place or
something but haven't had a chance to investigate yet... but don't spend
too much time on that unless you happen to have a simple solution or bug
you can point me to, as I'll create a separate thread for it when I'm
ready, given that it's really a separate topic and this thread's
convoluted enough already), so I'm not worried about /extra/
functionality yet, just trying to keep it reasonably simple to deal with
until I'm sure the basics are working correctly.
>> Or it could be as you suggested a bad dep, tho it's newly and
>> deliberately added, so there was evidently something [triggering it.]
> 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.
Based on this subthread I'll probably do a bug-search, and then possibly
ask, if necessary. Plus, I have that double-include, in both extractonly
and compileonly, to look into. I just spotted that as a result of
listing them, above. The comments/instructions at the top of the kde4-
meta.eclass are very specific about not doing that, which makes sense,
given the intended functionality.
>> 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
Unlike the thread OP, I did NOT have a previous kmail2 attempt around.
While my kmail installation is ~a decade old, and thus no doubt has
various cruft (including the original import from OE5, which goes back
another half-decade) in that regard, it was clean in terms of previous
kmail2 attempts as I had been very careful NOT to try such a thing until
>> 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.
> I am not sure if this would not always trigger for people who use just
> IMAP accounts,
Good point. Since I'm all pop3 (plus a machine-local maildir), I tend
not to think about the IMAP folks. Glad someone does! =:^)
> 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
> 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.
That's a reasonable explanation. I found the fact that the migrator log
mentions the pop3 accounts and even the local sysmail account, but says
nothing at all about an error or an unaccountably missing localfolders
rather interesting, but a one-by-one treatment with no overall view of
things, particularly given folks who many not have local storage, only
IMAP, so a missing local store probably in itself isn't incredibly weird,
makes some sense. When the one-by-one got to that point, for whatever
reason, it must have simply detected absolutely nothing, so there was no
error/warning to log, because there wasn't an overall view to raise that
>> >> 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.
>> I think that's what I was using. (Reopening the importer to check...)
> Ah, so you were referring to the mail importer (executable kmailcvt),
> not the migrator (executable kmail-migrator).
Yes. By that point the migrator had finished, failing to detect the
local mail store at all, according to the migrator log which has no
mention of it, no errors, nothing. So I was doing the manual import
But I had assumed that the migrator was simply an automatic trigger for
what would otherwise be a manual import/conversion process, thus more or
less conflating them in my discussion, I suppose. It appears that I
assumed wrong, and they're two entirely separate things.
Thanks for clearing that up. It's very possible that will help with
others down the line, as well.
> Sounds like kmailcvt has a bug in its "import from KMail" tree then.
It would appear so.
> 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.
Well, I'm done with that for now... unless something happens and I end up
having to redo it a fourth time... The "pleasures" of beta! =:^\
But again, that's likely to be a very useful hint for others, when they
>> 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
What I found interesting was that it wasn't /all/ messages unread or all
read, it was /mostly/ unread. If there wasn't support for the index
files at all, they should all be unread (or all read, arbitrary choice of
BTW, in an admittedly rather naive attempt to clear up that two-copies
thing I'm getting on every incoming mail as mentioned above, I decided
that the local-folders resource must duplicate something builtin, thus
triggering the duplicate warnings, so tried to delete it (!! yes, I SAID
rather naive!!). I quickly realized my mistake as the disks churned, but
as I still have the old data, I decided it was probably best to just let
it go and deal with whatever it left me when it was done.
What happened was that as it tried to delete the outbox, etc, kmail
crashed. When it returned, everything was still there (automatically
recreated resource? final commit not made due to crash so it recovered?),
but all the messages were again marked unread.
So I had to go thru and again mark everything read, in all my dozens of
dirs. Then I had to go thru and re-configure all my dozens (50-ish) of
mailfilters to point to valid folders once again.
Oh, well, can't complain as I expected to have to do the imports again as
well, but apparently, someone had the insight to think of someone
accidentally deleting their main local-folders resource, and thus
automatically recovered it. So "all" I had to do was mark everything
read again, and re-point the filters at valid folders, again.
The upside is that I've done the mark-read, re-point filters dance enough
times now that it was a rather faster process this time than the first!
>> 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.
Yes, it does...
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