Upgrade mariadb to version 10.11.19

[Sumit Jena (SumitJenaHCL)]

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• The toolchain has been rebuilt successfully (or no changes were made to it)
• The toolchain/worker package manifests are up-to-date
• Any updated packages successfully build (or no packages were changed)
• Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• All package sources are available
• cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• LICENSE-MAP files are up-to-date (./LICENSES-AND-NOTICES/SPECS/data/licenses.json, ./LICENSES-AND-NOTICES/SPECS/LICENSES-MAP.md, ./LICENSES-AND-NOTICES/SPECS/LICENSE-EXCEPTIONS.PHOTON)
• All source files have up-to-date hashes in the *.signatures.json files
• sudo make go-tidy-all and sudo make go-test-coverage pass
• Documentation has been updated to match any changes to the build system
• Ready to merge

---

Summary

What does the PR accomplish, why was it needed?

This PR upgrades the mariadb package from 10.11.18 to 10.11.19.

Two downstream patches needed rebasing because upstream 10.11.19 rewrote the surrounding
context, and one orphaned patch file was removed:

• mariadb-logrotate.patch — upstream replaced the documentation-URL comment lines that
  form the context of hunk 1 (mariadb.com/kb/en/... -> mariadb.com/docs/server/...). The
  functional change is untouched; only context drifted. This is invisible to a default
  patch run (fuzz=2) but fails under rpmbuild, which applies patches with --fuzz=0.

• mariadb-libfmt.patch — 10.11.19 replaced the literal fmt archive URL in
  cmake/libfmt.cmake with a compiler-conditional SET(source URL ...) block selecting fmt
  11.0.2 for gcc < 4.9 and fmt 12.2.0 otherwise. Azure Linux builds with gcc 13, so only the
  latter branch is redirected to the pre-downloaded archive, and fmt_bundled_version moves
  11.0.2 -> 12.2.0 to match. This path is dormant (bundled_fmt is off) but is kept
  self-consistent. Upstream references:

  • 10.11.18 — literal URL:
    https://github.com/MariaDB/server/blob/mariadb-10.11.18/cmake/libfmt.cmake#L18-L19
  • 10.11.19 — new conditional block (upstream comments the 11.0.2 branch as
    "it's for RHEL-7, gcc 4.8.5"):
    https://github.com/MariaDB/server/blob/mariadb-10.11.19/cmake/libfmt.cmake#L15-L23
  • fmt 12.2.0 release archive selected by the ELSE() branch:
    https://github.com/fmtlib/fmt/releases/tag/12.2.0

• mariadb-ssl-cypher.patch — removed. The file was present on disk but never declared
  via a PatchN: tag nor applied in %prep, so it was dead weight. It is an undeclared
  orphan in Fedora's package as well.

Both rebases were confirmed to be upstream drift rather than downstream error: Fedora's own
copies of these two patches fail on the 10.11.19 tree at the identical hunks.

Patch inventory was reconciled in both directions — all 6 declared patches exist and apply at
--fuzz=0, and no orphan .patch files remain. This package carries no CVE backport patches.

Fedora alignment. Fedora tracks the 10.11 LTS stream as the separate mariadb10.11
component (rawhide's mariadb is 11.8); its newest build is 10.11.18, so this package is one
release ahead and there is no Fedora 10.11.19 spec to reference. Patch numbering matches on all
shared patches (4/7/9/13/14) and 16 shared support files are byte-identical. Fedora's two extra
patches are correctly absent here: Patch15 marks RISC-V64 as 64-bit (not an Azure Linux
architecture), and Patch16 (MDEV-39691) is already included in 10.11.19, verified by
reverse-applying it against the release tarball.

Change Log

• SPECS/mariadb/mariadb.spec — bump to 10.11.19-1, fmt_bundled_version 11.0.2 -> 12.2.0, changelog
• SPECS/mariadb/mariadb.signatures.json — new source hash
• SPECS/mariadb/mariadb-logrotate.patch — rebased onto 10.11.19 context
• SPECS/mariadb/mariadb-libfmt.patch — rebased onto upstream's new conditional fmt selection
• SPECS/mariadb/mariadb-ssl-cypher.patch — removed (never declared or applied; orphan file)
• cgmanifest.json — mariadb 10.11.18 -> 10.11.19

Does this affect the toolchain?

NO

Associated issues

• #xxxx

Test Methodology

• Local build via the toolkit with RUN_CHECK=y: built SRPMs 1, passed SRPMs tests 1,
  failed SRPMs 0, failed SRPMs tests 0. The %check section (MTR suite) executed and passed;
  12 RPMs were produced.
• Buddy Build URL - https://dev.azure.com/mariner-org/mariner/_build/results?buildId=1190807&view=results

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Sumit Jena (SumitJenaHCL)]

Breaking Changes Analysis — mariadb 10.11.18 → 10.11.19

Verdict: no breaking changes for consumers or operators. One config file is modernised, and the server plugin API has source-incompatible edits that affect nobody in this distro. Method: diffed the actual built RPMs against the shipped 10.11.18 binaries from PMC, plus the 336-commit upstream delta.

