Accidentally hit shortcut to send mail before it was ready. Here is the full version.
Hi Philippe, hi. Please do not use HTML. Additional work for plain text formatting when I reply to you. phil-deb1.mer...@laposte.net - 04.03.25, 15:27:11 Mitteleuropäische Normalzeit: > Faced with slowdowns sometimes reaching almost a minute of very > unpleasant operation of Kmail which I perhaps wrongly attribute to > Akonadi and its Mysql Do you use POP3 and local maildir storage? I had these as well. With SQLite3 it is much better, much faster. But occasionally I still have such a strange pause. > database, I read in this list that Akonadi with a Sqlite3 database is > much faster. I would like to migrate my Mysql database to Sqlite3. the > planned procedure not working see Debian Bug 1098891# not wanting to > abandon Kontact I have been an old user since 2003, 22 years. I thought That is even longer than I am using it. > of a solution, I would like you to tell me what you think. > Remove pim, kontact, kmail, akonadi. That is the brute force approach. > Delete the akonadi Mysql database. > > Reinstall Kontact, Kmail, Pim, akonadi. > > At this time configure akonadi with Sqlite3 as a database. > > In Kontact import messages that were stored in a directory. I'd not really import messages. From what I read from user users this process is error prone and slow. But of course your mileage may vary. For a very long time I did not try to import a lot of mails at once. Sometimes I imported a small mbox file with a few mails. That worked. But not a complete structure. What may work is using the PIM data exporter. You could try it. Whatever approach you choose: *Make* *A* *Backup* *First*! Of your *complete* home directory, while Akonadi is not running. Better be safe than sorry. Then you have a second attempt if need be. Likely all in all (way) faster, but it will require some knowledge on how Akonadi works is the following approach – *read all of it*, before any attempt to do it in this way: It is enough to point a maildir resource to the location where the old mails are… or… move them into the new location. It will pick up mails from there. However in case you just remove the Akonadi MySQL database, the maildir resource configuration is not lost. So it will pick up your old mails automatically anyway. But wherever you reference mail folders in KMail configuration, including filters these references are very likely to be wrong. They are by database ID and that will change. I already described that I migrated without the migrator. I basically just deleted the old database and switched configuration in ~/.config/akonadi/akonadiserverrc to SQLite: % cat .config/akonadi/akonadiserverrc […] [%General] Driver=QSQLITE I think that will be enough. It will automatically choose the location of the database file on first start. *Before* that however I exported all my local mail filters to a file. Then I deleted those local mail filters from KMail configuration. I kept all other configuration. I stopped akonadi: "akonadictl stop". I removed old database. I did not remove and reinstall KDEPIM. It is not necessary. I changed to SQLite3. I did "akonadictl start" in a command line to see whether database creation works and so on. I started KMail. I reimported all local mail filters. That way KMail automatically picked up the right folders for them by name (instead of database ID). I reviewed every reference to a folder in KMail configuration and changed wrongly configured folders everywhere. Like within my identities, POP3, IMAP and SMTP configuration. That worked for me. I do not really have the time to give support. But these were the basic steps I did. I also wrote about it before already. > It's a shame that I have to do this gymnastics because the planned > procedure is blocked from the start and in my opinion the specialists > that you are will have no difficulty in correcting bug 1098891#. Sorry, that is not how it works. Debian Qt/KDE developers package KDEPIM. Many of them are not upstream developers. If you read my other mails carefully, you know that I already suggested to check whether there is an upstream issue and if not report one. Again and again and again: Most of Debian/Ubuntu and upstream developers, if not all of them are doing all or most of this work in their free time. For me that means: I am not in a position to place demands on them. I am not the one to decide on what they should do in their free time. The bug may be easy or not so easy to fix. It may be difficult to fix for developers in case it would not happen in their system. Who knows? But everyone could help. By checking for upstream bug report, doing one if there is none and having installed most recent versions in Debian – they are up to date at the moment –, and providing necessary details, including ideally a GDB backtrace of the crash. So if you like to see this fixed, you can see how you can invest some of *your* time to help someone else to help you. As I migrated already and there is quite some other places where I contribute at the moment and I need to focus on some topics at a time not to overwhelm myself, I am not willing to invest more time into this topic at the moment. I invested some of my time to get it sorted by myself back then. Hope my above explanations may either help you to do the migration with KDEPIM data exporter/importer or in an not so official, but hopefully working way, and/or find a way for yourself to help upstream to help you. Best, -- Martin - please no carbon copy to me
