On 2023-02-22 17:03, Otto Kekäläinen wrote:
Seems Akonadi tried to execute
"INSERT INTO PimItemTable (rev, remoteId, remoteRevision, gid,
collectionId, mimeTypeId, datetime, atime, dirty, size) VALUES (:0,
:1, :2, :3, :4, :5, :6, :7, :8, :9)"
and gets error
"Incorrect datetime value: '2023-02-22T12:00:36Z' for column
`akonadi`.`pimitemtable`.`datetime` at row 1"
Can you check what the schema for that table is? How does the current
data look like?
So, akonadiconsole produces a graphical representation of the schema, so
I had to use the command line client as follows:
mysql -S /tmp/akonadi-paulb.c9oVw2/mysql.socket
The socket file can be discovered by doing "ps -ef | grep mysql" and
reading the --socket option of the mysqld process command line.
After doing "use akonadi", I performed the following:
MariaDB [akonadi]> desc PimItemTable;
+----------------+----------------+------+-----+---------------------+----------------+
| Field | Type | Null | Key | Default |
Extra |
+----------------+----------------+------+-----+---------------------+----------------+
| id | bigint(20) | NO | PRI | NULL |
auto_increment |
| rev | int(11) | NO | | 0 |
|
| remoteId | varbinary(255) | YES | MUL | NULL |
|
| remoteRevision | varbinary(255) | YES | | NULL |
|
| gid | varbinary(255) | YES | MUL | NULL |
|
| collectionId | bigint(20) | YES | MUL | NULL |
|
| mimeTypeId | bigint(20) | YES | MUL | NULL |
|
| datetime | timestamp | NO | | current_timestamp() |
|
| atime | timestamp | NO | | current_timestamp() |
|
| dirty | tinyint(1) | YES | | NULL |
|
| size | bigint(20) | NO | | 0 |
|
+----------------+----------------+------+-----+---------------------+----------------+
11 rows in set (0.001 sec)
(Unless you are sure the root cause is
https://bugreports.qt.io/browse/QTBUG-95071)
This was the closest thing I could find.
Or could this be a variant of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993219 ?
I don't think so. People have experienced configuration issues with
MySQL in the past, on one occasion involving a change in the default
behaviour of MySQL itself, but the library upgrade seems more likely to
have caused a problem than anything else.
Very weird that Akonadi would stop working on an upgrade of
1:10.3.38-0+deb10u1. Does it start working if you downgrade back to
1:10.3.37-0+deb10u1?
Yes, I wouldn't expect the issue described in the upstream bug tracker
to occur at this point, but I don't know what goes into the Debian
patching of this library, either.
Using "apt-cache showpkg libmariadb3", I found that the following
version was available via apt:
1:10.3.34-0+deb10u1
However, in my /var/cache/apt/archive collection, I have this later
version:
1:10.3.36-0+deb10u2
Trying to use dpkg to install this later version seems to make Akonadi
non-functional, as does any attempt to use apt to install the earlier
version, these being the respective commands:
dpkg -i
/var/cache/apt/archives/libmariadb3_1%3a10.3.36-0+deb10u2_amd64.deb
apt-get install libmariadb3=1:10.3.34-0+deb10u1
Both attempts yield errors like this in the Akonadi server log:
Tokenizer Warning: trailing garbage after angle-addr in Return-Path!
Maybe I am just failing to downgrade the library properly, and perhaps I
would also need to ensure that the MySQL server is also downgraded.
Paul
