Bug#1031863: libqt5sql5-mysql: incompatible change in libmariadb3 breaks kontact, needs upstream fix in libqt5sql5-mysql

[Paul Boddie]

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 libqt5sql5 5.11.3+dfsg1-1+deb10u5
ii libstdc++6 8.3.0-6

libqt5sql5-mysql recommends no packages.

libqt5sql5-mysql suggests no packages.

-- no debconf information

[Lisandro Damian Nicanor Perez Meyer]

reassign 1031863 libmariadb3 1:10.3.34-0+deb10u1
thanks

Hi!

On Fri, 24 Feb 2023 15:25:58 +0100 Paul Boddie <pa...@boddie.org.uk> wrote:
> 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

This is a bug in oldstable! If mariadb maintainers pushed a new version there
then they need to undo the change you mention above. This is not a Qt issue
for oldstable.

[Paul Boddie]

On Sunday, 26 February 2023 15:38:20 CET Lisandro Damian Nicanor Perez Meyer
wrote:

> reassign 1031863 libmariadb3 1:10.3.34-0+deb10u1
> thanks

[...]

> This is a bug in oldstable! If mariadb maintainers pushed a new version
> there then they need to undo the change you mention above. This is not a Qt
> issue for oldstable.

It was an open question as to whether Debian packaging would adopt the same
strategy as Qt upstream, introducing the workaround in Qt, or mitigate the
problem in the libmariadb3 packaging. I wonder, then, if the severity should
be elevated since this regression potentially breaks numerous other packages.

Thanks,

Paul

[Lisandro Damian Nicanor Perez Meyer]

Hi Paul!

If we where talking about testing, yes, fixing Qt would be the way to go. But
this is different, ideally the mariadb maintainers (or whoever uploaded the
package) should fix the regression. If we try to do this in oldtsbale then we
risk breaking someone else's setup.

That being said: you should **REALLY** consider switching to stable like
**RIGHT NOW**. Why? Because in Debian we provide no security on webengine/
wekbit, and kde pim uses it a lot. Using it in oldstable is really a bad, bad
idea.

Regards, Lisandro.

[Otto Kekäläinen]

Hi!

> > reassign 1031863 libmariadb3 1:10.3.34-0+deb10u1
> > thanks

Why did you run into this issue now? The version above has been in
Debian oldstable since almost a year, are you sure you diagnosed this
for the correct package version?

> > This is a bug in oldstable! If mariadb maintainers pushed a new version
> > there then they need to undo the change you mention above. This is not a Qt
> > issue for oldstable.
>
> It was an open question as to whether Debian packaging would adopt the same
> strategy as Qt upstream, introducing the workaround in Qt, or mitigate the
> problem in the libmariadb3 packaging. I wonder, then, if the severity should
> be elevated since this regression potentially breaks numerous other packages.

This is the first bug report on this. It might affect other packages,
but there is no evidence of that yet. Also I am a little bit confused
on what is the actual error here.

Could you provide me the exact commands I should run in e.g. a Docker
container with Debian Buster to reproduce the bug? If I can reproduce
it, I should be able to get to the bottom of it.

[Paul Boddie]

On Monday, 27 February 2023 06:50:42 CET Otto Kekäläinen wrote:
> Hi!
>
> > > reassign 1031863 libmariadb3 1:10.3.34-0+deb10u1
> > > thanks
>
> Why did you run into this issue now? The version above has been in
> Debian oldstable since almost a year, are you sure you diagnosed this
> for the correct package version?

The package details are these (from dpkg):

libmariadb3:amd64 1:10.3.38-0+deb10u1

These are consistent with the first message in this bug report.

[...]

> This is the first bug report on this. It might affect other packages,
> but there is no evidence of that yet. Also I am a little bit confused
> on what is the actual error here.

Bug #1031770 described how the problem manifests itself in Kontact/Akonadi:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770

To summarise, after the packages were upgraded, Kontact produced an error upon
trying to open mail messages:

Unable to fetch item from backend (collection -1)
Unable to retrieve item from resource

Further discussion about this took place in the original bug report.

> Could you provide me the exact commands I should run in e.g. a Docker
> container with Debian Buster to reproduce the bug? If I can reproduce
> it, I should be able to get to the bottom of it.

I think I already established the origin of the problem:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770#25

For some reason, someone decided to merge an incompatible change to the 10.3
branch of the MariaDB library code, breaking the API.

