The 'mariadb-fips.patch' patch has to be applied conditionally. It will FTBFS on releases without OpenSSL 3.
---
/builddir/build/BUILD/mariadb-10.5.15-downstream_modified/mysys_ssl/my_md5.cc: In function 'void md5_init(EVP_MD_CTX*)':
/builddir/build/BUILD/mariadb-10.5.15-downstream_modified/mysys_ssl/my_md5.cc:56:9: error: 'EVP_MD_fetch' was not declared in this scope; did you mean 'EVP_MD_flags'?
56 | md5 = EVP_MD_fetch(NULL, "MD5", "fips=no");
| ^~~~~~~~~~~~
| EVP_MD_flags
/builddir/build/BUILD/mariadb-10.5.15-downstream_modified/mysys_ssl/my_md5.cc:63:3: error: 'EVP_MD_free' was not declared in this scope; did you mean 'EVP_MD_type'?
63 | EVP_MD_free(md5);
| ^~~~~~~~~~~
| EVP_MD_type
gmake[2]: *** [mysys_ssl/CMakeFiles/mysys_ssl.dir/build.make:149: mysys_ssl/CMakeFiles/mysys_ssl.dir/my_md5.cc.o] Error 1
Logrotate patch rebased onto upstream commit:
008c02c987
Groonga patch upstreamed:
045f5f7b10
OpenSSL 3 patch rebased onto upstream commit:
be1d965384
OpenSSL 3 CMake condition reverted - it should be only applied to series without OpenSSL 3 patch:
c9beef4315
Full testsuite success on a Fedora Rawhide scratch build,
setting "last_tested_version" to 10.5.15 so only the "main" test suite will be run on subsequent
builds of the same MariaDB release
OpenSSL 3.0.0+ does not support EVP_MD_CTX_FLAG_NON_FIPS_ALLOW any longer.
In OpenSSL 1.1.1 the non FIPS allowed flag is context specific, while
in 3.0.0+ it is a different EVP_MD provider.
Resolves: #2050541
This issue was originally discovered by Annocheck stack-protection test in RHEL 9: #2044388
The -DSECURITY_HARDENED is used to force a set of compilation flags for hardening
The issue is that the MariaDB upstream level of hardening is lower than expected by Red Hat
We disable this option to the default compilation flags (which have higher level of hardening) will be used
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
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.
Michal Schorm
Honza Horak
Fedora Release Engineering
Lukas Javorsky
Sahana Prasad
Marek Kulik
Daniel Black
Jonathan Wakely
Zbigniew Jędrzejewski-Szmek