Downstream issue: https://pagure.io/fedora-infrastructure/issue/8657
So I retried a fresh test build of the LibreOffice flatpak with https://src.fedoraproject.org/flatpaks/libreoffice/c/db8cf4befde9af854f4f4194a34beba95c7b22a9?branch=stable "Revert 'Revert 'Restrict builds to x86_64''" now, but fedpkg module-build still fails (https://mbs.fedoraproject.org/module-build-service/2/module-builds/12305), now with
[Build #12305] libreoffice-stable-3420210629113934-dab6ca4c is in "init" state. Koji tag: None Link: https://mbs.fedoraproject.org/module-build-service/2/module-builds/12305 [Build #12305] libreoffice-stable-3420210629113934-dab6ca4c is in "failed" state. Components: 0 done, 0 failed Reason: modulemd-error-quark: Could not validate stream to emit: Component rpm 'hyphen-pl' arch 'aarch64' not in module buildopts.arches (1)
My reading of the infra issue:
It appears that libreoffice flatpaks have been building successfully since August. This is because they've dropped the buildopts from their yaml. I see a series of flip-flopped reversions since Feb 2020.
The error here is coming from libmodulemd itself, in modulemd_module_stream_validate_component_rpm_arches which "iterate[s] through rpm components and verif[ies] that any arches specified are a subset of the module level arches"
modulemd_module_stream_validate_component_rpm_arches
I was able to replicate the issue by adding the buildopts back in on a private branch. Link:
https://mbs.fedoraproject.org/module-build-service/2/module-builds/13406
In MBS, the traceback looks like:
Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/module_build_service/scheduler/handlers/modules.py", line 213, in init build.modulemd = mmd_to_str(mmd) File "/usr/lib/python2.7/site-packages/module_build_service/common/utils.py", line 222, in mmd_to_str return to_text_type(index.dump_to_string()) Error: modulemd-error-quark: Could not validate stream to emit: Component rpm 'hyphen-pl' arch 'aarch64' not in module buildopts.arches (1)
This is on the backend, where we have: module-build-service-3.6.1-2.el7.infra.noarch python2-libmodulemd2-2.13.0-2.el7.x86_64 libmodulemd-1.6.3-1.el7.x86_64 libmodulemd2-2.13.0-2.el7.x86_64
@mcurlej is this the expected libmodulemd behavior here?
Libreoffice appears to be the only package that has hit this error, but it's possible it is also the only package using buildopts.arches
The reason that modulemd_module_stream_validate_component_rpm_arches() is complaining is the code in module_build_service/scheduler/submit.py.format_mmd():
for pkgname in mmd.get_rpm_component_names(): [...] if not pkg.get_arches(): for arch in conf.arches: pkg.add_restricted_arch(arch)
So MBS is creating a modulemd file that restricts the components more broadly than the whole build.
It would be entirely possible to consider such a modulemd file to be valid - with the meaning that the component should be built with the intersection of the arches (@mikem's question to @mcurlej) [*] - but MBS, in this case, is simple reating such a file by mistake. It should be a small patch to format_mmd() to get the list of arches to set from the component from module.arches rather than conf.arches
[*] Note that setting component.arches doesn't even work, at least according to code in KojiModuleBuilder
# disabled by default, wouldn't work until Koji issue #1158 is done if conf.allow_arch_override: build_opts["arch_override"] = self.mmd.get_rpm_component(artifact_name).get_arches()
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/koji/mbs/issues/1734
Please continue any further discussion there.