Bug#1031770: Info received (kontact: cannot show existing messages and will not retrieve new ones)
On Friday, 24 February 2023 09:55:18 CET Rai wrote: > Hi Paul, > > Great work and big thanks for the findings. > But indeed, this change in mariadb_lib.c is a functional change which should > have never made it in a security update. :( Agreed. Since this bug merely manifests itself in Kontact but must be fixed elsewhere, I have opened a new bug against libqt5sql5-mysql: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031863 Sorry if this bug might have been retargeted, but it isn't obvious how that might be done. I imagine that we could make this existing bug dependent on the new bug, and when the fix is hopefully made, we might then close both of them. It is conceivable that Debian maintainers may wish to revert the regression in libmariadb3 instead, but that it a matter for them to decide, and so I won't go and create another bug against libmariadb3. I have merely mentioned the possibility in the new bug description. Paul
Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql
Package: libqt5sql5-mysql Version: 5.11.3+dfsg1-1+deb10u5 Severity: important Dear Maintainer, A recent update to libmariadb3 introduced a change to MySQL version number reporting that ultimately breaks Kontact and Akonadi. To note this, I filed bug #1031770 against the kontact package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770 However, this breakage probably needs fixing in the Qt 5 SQL driver for MySQL/MariaDB, and a fix was indeed introduced to Qt 5.15 upstream: https://bugreports.qt.io/browse/QTBUG-95071 Should the Qt packaging be the appropriate location of any fix, then this upstream fix will need to be backported to Qt 5.11.3, as packaged by Debian for Buster. I have tested a variant of the upstream patch with the Qt 5.11.3 SQL driver for MySQL, and it restored Kontact to a functioning state. It is a question of policy as to whether the upstream Qt approach of working around the breakage is more desirable than patching libmariadb3 within Debian. Obviously, an alternative would be to make Qt-based software link against later versions of Qt, but these are, of course, not packaged for Buster. Such an alternative is presumably available by upgrading a system to Bullseye, but having to upgrade a system purely to work around a one-line regression is hardly optimal. Therefore, I invite the Qt and MariaDB package maintainers to discuss the most convenient solution to this issue, noting that anyone relying on Kontact, KMail, Akonadi and other Qt-based software employing MySQL/MariaDB in Buster will already have been dealing with non-functioning software for the past few days. Thanks in advance for any consideration you can give to this issue, Paul -- System Information: Debian Release: 10.13 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libqt5sql5-mysql depends on: ii libc6 2.28-10+deb10u2 ii libmariadb3 1:10.3.38-0+deb10u1 ii libqt5core5a [qtbase-abi-5-11-3] 5.11.3+dfsg1-1+deb10u5 ii libqt5sql55.11.3+dfsg1-1+deb10u5 ii libstdc++68.3.0-6 libqt5sql5-mysql recommends no packages. libqt5sql5-mysql suggests no packages. -- no debconf information
Bug#1031770: Info received (Bug#1031770: Info received (kontact: cannot show existing messages and will not retrieve new ones))
Hello again, I also found the applicable upstream KDE bug: "Akonadi fails with Mariadb 10.6.3" https://bugs.kde.org/show_bug.cgi?id=439769 Meanwhile, applying the fix suggested for Qt 5.15 in a slightly modified form seems to prevent the error I experienced from occurring. With the modified libqt5sql5-mysql package installed, I have managed to start Kontact, view stored messages (after some messing around with akonadiconsole, due to earlier troubleshooting attempts), and this message will have been sent from Kontact. I conclude, then, that the upstream fix needs backporting to Qt 5.11.3 for Debian. Paul
Bug#1031770: Info received (kontact: cannot show existing messages and will not retrieve new ones)
Hello again,
I looked at the packaging repository for libmariadb3 and found the
following commit importing the upstream sources for 10.3.38:
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;
}
ulong STDCALL mysql_hex_string(char *to, const char *from, unsigned
long len)
This appears to be what the Qt bug report is describing:
"MariaDB 10.6 changed the mysql_get_client_version output to return the
library version (30200 as of 10.6.3) instead of the server version"
https://bugreports.qt.io/browse/QTBUG-95071
So, it seems that the changes to MariaDB 10.6 have leaked into 10.3,
thus causing this issue.
Paul
Bug#1031770: kontact: cannot show existing messages and will not retrieve new ones
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
Bug#1031770: kontact: cannot show existing messages and will not retrieve new ones
Package: kontact Version: 4:18.08.3-1 Severity: important Dear Maintainer, Today I found that Kontact would not load and show messages that already reside in my mailboxes, and it refuses to download new ones. In the status bar, messages like the following are shown: Unable to fetch item from backend (collection -1) Unable to retrieve item from resource Opening akonadiconsole and its browser functionality does show messages in the list for each mailbox, and it also manages to show each message payload. However, the following error messages are generated in the terminal window: 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" 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:08:21Z' for column `akonadi`.`pimitemtable`.`atime` at row 1" org.kde.pim.akonadiserver: Error text: "Incorrect datetime value: '2023-02-22T12:08:21Z' for column `akonadi`.`pimitemtable`.`atime` at row 1 QMYSQL: Unable to execute query" org.kde.pim.akonadiserver: Query: "UPDATE PimItemTable SET atime = :0 WHERE ( PimItemTable.collectionId = :1 )" org.kde.pim.akonadiserver: Unable to update item access time It turns out that this is caused by a bug that was reported back in 2021: "Kmail fails to display message, akonadiserver errors" https://forums.opensuse.org/t/kmail-fails-to-display-message-akonadiserver-errors/147051 "Bug 1189184 - org.kde.pim.akonadiserver: Error code: "1292"" https://bugzilla.opensuse.org/show_bug.cgi?id=1189184 "Akonadi fails with Mariadb 10.6.3" https://bugs.kde.org/show_bug.cgi?id=439769 "mysql client version detection broken with MariaDB 10.6" https://bugreports.qt.io/browse/QTBUG-95071 I imagine that a fix for this bug needs to be introduced to the packaged Qt 5 SQL library from whichever version was fixed. It looks like the libqt5sql5-mysql:amd64 package on my system is based on 5.11: 5.11.3+dfsg1-1+deb10u5 But upstream fixes only covered 5.15 and 6.2 branches. I see that the following package was upgraded on my system recently: libmariadb3_1%3a10.3.38-0+deb10u1_amd64.deb The libmariadb3 package has the following version: 1:10.3.38-0+deb10u1 So, this may have caused this bug to appear on my system. If anyone really thought that they absolutely had to incorporate a full relational database server into their desktop application, then at the very least they should have used PostgreSQL and saved everyone the bother of dealing with the circus that is MySQL. I will spare everyone the usual rant about Akonadi, noting only that "akonadictl restart" is a regular command invocation in my workflow. Thanks in advance for any consideration of this issue, Paul -- System Information: Debian Release: 10.13 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kontact depends on: ii kdepim-runtime 4:18.08.3-4 ii kio 5.54.1-1 ii libc62.28-10+deb10u2 ii libgcc1 1:8.3.0-6 ii libkf5completion55.54.0-1 ii libkf5configcore55.54.0-1+deb10u1 ii libkf5configgui5 5.54.0-1+deb10u1 ii libkf5configwidgets5 5.54.0-1 ii libkf5coreaddons55.54.0-1 ii libkf5crash5 5.54.0-1 ii libkf5grantleetheme-plugins 18.08.3-1 ii libkf5grantleetheme5 18.08.3-1 ii libkf5i18n5 5.54.0-1 ii libkf5iconthemes55.54.0-1 ii libkf5kcmutils5 5.54.0-1 ii libkf5kdepimdbusinterfaces5 4:18.08.3-2 ii libkf5kiowidgets55.54.1-1 ii libkf5kontactinterface5 18.08.3-1 ii libkf5libkdepim-plugins 4:18.08.3-2 ii libkf5libkdepim5 4:18.08.3-2 ii libkf5parts5 5.54.0-1 ii libkf5service-bin5.54.0-1 ii libkf5service5
Bug#908588: Some more observations
Evidently, the "fix" doesn't seem to have the intended effect. Launching Akregator just now spawned three "HTTP Cache Cleaner" instances and the animated cursor, with the plasma-desktop process increasing its activity. I suppose it is possible that the referenced .desktop file is not involved, but the /usr/lib/kde4/libexec/kio_http_cache_cleaner program does seem to be invoked. Paul
Bug#908588: kdelibs5-data: HTTP Cache Cleaner starts irritating launch notifier (also makes plasma-desktop busy)
Package: kdelibs5-data Version: 4:4.14.2-5+deb8u2 Severity: normal Upon launching Akregator in the Kontact application, "HTTP Cache Cleaner" starts up with the bouncing notifier cursor and a window entry in the taskbar. Also plasma-desktop starts running more excitedly. This can be quite annoying. Apparently, some efforts were made to fix this bug in the past: https://bugs.kde.org/show_bug.cgi?id=108809 https://bugs.launchpad.net/ubuntu/+source/kde4libs/+bug/60315 The suggested fix is not applied in the Jessie version of the affected file: /usr/share/kde4/services/http_cache_cleaner.desktop Here is a link to the fairly trivial change: http://commits.kde.org/kio/a327b47c16e2a8167e90864aae11240b94dc3f05 (It is mentioned near the end of each of the bug reports given above.) It may be the case that this fixes the problem, although with the offending program having been run recently, the program might not be invoked again when I re-run Akregator, so it remains possible that it will recur in future. I will attempt to monitor this and provide additional information. Thanks for packaging KDE for Debian. -- System Information: Debian Release: 8.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: i386 (i686) Kernel: Linux 3.16.0-6-586 Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kdelibs5-data depends on: ii ca-certificates 20141019+deb8u4 ii hicolor-icon-theme 0.13-1 ii perl5.20.2-3+deb8u11 kdelibs5-data recommends no packages. kdelibs5-data suggests no packages. -- no debconf information
Re: Sort of quick review of libkolab
On Wednesday 21. May 2014 10.39.25 Maximiliano Curia wrote: > > Thanks for taking care of libkolab, I've made a quick review of the > package, mostly checking the differences with the Debian package. The list > is long, but I think most of the points are easy to fix. I hope so! As I'm more or less merging other people's work, and being a quick first attempt in limited time, it was not going to produce acceptable results straight away, but you've given me some concrete things to fix. I'll take a look at these things and try and refine the packaging. Thanks for taking a look! Paul -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201405212329.48331.p...@boddie.org.uk
