kmail migration akonadi database Mysql to Sqlite3
Hey, Faced with slowdowns sometimes reaching almost a minute of very unpleasant operation of Kmail which I perhaps wrongly attribute to Akonadi and its Mysql 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 of a solution, I would like you to tell me what you think. Remove pim, kontact, kmail, akonadi. 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. 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#. Philippe Merlin
Re: Qt 6.8.2 incoming
Martin Steigerwald - 01.03.25, 12:49:06 Mitteleuropäische Normalzeit: > Idea is to get in Qt 6.8.2 quickly, but it will take some time for the > build servers to do their job. Also there are dependencies which need to > be rebuilt against new Qt. One machine updated just nicely. Others will follow, but more in the late afternoon time. Thanks for bringing Qt 6.8.2 in, in time for Trixie! Best, -- Martin - please no carbon copy to me
Re: kmail migration akonadi database Mysql to Sqlite3
Hi Philippe, hi. Please do not use HTML. Additionally 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 me. > 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. It is enough to point a maildir resource to the location where the old mails are… or… move them into the new location. 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. However… 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/ 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. 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. I reviewed every reference to a folder in KMail configuration. 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 them, if not all of them are doing all of this work in their free time. For me that means: I am not in a position to place demands on them. But I could help. By checking for upstream bug report, doing one if there is none and I have 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. Best, -- Martin
Re: kmail migration akonadi database Mysql to Sqlite3 (complete mail)
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, y
Re: Qt 6.8.2 incoming
On Tue, Mar 4, 2025 at 9:00 AM Martin Steigerwald wrote: > > Martin Steigerwald - 01.03.25, 12:49:06 Mitteleuropäische Normalzeit: > > Idea is to get in Qt 6.8.2 quickly, but it will take some time for the > > build servers to do their job. Also there are dependencies which need to > > be rebuilt against new Qt. > > One machine updated just nicely. Others will follow, but more in the late > afternoon time. > Thanks, Martin, for all the hints. Here, adduser causes some CRITICAL post-installation problems with dbus-system-bus-common, colord, etc. https://bugs.debian.org/1099470 Workaround: root# apt install adduser=3.137 -y --allow-downgrades Best regards, -Sedat- > Thanks for bringing Qt 6.8.2 in, in time for Trixie! > > Best, > -- > Martin - please no carbon copy to me > >
Re: Qt 6.8.2 incoming
Sedat Dilek - 04.03.25, 21:32:59 Mitteleuropäische Normalzeit: > On Tue, Mar 4, 2025 at 9:00 AM Martin Steigerwald wrote: > > Martin Steigerwald - 01.03.25, 12:49:06 Mitteleuropäische Normalzeit: […] > > One machine updated just nicely. Others will follow, but more in the > > late afternoon time. > > Thanks, Martin, for all the hints. You are welcome. > Here, adduser causes some CRITICAL post-installation problems with > dbus-system-bus-common, colord, etc. > > https://bugs.debian.org/1099470 > > Workaround: > > root# apt install adduser=3.137 -y --allow-downgrades Thanks for this. What often comes in handy in such cases: Use apt-listbugs. Usually I just let it pin the packages in case I think it might be affecting me. It also unpins them automatically again once the bug is closed. Of course if you are really quick with updating and an issue with severity of at least "serious" has not been reported, you still get to keep the bug. apt-listbugs and apt-listchanges are two tools I'd install on every unstable/testing machine. Best, -- Martin - please no carbon copy to me
Re: Qt 6.8.2 incoming
On Tue, Mar 4, 2025 at 9:46 PM Martin Steigerwald wrote: > > Sedat Dilek - 04.03.25, 21:32:59 Mitteleuropäische Normalzeit: > > On Tue, Mar 4, 2025 at 9:00 AM Martin Steigerwald > wrote: > > > Martin Steigerwald - 01.03.25, 12:49:06 Mitteleuropäische Normalzeit: > […] > > > One machine updated just nicely. Others will follow, but more in the > > > late afternoon time. > > > > Thanks, Martin, for all the hints. > > You are welcome. > > > Here, adduser causes some CRITICAL post-installation problems with > > dbus-system-bus-common, colord, etc. > > > > https://bugs.debian.org/1099470 > > > > Workaround: > > > > root# apt install adduser=3.137 -y --allow-downgrades > > Thanks for this. > > What often comes in handy in such cases: > > Use apt-listbugs. Usually I just let it pin the packages in case I think > it might be affecting me. It also unpins them automatically again once the > bug is closed. > > Of course if you are really quick with updating and an issue with severity > of at least "serious" has not been reported, you still get to keep the > bug. > > apt-listbugs and apt-listchanges are two tools I'd install on every > unstable/testing machine. > Thanks, again. I have installed apt-listbugs. The issue with adduser was NOT obvious as my last apt full-upgrade was on 21-Feb-2025 and I had to download 1.2GiB of upgraded packages. My first view was on DBUS version 1.16.2 (messagebus - see /var/lib/dpkg/info/dbus-system-bus-common.postinst) - afterwards I saw colord causing issues, too. BAD timing. BR, -sed@-
Re: Qt 6.8.2 incoming
On Tue, Mar 4, 2025 at 10:10 PM Sedat Dilek wrote: ... > BAD timing. > adduser (3.144) unstable; urgency=medium [ Matt Barry ] * Clean up system account logic. Thanks to Michael Musenbrock and Vincent Lefevre (Closes: #1099470, #1099477) -- Marc Haber Tue, 04 Mar 2025 20:57:13 +0100 -sed@-
