KDEPIM 4.6 prob^Wimpressions

[Duncan]

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

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, 
ksendemail... ontologies...

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.

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/kde-base/kmail/
kmail-4.6.0.ebuild

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.

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/kde4-
meta.eclass

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

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

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

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

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

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

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

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

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.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.