Your message dated Mon, 6 Mar 2023 23:32:51 -0800
with message-id
<caou6tabbuzh-hde85mpumx9unysxtd1yivesccu3owxegt-...@mail.gmail.com>
and subject line Re: [debian-mysql] Bug#918988: libmariadbclient18: conflict
with libmysqlclient18
has caused the Debian Bug report #918988,
regarding libmariadbclient18: conflict with libmysqlclient18
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
918988: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918988
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libmariadbclient18
Version: 10.1.26-0+deb9u1
Severity: normal
Dear Maintainer,
On a web server running Apache, I'm using OCS inventory (using the
ocsinventory-server Debian package), through mod_perl. OCS inventory
uses libdbd-mysql-perl, which depends on libmariadbclient18.
This Apache instance also runs mod_php, using php5-mysql, which depends
on libmysqlclient18.
After upgrading libmariadbclient18 from 10.1.26-0+deb9u1 to
10.1.37-0+deb9u1, requests to the OCS inventory server were making Apache
crash, leaving "child pid #### exit signal Segmentation fault (11)"
messages in Apache error log files. As a result, Apache was returning
500 HTTP error instead of expected response from OCS inventory.
Downgrading libmariadbclient18 to 10.1.26-0+deb9u1 made everything work
again.
On another server running Apache, I'm using django through mod_wsgi. My
django app was depending on the mysqlclient Python module (provided by
pip in a virtualenv, not by a Debian package), which contained a .so
file linked with libmariadbclient18 (the one in
/usr/lib/x86_64-linux-gnu).
This same Apache instance also runs mod_php, using php5-mysql, which
depends on libmysqlclient18.
After upgrading libmariadbclient18 from 10.1.26-0+deb9u1 to
10.1.37-0+deb9u1, requests to the django web site were making Apache
crash, leaving "child pid #### exit signal Segmentation fault (11)"
messages in Apache error log files. As a result, Apache was returning
500 HTTP error instead of expected response from django.
Downgrading libmariadbclient18 to 10.1.26-0+deb9u1 made everything work
again. Using libmariadbclient18 10.1.37-0+deb9u1 but disabling mod_php
also worked.
I eventually kept libmariadbclient18 10.1.37-0+deb9u1 but installed
libmysqlclient-dev instead of libmariadbclient-dev, and rebuilt
mysqlclient Python module with libmariadbclient-dev. Now the .so file
from mysqlclient is linked with libmysqlclient18, not with
libmariadbclient18 anymore. This way mod_wsgi and mod_php successfully
run in the same Apache instance, while using libmariadbclient18
10.1.37-0+deb9u1.
As a whole, it seems libmysqlclient and libmariadbclient coexisted
peacefully with 10.1.26-0+deb9u1, but don't since 10.1.37-0+deb9u1.
While trying to debug my wsgi crash, I read some explanations about
conflicting symbols. I don't now very well how this whole symbols and
dynamic libraries stuff works, but I remarked this :
* with 10.1.26-0+deb9u1:
$ nm -D /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 | egrep
'lib(mariadb|mysql)client_18'
0000000000000000 A libmariadbclient_18
$ nm -D /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18 | egrep
'lib(mariadb|mysql)client_18'
0000000000000000 A libmysqlclient_18
$
* with 10.1.37-0+deb9u1:
$ nm -D /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 | egrep
'lib(mariadb|mysql)client_18'
0000000000000000 A libmariadbclient_18
0000000000000000 A libmysqlclient_18
$ nm -D /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18 | egrep
'lib(mariadb|mysql)client_18'
0000000000000000 A libmysqlclient_18
$
So I wonder if new libmariadbclient declaring the same mysql "things" as
libmysqlclient could be the reason of the crashes.
--- End Message ---
--- Begin Message ---
Hi!
Latest version of MariaDB in Debian unstable/testing/Bookworm is
10.11.2. You might want to consider testing it.
If you want to contribute in the open source way to fix this or any
other issue, see
https://salsa.debian.org/mariadb-team/mariadb-server/-/wikis/Contributing-to-MariaDB-packaging-in-Debian
on how to submit a Merge Request!
If you have time to help, please consider these (in order of importance):
1. Review current open MRs at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests
2. Review items highlighted by Debian QA systems (Lintian, builds etc)
and submit a fix to improve the quality:
https://tracker.debian.org/pkg/mariadb
3. Review what testing we have at
https://salsa.debian.org/mariadb-team/mariadb-server/-/pipelines and
think about potential gaps - CI is very important as it is the only
way we can prevent regressions in a scalable way
4. Review/follow-up on existing bugs that currently need more
information:
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
MariaDB and C++ skills are useful, but not required. For example
reviewing the NEWS for 10.11 requires no coding skills:
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/37
My request for help from debian-devel in
https://lists.debian.org/debian-devel/2023/02/msg00272.html did not
get many responses, so the future of this package depends on how
active the users and people who previously reported bugs are in
participating in the maintenance of the package.
- Otto
--- End Message ---
