Hi Otto, below the information you requested from my system:
pgrep -x --nslist pid --ns $$ "mysqld|mariadbd" none pgrep -af "mysql|mariadb" 1908 /usr/sbin/mysqld-akonadi --defaults-file=/home/rai/.local/share/akonadi/mysql.conf --datadir=/home/rai/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-rai.bxYrSB/mysql.socket --pid-file=/tmp/akonadi-rai.bxYrSB/mysql.pid The problem has been described here first: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770 I will give an overview: kontact (kmail, kalendar) does not work anymore the akonadi error file shows: org.kde.pim.akonadiserver: DATABASE ERROR: org.kde.pim.akonadiserver: Error code: "1292" org.kde.pim.akonadiserver: DB error: "Incorrect datetime value: '2023-02-22T12:00:36Z' for column `akonadi`.`pimitemtable`.`datetime` at row 1" org.kde.pim.akonadiserver: Error text: "Incorrect datetime value: '2023-02-22T12:00:36Z' for column `akonadi`.`pimitemtable`.`datetime` at row 1 QMYSQL: Unable to execute query" org.kde.pim.akonadiserver: Query: "INSERT INTO PimItemTable (rev, remoteId, remoteRevision, gid, collectionId, mimeTypeId, datetime, atime, dirty, size) VALUES (:0, :1, :2, :3, :4, :5, :6, :7, :8, :9)" org.kde.pim.akonadiserver: Error during insertion into table "PimItemTable" "Incorrect datetime value: '2023-02-22T12:00:36Z' for column `akonadi`.`pimitemtable`.`datetime` at row 1 QMYSQL: Unable to execute query" The culprit seems to be: libmariadb3_1%3a10.3.38-0+deb10u1_amd64.deb which has been updated on my system last Tuesday: 2023-02-21 07:30:26 upgrade libmariadb3:amd64 1:10.3.36-0+deb10u2 1:10.3.38-0+deb10u1 The next morning, kmail was broken. If I understood it well, this was an upgrade from 10.3.36 to 10.3.38. Paul did some research and it seems this commit to be the problem: https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/773fb3e04ffae2b4868876be632fb7244329e7c3 Looking at the diff, I found the following change to libmariadb/libmariadb/mariadb_lib.c: @@ -3879,7 +3881,7 @@ int STDCALL mysql_set_server_option(MYSQL *mysql, ulong STDCALL mysql_get_client_version(void) { - return MARIADB_VERSION_ID; + return MARIADB_PACKAGE_VERSION_ID; } BTW, I'm not using any oldstable stuff. My sources.list looks like: deb http://ftp.de.debian.org/debian/ buster main contrib non-free deb-src http://ftp.de.debian.org/debian/ buster main contrib non-free deb http://security.debian.org/debian-security buster/updates main contrib non-free deb-src http://security.debian.org/debian-security buster/updates main contrib non-free deb http://ftp.de.debian.org/debian/ buster-updates main non-free deb-src http://ftp.de.debian.org/debian/ buster-updates main non-free So it looks to me that whith a security update a functional change came in. If I can help more, let me know. Regards Rai Am 27.02.2023 um 06:46 schrieb Otto Kekäläinen: > Hi! > > Thanks for reporting this. What does the exact process listing look > like on a system that has the Akonadi server running? > > What do these commands below yield on your system? > > pgrep -x --nslist pid --ns $$ "mysqld|mariadbd" > pgrep -af "mysql|mariadb" > > Indeed, the preinst has a section where it tries to stop any existing > servers. This section has been there for years and years, this is > nothing new in 10.11. Maybe it should have an extra check for Akonadi > in particular, or maybe some trigger for Akonadi to restart the > embedded MariaDB it has.