I suppose I could restore my libqt5sql5-mysql package to the standard one,
reverting the upstream workaround, then I could revert this incompatible test
in libmariadb3, and then I could see if I can still read my mail messages.
Would that help?

Paul

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Tue, 28 Feb 2023 at 18:31, Paul Boddie <pa...@boddie.org.uk> wrote:
> So, to summarise:
>
> Standard libqt5sql5-mysql plus standard libmariadb3 breaks Akonadi/Kontact.
> Revised libqt5sql5-mysql plus standard libmariadb3 fixes Akonadi/Kontact.
> Standard libqt5sql5-mysql plus revised libmariadb3 breaks Akonadi/Kontact.
>
> But as I noted, since the fix to libqt5sql5-mysql involves interpretation of
> the version identifier, I wonder whether I am really building a fixed
> libmariadb3 package.

If by "standard" you mean "what was shipped with buster" I'm pretty
sure it should work, else we would have tons of users telling us :-D
Now if you mean something different I did not get the real meaning :-)

Cheers, Lisandro.

--
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

[Paul Boddie]

On Monday, 27 February 2023 12:07:27 CET Paul Boddie wrote:
>
> I think I already established the origin of the problem:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770#25
>
> For some reason, someone decided to merge an incompatible change to the 10.3
> branch of the MariaDB library code, breaking the API.
>
> I suppose I could restore my libqt5sql5-mysql package to the standard one,
> reverting the upstream workaround, then I could revert this incompatible
> test in libmariadb3, and then I could see if I can still read my mail
> messages. Would that help?

Well, I tried to build a libmariadb3 package using the delightful gbp tool,
then I restored the standard version of the libqt5sql5-mysql package and
installed this revised libmariadb3 package, but either reverting the upstream
change made no difference within libmariadb3 or I failed to introduce the
change and gbp just built the standard package all over again.

So, to summarise:

Standard libqt5sql5-mysql plus standard libmariadb3 breaks Akonadi/Kontact.
Revised libqt5sql5-mysql plus standard libmariadb3 fixes Akonadi/Kontact.
Standard libqt5sql5-mysql plus revised libmariadb3 breaks Akonadi/Kontact.

But as I noted, since the fix to libqt5sql5-mysql involves interpretation of
the version identifier, I wonder whether I am really building a fixed
libmariadb3 package.

Paul

[Paul Boddie]

On Tuesday, 28 February 2023 22:35:35 CET Lisandro Damián Nicanor Pérez Meyer
wrote:

>
> On Tue, 28 Feb 2023 at 18:31, Paul Boddie <pa...@boddie.org.uk> wrote:
> > So, to summarise:
> >
> > Standard libqt5sql5-mysql plus standard libmariadb3 breaks
> > Akonadi/Kontact.
> > Revised libqt5sql5-mysql plus standard libmariadb3 fixes Akonadi/Kontact.
> > Standard libqt5sql5-mysql plus revised libmariadb3 breaks Akonadi/Kontact.
> >
> > But as I noted, since the fix to libqt5sql5-mysql involves interpretation
> > of the version identifier, I wonder whether I am really building a fixed
> > libmariadb3 package.
>
> If by "standard" you mean "what was shipped with buster" I'm pretty
> sure it should work, else we would have tons of users telling us :-D
> Now if you mean something different I did not get the real meaning :-)

I mean standard as in the most recent versions:

libqt5sql5-mysql:amd64 5.11.3+dfsg1-1+deb10u5
libmariadb3:amd64 1:10.3.38-0+deb10u1

As in the combination which caused my mail client to stop working last week,
possibly when this package update rolled in...

2023-02-21 10:26:08 upgrade libmariadb3:amd64 1:10.3.36-0+deb10u2
1:10.3.38-0+deb10u1

Source: /var/log/dpkg.log

Paul

[Otto Kekäläinen]

Hi!

The fact that his issue surfaced now about something that changed in
Debian 1-2 years ago and was changed upstream 2 years ago confuses me.
Also I don't have any easy way to fire up a container and reproduce
the issue.

However, as a clear patch was suggested I did it in
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/bugfix/1031863-libmariadb3-version-id

The the Salsa runner comes back online and pipeline works again, there
will be build artifacts available at
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/4004950 and
you can download the libmariadb3 with this patched and test if it
fixes your mail client situation.

[Paul Boddie]

On Wednesday, 1 March 2023 07:24:23 CET Otto Kekäläinen wrote:
>
> The fact that his issue surfaced now about something that changed in
> Debian 1-2 years ago and was changed upstream 2 years ago confuses me.
> Also I don't have any easy way to fire up a container and reproduce
> the issue.

