Ignore check_stack_overrun function in optimization test in rpminspect
check.
This function is purposely not being optimized, to preserve a
stack variable creation.
--
Resolves: #2012938
The '%cmake' RPM macro in Fedora actually expands to:
| ...
| /usr/bin/cmake \
| -S "." \
| -B "redhat-linux-build" \
| ...
So in this case the source patch was specified twice.
First in the macro with the '-S' option and second time outside of the macro,
in the SPECfile, without the '-S' option.
CMake upstream declares that:
| This has never been officially documented or supported,
| but older versions accidentally accepted multiple source paths
| and used the last path specified. Update scripts to avoid
| passing multiple source path arguments.
https://cmake.org/cmake/help/v3.23/release/3.23.html#deprecated-and-removed-features
This was discovered as CMake upstream implemented a change to the 3.23.0-rc2 release
that changed this behavior and it broke many Fedora packages that used this
double source path definition.
See rhbz#2057738 to see how build behaved
After the CMake upstream got aware of what problems it caused in Fedora,
they opened a merge request to restore the behavior to the old one,
but kept the warnings that that is an unsupported and problematic behavior:
https://gitlab.kitware.com/cmake/cmake/-/issues/23334
---
As for today, this issue is still not yet fully resolved.
- The CMake maintainers in Fedora haven't rebased the package to 3.23-1 release, so it is still broken
- Affected packages in Fedora should find a way to stop using this unsupported behavior
- The double '-S' argument passing should be marked as problematic too, in the exact same way
https://gitlab.kitware.com/cmake/cmake/-/issues/23334#note_1159258
- A change to the %cmake Fedora RPM macro might be in play, so it won't force a source path
https://gitlab.kitware.com/cmake/cmake/-/issues/23334#note_1159258
I opened a BZ #2079833 to track the progress of the solution by CMake maintainers
--
Related: #2092370
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
--
Related: #2092370
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
--
Related: #2092370
Issues Fixed in MariaDB 10.5.14
Reolves: #2083371#2068219
Issues Fixed in MariaDB 10.5.15
Resolves: #2055607
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
Resolves: #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
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.
Undefined behaviour leads to the SE being built by default on systems that have the necessary devel package installed
Cherry-picked from Fedora: e96ef648dd
Related: #1971248
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
Cherry-picked from Fedora: f192442cc3
Related: #1971248
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
Cherry-picked from Fedora: 7f8a0e15a6
Related: #1971248
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.
Cherry-picked from Fedora: a87e9e5d9a
Related: #1971248
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.
Cherry-picked from Fedora: 95f558b833
Related: #1971248
