subunit-1.3.0-10.fc31 fails to build in F31 because of mismatch in noarch packages: BuildError: The following noarch package built differently on different architectures: python2-subunit-1.3.0-10.fc31.noarch.rpm rpmdiff output was: removed PROVIDES python-subunit(x86-64) = 1.3.0-10.fc31 added PROVIDES python-subunit(aarch-64) = 1.3.0-10.fc31 It seems the "%{?python_provide:%python_provide python2-%{name}}" macro call does not take into account that python2-%{name} is a noarch package.
Updating rpm-build from 4.14.2.1-10.fc31 to 4.14.90-0.git14653.13 looks suspicious.
Yeah, rpm >= 4.14.90 no longer defines macros for various tags where it doesn't make sense, BuildArch: being one of them, see https://github.com/rpm-software-management/rpm/issues/689 That said I can see a legitimate use-case of knowing the "current" architecture of a package, but the buildarch macro as it existed is not generally meaningful for that purpose. Unfortunately it seems to be used in the extremely commonly used %python_provide macro, so we might need to temporarily revert the upstream change for buildarch while we figure out how to properly address the issue.
%buildarch macro re-enabled for the time being as of rpm-4.14.90-0.git14653.15.fc31. Reassigning to rpm for further action, this is strictly between rpm and rpm-python-macros and subunit is just an innocent victim.
For the record, the (architecture) part was removed from %python_provide, see bz1705656.
Okay, lets consider the case closed then, there are more pressing matters to deal with.