Reason is, that the bug is already reported on upstream:
https://jira.mariadb.org/browse/MDEV-26905.
Also we currently do not know how to fix it. If we eventually figure out
how to fix this bug, then the patch would be submitted directly to the
upstream, rather than to downstream, to avoid unintentionally breaking
some code that relied on the malformed XML.
Temporary workaround for BZ#2026600
Problem with the GCC is already beeing discussed in upstream's Bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103395
This commit should be reverted when the GCC fixes the issue on their
side
The commented "Source0" line in the #7f8a0e15a commit raises RPMLint warnings.
While it is good to have the code without such warnings, the value of the clean revert of the whole #7f8a0e15a commit is higher.
The RPMLint warning for "macro in a comment" is meant for cases, when the macro in the comment would be expanded to multiple lines.
The additional lines won't be commented out as the original line with the unexpanded macros.
That leads to an unwated code execution.
The macro "%{version}" is a single line macro, so no real issue should arise here.
until it is packed properly
Undefined behaviour leads to the SE being built by default on systems that have the necessary devel package installed
Resolves: #1960161
The TokuDB SE from Percona upstream has been deprecated in MariaDB 10.5 and completely removed in MariaDB 10.6
In Fedora, we don't build it since MariaDB 10.5
Change the name of the sources archive, so the maintainer will encounter an error when uploading new sources which haven't undergo modification by this script
Prefer the systemctl edit mysql.service syntax
and leave the more complex alternatives to the
existing documents referenced.
Also show how to use the multiinstance a bit more.
MariaDB-10.4 onwards included a pam_helper subprocess to help
with the pam authentication module.
If the user is running with Galera there are SST modules that could
be executing.
By dropping KillMode=process this reverts back to control-group to
cover all of these subprocesses. This is what upstream does.
https://jira.mariadb.org/browse/MDEV-25233 suggests moving to
KillMode=mixed, which is probably ok too, but has been tested less.
Use mariadbd rather than mysqld in package descriptions.
Changed community branch of MySQL to "fork from", since branch
implies far too many updates from or back to the original
which isn't true.
Updated server-galera package description as it didn't
reference Galera at all.
---
Until now, we remove "mysql*" named upstream service files from the datadir, but leave the others.
IMO we should either ship them all or remove them all.
I see no benefit in keeping upstream service files, since they use different logic, capabilities, and starts scripts as root; unlike our downstream Systemd service files.
The patch was originally a copy of an upstream commit fixing this issue
Now the commit is a part of the server codebase
https://jira.mariadb.org/browse/MDEV-18737ddce859076
I stopped applying the patch with 10.5.0 release
Upstream issue:
https://jira.mariadb.org/browse/MDEV-19755
Upstream commit:
5cc2096f93 (diff-8576e5effae0770fc984e35e6749c43a8946489a1b478ce54facb3b9086622bf)
Scripts that rely on a specific driver won't work with differently named driver
Following scripts are affected:
mysql_convert_table_format.sh
mysql_setpermission.sh
mysqlhotcopy.sh
mytop.sh
as well as several tests for various components
So changing the required package to match the needs of the scripts
Testing:
Following command:
mysql_setpermission --user=root --host=127.0.0.1 --port=3306
Would fail with:
install_driver(MariaDB) failed: Can't locate DBD/MariaDB.pm in @INC (you may need to install the DBD::MariaDB module)
