Thanks to the Qt/KDE team, specially to Maxy who has done most of the packaging and uploading, sid users are now enjoying KDE 4.10.5, including the new KDE PIM stuff that we have held out for the Wheezy release.
I started using KMail2 (inside Kontact) a few days after Wheezy's release, getting it from experimental. And I have to admit that I really like it, just like with KMail1.
But my upgrade did have some bumps on the road, so I'm sharing them here so you can now how I solved them.
Mail import worked as we were waiting: it did work. So it was really useful to hold back Kmail1 until this really worked.
Now, I had a problem with my hard disk: whenever KMail started, it would start accessing it without pause. There where two reasons (for what I could test, I haven't looked at the source to really see if there was some other oddity) for this: I had a nepomuk/virtuoso DB created quite some time ago and initial mail indexing.
The initial mail indexing takes lots of time. For 1GB of DIMAP I had to wait like 5 hours (yes, 5 hours) on a 5600 rpm disk to let it fully finish. My desktop machine, with a faster hard drive, took a little less.
As far as people told me, that should have been enough, but my disk kept crawling. So I remembered someone from the team saying something about people with early-created nepomuk/virtuoso databases will have some speed issues. Mine where more than that, buy trying was worth the shot.
I had nepomuk disabled since I tried it the first version due to this exact problem. So I closed my KDE session and removed the nepomuk/virtuoso data:
rm -r ~/.kde/share/apps/nepomuk/
Then I logged back in KDE and waited (again) the 5 hours to let nepomuk re index my mail, this time totally finishing after 5 hours. Starting from that point, I get some one or two minutes of disk trashing some times I log in (not always), but it's actually not that bad. And I heard that in KDE 4.11 this has been improved a lot, so I should see a better behavior from that point on.
Please understand that this was my trial-and-error fix, it may be possible that someone comes with a better solution :-)
I've likewise been having some interesting issues since upgrading to KMail2 since it's come to Debian Sid. The first thing I noticed was that the system was using a lot of CPU time for hours, and that the process using the CPU was MySQL. I don't like having to use MySQL and wanted to switch to PostgreSQL, since there's an akonadi-backend-postgresql package available.
ResponderEliminarUsing the PostgreSQL akonadi backend with PostgreSQL 9.1 isn't simple to set up though; first a "ROLE" must be made for each user by first connecting to Postgres via the 'postgres' user, creating a role, then creating a database for that user to use. After all that, things still go horribly wrong; Akonadi is able to start and use PostgreSQL, and it _looks_ like KMail2 is able to import all of the email that I have under IMAP, except it does so _immensely_ slowly and continuously spits errors to the PostgreSQL 9.1 log.
After about two days of indexing, KMail2 would only show me about 200 emails (out of thousands) that I have in my main IMAP account, and I have a 650 MB postgresql log containing about 9 million lines of:
2013-07-16 17:51:52 EDT ERROR: invalid input syntax for type bytea at character 24
2013-07-16 17:51:52 EDT STATEMENT: EXECUTE qpsqlpstmt_7d ('\SEEN')
2013-07-16 17:51:52 EDT ERROR: invalid input syntax for type bytea at character 24
2013-07-16 17:51:52 EDT STATEMENT: EXECUTE qpsqlpstmt_7d ('\SEEN')
...
I had to switch back to using the MySQL akonadi backend. However when I try to send an email after doing this, the first attempts fail until logging out and back in again (#717040). After logging out/in sending email now works, but sometimes the sent email doesn't show up in the correct "Sent" folder that I've set, and instead shows up in "sent" under Local Folders.
I'm also repeatedly getting prompted for entering in the password for a couple of the IMAP accounts, which is pretty annoying. I'm trying to change KWalletd settings to help this. Also KMail2 now _requires_ Nepomuk and Strigi indexing of email in order to use the Search functionality, where KMail v1 didn't require that. :-/
I'm going to try to get used to this (and continue to try to test switching to PostgreSQL in a VM instance). At least I've gotten Kmail2 (mostly) working again in the meantime.
I think you may have been hit by #716922.
EliminarBut as far as I know, upstream really recommends using virtuoso for this.
I've been told that upstream suggest MySQL, not virtuoso. My bad.
Eliminar