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.
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.
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.