#1734 modulemd-error-quark: Could not validate stream to emit: Component rpm 'hyphen-pl' arch 'aarch64' not in module buildopts.arches (1)
Opened by kevin. Modified

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:

  • in early 2020, libreoffice builds were failing because mbs did not support the buildopts.arches field
  • also the installed libmodulemd was too old
  • the first was fixed in PR #1593 (merged May 2021)
  • MBS v3 we deployed to Fedora in that timeframe
  • In late June 2021, sbergman retried a build, but got a different error (Component rpm 'hyphen-pl' arch 'aarch64' not in module buildopts.arches)

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"

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.

Metadata