fm-orchestrator

#1614 MBS produces different output than koji scratch build on SRPM rebuild; FTBFS
Opened by mschorm. Modified

Open
Close Issue

Hello,
I'm trying to get MariaDB 10.5 module into Fedora.

There already are MariaDB modules or previous major version. (= I know it works with different version)

The source for the RPM can be found in "rpms/mariadb" in "10.5" branch.
The source for the module can be found in "modules/mariadb" in "10.5" branch.

For now, the 10.5 module should be built only against Rawhide.

When I build from the "rpms/mariadb" from "10.5" branch, with:
# fedpkg --release=f33 build --scratch --srpm --arches=x86_64 --target=f33
command, the build succeeds without any issue:
https://koji.fedoraproject.org/koji/taskinfo?taskID=43394045
same in the COPR, which I used as a developement ground for the 10.5 version.

When built as a module, it will fail on mariadb component, on SRPM rebuild, as follows:
error: parse error in expression: %{__isa_bits} == 64 && 033
error: ^
error: /builddir/build/SPECS/mariadb.spec:1028: bad %if condition: %{__isa_bits} == 64 && 033
Building target platforms: noarch
Building for target noarch
Child return code was: 1
Here is the module build (and the failing task)
https://release-engineering.github.io/mbs-ui/module/8634/components
https://koji.fedoraproject.org/koji/taskinfo?taskID=43390726
https://koji.fedoraproject.org/koji/getfile?taskID=43390726&volume=DEFAULT&name=build.log

Does this error repeat?

The buildroot from the successful rebuildSRPM from the normal task is extremely similar to the buildroot from the failed buildSRPMFromSCM from the module build. The only differences are:

  • arch -- the successful one is aarch64, the failed one is x86_64
  • gnupg2 -- the failed one has a slightly older version, 2.2.19-1.fc32 vs 2.2.20-1.fc33
  • module-build-macros is present for the module build

module-build-macros does not alter the __isa_bit macro value

I'm wondering if there could be some subtle arch-specific breakage in the buildroot.

Yes, it is always reproducible.
I tired several times before reporting and just now I tried once more.

I know this would not solve the cause of the problem, but might be used for simplifying the SPEC -- the whole part of SPEC could be rewritten to:

 mv %{buildroot}/%{_lib}/security %{buildroot}%{_libdir}

I know this would not solve the cause of the problem, but might be used for simplifying the SPEC -- the whole part of SPEC could be rewritten to:
mv %{buildroot}/%{_lib}/security %{buildroot}%{_libdir}

I applied this workaround and it works well !

The modules are built now, but the issue itself remains.
The bright side is that is no longer blocks me.

If you want to reproduce, build the module from the last commit before I applied the fix:
https://src.fedoraproject.org/rpms/mariadb/c/04c626f762ac022ad8db57ce9631e5f5fc9e89db?branch=10.5

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/mbs/issues/1614

Please continue any further discussion there.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.