It isn't really so mysterious, and I tried to explain it in the original bug I
filed against Kontact:

1. A change in MariaDB 10.6 broke Qt's MySQL support back in 2021.

2. Someone decided to let this change leak into MariaDB 10.3.38.

3. A Debian package for 10.3.38 was finalised in the last couple of weeks and
arrived last week.

4. Suddenly, Akonadi cannot connect to MySQL properly and Kontact won't show
the contents of mail messages any more.

How the change leaked is more mysterious. However, going to the 10.3 branch of
the server, following the link to libmariadb and the mariadb-connector-c
repository and using the "blame" tool yields this commit:

https://github.com/mariadb-corporation/mariadb-connector-c/commit/
d204e83104222844251b221e9be7eb3dd9f8d63d

That was made two months ago, but I imagine that the workflow propagated it in
various branches for a while before a release was actually made.

> However, as a clear patch was suggested I did it in
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/bugfix/1031863-> libmariadb3-version-id

I realised that I had messed up my own patch, explaining why I didn't see any
change in behaviour with my revised package, but rebuilding again and testing
now, I can confirm that the above patch fixes the problem. Reverting to the
distribution-supplied libqt5sql5-mysql package and using the patched version
of libmariadb3 makes Kontact and Akonadi work again.

> The the Salsa runner comes back online and pipeline works again, there
> will be build artifacts available at
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/jobs/4004950 and
> you can download the libmariadb3 with this patched and test if it
> fixes your mail client situation.

It seems that the pipeline failed, but I managed to build a revised package
anyway.

I have no idea about whether other software has been broken by this, but
anyone using the distribution-supplied packages for libmariadb3 and
libqt5sql5-mysql will have seen programs break.

Maybe only the Akonadi stack is affected as a consequence. Since people tend
to abandon the KDE groupware programs every time something breaks, it is
entirely possible that there are relatively few users left to complain.

All this effort for a single-token change in a file that shouldn't have been
made in the first place!

Paul

[Otto Kekäläinen]

> > The fact that his issue surfaced now about something that changed in
> > Debian 1-2 years ago and was changed upstream 2 years ago confuses me.
> > Also I don't have any easy way to fire up a container and reproduce
> > the issue.
>
> It isn't really so mysterious, and I tried to explain it in the original bug I
> filed against Kontact:

i was referring to steps to reproduce.

> https://github.com/mariadb-corporation/mariadb-connector-c/commit/d204e83104222844251b221e9be7eb3dd9f8d63d

Thanks for pointing this one. I was reading the commit
https://github.com/mariadb-corporation/mariadb-connector-c/commit/a37b7c3965706f9a062baaba0c494dd6efb2c306
that another reporter posted earlier.

> > However, as a clear patch was suggested I did it in
> > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/bugfix/1031863-> libmariadb3-version-id
>

..

> It seems that the pipeline failed, but I managed to build a revised package
> anyway.

Salsa-CI is back online and
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/292377544983e0db9b702399a977b900cdacbcee
is building.

[Paul Boddie]

On Wednesday, 1 March 2023 17:09:54 CET Otto Kekäläinen wrote:
> > > The fact that his issue surfaced now about something that changed in
> > > Debian 1-2 years ago and was changed upstream 2 years ago confuses me.
> > > Also I don't have any easy way to fire up a container and reproduce
> > > the issue.
> >
> > It isn't really so mysterious, and I tried to explain it in the original
> > bug I filed against Kontact:
> i was referring to steps to reproduce.

Sorry, I can only really report how the bug arose on my system. Reproducing it
would presumably involve creating an environment where Akonadi is initialised
and then trying to access resources via Akonadi. Without some kind of test
suite, which I presume does not already exist for Akonadi, that would
potentially be a lot of work.

> > https://github.com/mariadb-corporation/mariadb-connector-c/commit/d204e831

> > 04222844251b221e9be7eb3dd9f8d63d
> Thanks for pointing this one. I was reading the commit
> https://github.com/mariadb-corporation/mariadb-connector-c/commit/a37b7c3965
> 706f9a062baaba0c494dd6efb2c306 that another reporter posted earlier.

Yes, it is difficult to navigate to the commit on the appropriate branch, and
the involvement of mysql_get_client_info in that patch also confused me.

