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.
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)
Related: #1903659
RPMDiff issue says:
File opt/rh/rh-mariadb105/root/usr/share/mysql-test/var is a dangling symlink (to /dev/shm/var_64_BuRk) on x86_64
In the CMake "CONFIGURE_FILE(<input> <output>)" command, the <input> path is treated relative to SOURCE dir, however the <output> patch is relative to BUILD dir.
Since the file has been copied to a wrong location, instead in-place updated as originally intended, the file that was later installed was the original unchanged file.
Resolves: #1873999, #1874446
Fix mariadb-pcdir.patch hunk
Since we do CMake out-of-source builds, and the SOURCE and BUILD directiories differ, the bug that was present in the patch started to cause a issues.
In the CMake "CONFIGURE_FILE(<input> <output>)" command, the <input> path is treated relative to SOURCE dir, however the <output> patch is relative to BUILD dir.
Since the file has been copied to a wrong location, instead in-place updated as originally intended, the file that was later installed was the original unchanged file.
Resolves: #1873999, #1874446
Force the CMake change regarding the in-source builds also to F31 and F32
Use CMake macros instead of cmake & make direct commands
%%cmake macro covers the %%{set_build_flags}, so they are not needed
Other changes to compile flags must be specified *after* the %%cmake macro
When rebuilding mariadb on EL7, I noticed that tokudb, mroonga, and
rocksdb were enabled, despite what this conditional appears to do.
After some experimentation, I can see that %ifarch does not support
appending another conditional with &&. To achieve the desired logic,
the statement must be separate conditionals.
The upstream now defaults to the location we need, although the server pkgconfig file location is still NOT configurable.
The CMake INSTALL_PCDIR option affects only the client library pkgconfig file location.