Surface	Result
RPM file lists	identical — 0 added, 0 removed, all 3 packages
Provides / Requires	identical (beyond version)
Server plugin set	41 → 41, none added or removed
mariadbd linked libraries	11 → 11, identical set
Public headers	445 → 445, none added or removed
Plugin interface versions	unchanged — 0x0104 / 0x010f
Config files	3 changed (2 cosmetic, 1 substantive)
systemd units	4 changed, cosmetic only

1. Packaging — zero delta

mariadb-server, mariadb, mariadb-devel all show empty diffs on file lists, Provides, and Requires. No file moved, no subpackage boundary shifted, no dependency added or dropped. Sizes moved <0.5% (e.g. server 26,221,317 → 26,273,468 bytes).

2. Config files

Two are pure comment churn — part of upstream's site-wide mariadb.com/kb/en/… → mariadb.com/docs/server/… doc migration (the same migration that broke mariadb-logrotate.patch):

• enable_encryption.preset
• spider.cnf

One is substantive — galera.cnf, from MDEV-39691:

-# enable "strictly synchronous" semantics for read operations
-wsrep_causal_reads=0
+# Syncronization causality setting, (0 - disabled)
+# same as deprecated and removed wsrep_causal_reads=0.
+wsrep_sync_wait=0

I checked whether this actually breaks existing Galera clusters, and it does not. galera.cnf is %config(noreplace) (mariadb.spec:1483), so existing installs keep their file and receive the new one as .rpmnew. That would only matter if wsrep_causal_reads had been removed from the server — and strings on both mariadbd binaries shows the symbol present in both 10.11.18 and 10.11.19. It remains a deprecated alias. Upstream's "deprecated and removed" comment refers to removal from the shipped config, not from the server.

Net: new installs get the modern variable; existing clusters keep working unchanged.

3. systemd units — cosmetic only

Four socket units differ (mariadb.socket, mariadb@.socket, mariadb-extra.socket, mariadb-extra@.socket). Every hunk is either the version string in Description= or a Documentation= URL. No ExecStart, ordering, or dependency changes.

4. Client API — additive, non-breaking

mysql.h and errmsg.h are byte-identical. mysql_com.h gains three lines, all additive:

/* Bits: NET_PROXY_PROTOCOL, NET_PROXY_PROTOCOL_CONNECT_ERRORS */
#define NET_PROXY_PROTOCOL 1
#define NET_PROXY_PROTOCOL_CONNECT_ERRORS 2

Nothing removed or redefined — existing client code compiles and links unchanged.

5. Server plugin API — source-incompatible edits (no impact here)

42 headers changed functionally; 339 of the 445 live under server/private/, explicitly internal. Two are genuine source breaks:

json_lib.h — struct field type change, from MDEV-28404 / MDEV-30518 ("JSON functions don't respect KILL QUERY"):

- volatile uchar    *killed_ptr;
+ volatile const uint32_t *killed_ptr;

Also adds JE_KILLED = -8 and json_valid_engine().

my_sys.h — macro renamed (same value 0x20000U), from "generalize ROOT_FLAG_MPROTECT to work on Windows, rename accordingly":

- #define MY_ROOT_USE_MPROTECT 0x20000U
+ #define MY_ROOT_USE_VMEM     0x20000U

Anything referencing MY_ROOT_USE_MPROTECT or assigning to killed_ptr fails to compile. But both plugin interface versions are unchanged, and MariaDB's server plugin API is explicitly not a stable cross-release ABI — out-of-tree engines rebuild per version regardless.

6. Reverse dependencies — none affected

Four packages BuildRequires: mariadb-devel: cyrus-sasl, apr-util, sysbench, bind. All four are client-side consumers (SASL auth backend, APR DBD driver, benchmark driver, BIND DLZ backend) — none includes server/private/ headers, and the client surface is additive-only.

Also relevant: mariadb-devel ships no libraries at all here (my library scan came back empty — AzL builds %{without clibrary}, so linking goes to mariadb-connector-c), and the spec does rm %{buildroot}%{_libdir}/*.a, so there is no static linkage. No Release bumps are required for dependents.

7. Behavioural changes worth knowing

336 commits / 300 files. Almost entirely crash, UBSAN/ASAN, and correctness fixes. The one real behaviour change:

MDEV-40589 — secure_file_priv now excludes proc. The default value is unchanged (DEFAULT(0)); what changed is that with an empty secure_file_priv, proc is now off-limits to LOAD DATA, SELECT … OUTFILE, and LOAD_FILE(). Upstream documents it in the help text: "Empty value means no limits except /proc". This is security hardening, but it is a behaviour change — anything reading proc via LOAD_FILE() with an unrestricted secure_file_priv will now fail.

Other notables, all fixes rather than breaks: MDEV-25817 (proxy protocol no longer resets connect errors on successful login), MDEV-40648 (malformed Rotate event UB in replication), MDEV-39841 (handlersocket empty default secret), MDEV-31808 / MDEV-38472 (crash fixes).

Risk assessment

Audience	Risk	Note
Client apps / the 4 dependents	None	additive client API, no static linkage
Operators (standalone)	None	no config, unit, or default changes affecting them
Operators (Galera)	Very low	.rpmnew only; old variable still accepted
LOAD_FILE() on proc	Low	now blocked when secure_file_priv is empty
Out-of-tree plugin authors	Low–Medium	rebuild needed; two source-level fixups

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.