> > > However, as a clear patch was suggested I did it in
> > > https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commits/bugfix/1031
> > > 863-> libmariadb3-version-id
> ..
>
> > It seems that the pipeline failed, but I managed to build a revised
> > package
> > anyway.
>
> Salsa-CI is back online and
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/commit/292377544983e0db
> 9b702399a977b900cdacbcee is building.

Thank you for activating this again.

Paul

[Rai]

Hi Paul,

Thanks for clearification.
At least we are 2 users and over the years I'm really happy with debian. ;)

Regards
Rai

[Otto Kekäläinen]

Hi!

I have this now as
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/36
and I also sent it upstream at
https://github.com/mariadb-corporation/mariadb-connector-c/pull/219.
You can +1 these if you want to increase the odds of them being
merged.

If somebody wants to make a bug report upstream at jira.mariadb.org it
would help, in particular if you can find any other library than just
libqt5sql5-mysql that is affected by this.

[Paul Boddie]

On Friday, 3 March 2023 08:37:05 CET Otto Kekäläinen wrote:
>
> I have this now as
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/36

Thanks for looking into this! I saw that the package build pipeline failed
with various Lintian errors, so there was no package to download and test as
far as I could see. Nevertheless, I tested an equivalent package myself and it
resolved the problem, as noted previously.

> and I also sent it upstream at
> https://github.com/mariadb-corporation/mariadb-connector-c/pull/219.
> You can +1 these if you want to increase the odds of them being
> merged.

I will probably do this and also add a comment.

> If somebody wants to make a bug report upstream at jira.mariadb.org it
> would help, in particular if you can find any other library than just
> libqt5sql5-mysql that is affected by this.

"apt-cache rdepends libmariadb3 | wc -l" yields 175 entries on my system,
although this is a very crude way of assessing the impact.

If I limit myself to "apt-cache rdepends libqt5sql5-mysql", I see the
following packages with dependencies on that package:

akonadi-backend-mysql
digikam

There are these packages which recommend it:

actiona
kraft
xca

So, the direct exposure to the same problem as reported in the original bug is
fairly limited. Had I kept using digiKam, I would probably have encountered
problems with that, too, but I stopped using it given various concerns about
its behaviour.

As for the broader dependencies on libmariadb3, I did a source code search for
mysql_get_client_version using sources.debian.org and found a few candidates
of note:

vtk6 and vtk9 both test for the client version to assess prepared query
availability:

https://sources.debian.org/src/vtk6/6.3.0+dfsg2-8.1/IO/MySQL/
vtkMySQLDatabase.cxx/?hl=108#L108

https://sources.debian.org/src/vtk9/9.1.0+really9.1.0+dfsg2-5/IO/MySQL/
vtkMySQLDatabase.cxx/?hl=108#L108

paraview appears to embed VTK code and thus exhibits a similar potential
issue:

https://sources.debian.org/src/paraview/5.11.0+dfsg-1/VTK/IO/MySQL/
vtkMySQLDatabase.cxx/?hl=109#L109

tango has two places with client version testing:

https://sources.debian.org/src/tango/9.3.4+dfsg1-2/cppserver/
tangoaccesscontrol/DbUtils.cpp/?hl=137#L137

https://sources.debian.org/src/tango/9.3.4+dfsg1-2/cppserver/database/
DataBaseUtils.cpp/?hl=782#L782

kamailio also seems to have code which might be affected:

https://sources.debian.org/src/kamailio/5.6.3-2/src/modules/db_mysql/
db_mysql.c/?hl=133#L133

Obviously, it is entirely possible that relatively few people use these
packages and that there are few, if any, reverse dependencies on these
packages, so nobody will have noticed any problems.

Paul

[Otto Kekäläinen]

Forwarded: https://lists.launchpad.net/maria-discuss/msg06508.html

I noticed that this was originally reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031773 but with so
few details that it did not lead into a deeper investigation at that
time.

[David Burau]

Hi,

I'm not sure if this is the right place to write this. Please help me if I'm wrong.

A few days a ago I had similar problems with different versions of mariadb.

I wasn't able to write, receive mails or change addresses in kontact.

The error in kmail was: "Unable to write item changes into the database"

The akonadi error lag can be found here: https://nopaste.net/SeDzR2I6VX 

The error occurs after an update of some mariadb and qt components.

You'll find an extraction from apts history.log here: https://nopaste.net/HXiPogtPMe 

I was able to solve the problem by downgrading mariadb via:

