Enabled more testsuite parallelization
I've tested that the builders will not deplete resources for this value
New bug discovered: #2165809
"Testsuite suite 'query_rewrite_plugins' fails on Fedora 38 and later"
Dissable running the testuite in memory to workaround OOM problem.
Disable testsuite parallelization to allow tests to pass on ppc64le too.
These issues are believed to originate in Koji build system and are present
mainly in the Rawhide (F38) buildroot.
F36 buildroot seems to be most stable out of the current ones.
In one of the previous commits, I've started to pack a different logrotate file
as it contains the correct path to the logfile of the mysql server.
It has been found, that I've overlooked that the filepath to the mysql server
was still set wrongly.
It was set to a: '/var/log/mysqld.log'
Instead of expected: '/var/log/mysql/mysql.log'
This path is added to the mysql logrotate configuration file via CMAKE variable
substitution.
However since we haven't specify the variable value,
a default value has been used instead.
The fix to this issue was simple - specify the variable value as the CMAKE
command argument.
--
At the same time, we were using a custom (downstream) variable meant to hold
the same information. We used this variable for generating the correct filepath
to the mysql server logfile in the mysql server configuration file.
Instead of using two different CMAKE variables with the same meaning,
I've changed it so we get rid of the downstream specified variable
and use the upstream specified variable instead.
--
The positive effect is the de-duplication of code and assurance that when we
set the value, it is used everywhere - both in the upstream code and in the
downstream patches.
The tiny negative effect is that at this moment, the names of the variables
differ to the we use in 'mariadb' package.
The sources contains two versions of the logrotate file:
* mysql-8.0.30/support-files/mysql-log-rotate.in
* mysql-8.0.30/packaging/rpm-common/mysql.logrotate.in
Until now, the first one was used. However logfile location
specified in that logrotate configuration file was wrong.
( /var/lib/mysql/mysqld.log )
From now on, we will use the second one, which is meant to be
used in RPM packages, and which respects their FSH layout.
( /var/log/mysql/mysqld.log )
--
As a side-effect, the whole configuration is now commented out.
So users now need to touch the file before they can start using it.
However once the configuration is un-commented,
it will work out-of-the-box (unlike until now).
--
Resolves: #2073434
The full testsuite has been run multiple times on multiple
Fedora releases, thus updating the "last_tested_version"
Note: the additional failing tests on s390x are NOT OpenSSL 3 related
This is usefull for Fedora Module builds, where a module build
for N Fedora releases is done from a single commit or a branch.
In the case of the 'mysql' module (from rpms/mysql repository)
we currently reference a single commit.
This change takes some pieces from MariaDB, including compat_ssl.h and
changes in my_md5.cc.
MySQL utilizes FIPS_mode() and FIPS_mode_set() functions that are not
available in OpenSSL 3.x any more. This patch only mocks the call of
those functions, returning 0 every time, which effectively makes usage
of those functions non working. For making the MySQL build with
OpenSSL 3.x this seems to be enough though.
---
This commit has been cherry-picked from CentOS Stream 9
51e2abe584
and adjusted to be applicable to Fedora Rawhide
Once the full testsuite has been run for the particular MySQL release; execute just the "main" suite on subsequent runs for that release.
The implementation default to running of the whole testsuite, as until now, if the maintainer won't set the flag that running of the minimal testsuite is enough for this release.
This feature aims to help with faster and more stable package builds when adding small fixes on top of already tested release;
and to ease the life of Fedora Linux Release Engineers during (mass) rebuilds.
