Created attachment 1704382 [details]
build.log

file build.log too big, will only attach last 32768 bytes

Created attachment 1704383 [details]
root.log

file root.log too big, will only attach last 32768 bytes

Created attachment 1704384 [details]
state.log

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Looking closely at https://koschei.fedoraproject.org/package/galera?last_seen_ts=1596401356&collection=f34
And trying to downgrade check to check-0.15.0-2.fc33.x86_64, it fixes the build issue.

An example of the compilation issue:

galera/tests/data_set_check.cpp:139:14: error: too many arguments for format [-Werror=format-extra-args]
  139 |              "expected: %zu, got %zu", offset, dset_out.size());
      |              ^~~~~~~~~~~~~~~~~~~~~~~~

The relevant code is:

fail_if (dset_out.size() != offset,
             "expected: %zu, got %zu", offset, dset_out.size());

And it looks correct. However, further investigation revealed these issues:
https://github.com/libcheck/check/issues/293 that led to this change in check-0.15.1 and further in check-0.15.2:
https://github.com/libcheck/check/commit/7ac1fcbcefe8813e2a75388ec61e20a184ddc8c8
https://github.com/libcheck/check/pull/298/commits/82540c5428d3818b64d6a8aefb601e722520651f

where we can read:
"""
A fix proposed by heftig in github.com//issues/293
is to add a new NULL to the end of every fail* call in the macro
itself. For users of these APIs who do pass a message there will
be a new warning about too many arguments. As the fail APIs are
deprecated, this new warning is a reasonable trade-off, and can
be avoided by switching fail* calls to ck_assert* calls.
"""

So, I believe the correct thing to do is to fix all `fail_if` and `fail_unless` calls with respective ck_assert calls.

Reported upstream, although we need to do something about this in Fedora soon: https://github.com/codership/galera/issues/577

Looking at upstream releases cadence and recent github activity, it is not clear when the update from upstream might come. Any idea whether there is gonna be an upstream patch at least? If not, we need a back-up plan, as we cannot have FTBFS component for long time.

Actually, what upstream do we talk about? I always considered https://github.com/codership/galera/ but maybe we should rather talk to mariadb folks?

We take sources from MariaDB upstream.
MariaDB takes the sources from Galera upstream and patches them to work best with MariaDB. (galera is originally developed to run with MySQL)

Apart from the patch for MariaDB datbase, the MariaDB upstream are IMHO not that big contributors to galera developement.
Such fix is IMHO correctly discussed directly on the galera upstream.

I exptect, that once the patch is ready, we should be able apply it downstream without much issues.

New Galera releases aren't much frequent, though.

---

There might be another way to fix the FTBFS state - which is to revert the part of the Fedora behaviour that caused this change.
Not if this is possible, but if the fix won't be developed fast enough on the uspteram side, this might be a good way to go.

FEDORA-2020-849d654bb6 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-849d654bb6

FEDORA-2020-849d654bb6 has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-849d654bb6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-849d654bb6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-249023a94d has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-249023a94d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-249023a94d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-849d654bb6 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-249023a94d has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.