sudo apt install mariadb-common=1:10.5.18-0+deb11u1 mariadb-server-core-10.5=1:10.5.18-0+deb11u1 mariadb-client-10.5=1:10.5.18-0+deb11u1 libmariadb3=1:10.5.18-0+deb11u1 mariadb-client-core-10.5=1:10.5.18-0+deb11u1

David

&references=<4500305.qgaIjWLANL@jason> <64D344E8-6286-45FA...@rlac.de>

 <CAOU6tACyRA3Mrhwq13ULB_A=pC5Q+b20Wm=8TTyhxe...@mail.gmail.com> <5278277.6OYGDDinUv@jason>

 <CAOU6tADUVpCm4t1J5oAT22sr...@mail.gmail.com>

[Otto Kekäläinen]

For the record, I have now patches both for 10.3 and 10.5:

https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/36
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/13

The upstream PR has not been accepted:
https://github.com/mariadb-corporation/mariadb-connector-c/pull/219

Some +1 might help get these included in next uploads.


Currently there isn't that many people helping with MariaDB
maintenance in Debian. If you want to contribute, please consider
helping by:

- Fixing some other bug listed at
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=mariadb&src=mariadb-10.6&src=mariadb-10.5&src=mariadb-10.3&src=mariadb-10.1
- Review open MRs at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests
- Review recent commits at https://salsa.debian.org/mariadb-team/mariadb-server

Thanks!

[Paul Boddie]

On Sunday, 26 March 2023 03:29:00 CEST Otto Kekäläinen wrote:
> For the record, I have now patches both for 10.3 and 10.5:
>
> https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/36
> https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/13
>
> The upstream PR has not been accepted:
> https://github.com/mariadb-corporation/mariadb-connector-c/pull/219
>
> Some +1 might help get these included in next uploads.

I gave your original message a +1, which I imagine is what I am supposed to do
in GitHub's convoluted interface. I find the upstream treatment of the issue
to be less than reassuring: to work around some other problem, they have
decided to break something else. Then again, I personally chose to ignore and
avoid MySQL in my own projects many years ago due to the lacklustre record of
its maintainers.

> Currently there isn't that many people helping with MariaDB
> maintenance in Debian. If you want to contribute, please consider
> helping by:
>
> - Fixing some other bug listed at
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=mariadb&sr
> c=mariadb-10.6&src=mariadb-10.5&src=mariadb-10.3&src=mariadb-10.1 - Review
> open MRs at
> https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests
> - Review recent commits at
> https://salsa.debian.org/mariadb-team/mariadb-server
>
> Thanks!

I appreciate your efforts, so I thank you again for pursuing this matter.
However, I have plenty of other demands on my time before I can even consider
getting involved here, not least another Debian packaging effort that is
largely stalled due to upstream inactivity and insularity, this in turn
blocking the migration of a public Debian service to a software stack that is
actively supported within Debian.

This whole affair is a reminder that the end-user often has limited influence
over precise technological choices. I chose to use Kontact/KMail many years
ago, and since that decision was made, its maintainers introduced a middleware
layer along with a dependency on MySQL, giving users very little opportunity
to exclude this new technology from their environment other than to migrate to
another application entirely. I imagine that a large proportion of the
previously happy user base did indeed migrate to something else due to
increasing dissatisfaction that was casually disregarded by the developers.

The outcome here is a broken mail program that people can only fix by either
downgrading packages, with potential security and stability concerns, or to
introduce the fix that the upstream developers refuse to apply. For non-
technical users, such remedies are not readily available, and so they just end
up with a system that no longer works for them. All because people introduce
problematic technology and won't stick around to fix it when it breaks.

Sorry to articulate my frustration with the state of modern technology!

Paul

[Otto Kekäläinen]

Hi!

I updated today
https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/36.

I would appreciate some eyes to review it and thumbs up if you want me
to proceed with this.

- Otto

Related for context:
- https://salsa.debian.org/mariadb-team/mariadb-10.3/-/merge_requests/36
- upstream PR of above
https://github.com/mariadb-corporation/mariadb-connector-c/pull/219
- bug reports in Debian for MariaDB 10.3:
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031773
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031863
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031770
- Also for 10.5: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033654
- and MR https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/13
(will be updated and merged after the 10.3 one)
- mariadb-config vs libmariadb.pc version oddity:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024241
- mariadb-config lib path oddity:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001843
- upstream PR to simplify mariadb.pc vs libmariadb.pc:
https://github.com/MariaDB/server/pull/1800