#8657 `fedpkg module-build` fails with "The modulemd libreoffice.yaml is invalid. Please verify the syntax is correct." upon buildopts: arches: [x86_64]
Opened a month ago by sbergmann. Modified a month ago

As described at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EZYHCXDYHOCYYMBL572FQSBSE7PKEH3U/ "Who maintains the service at mbs.fedoraproject.org:443?":

I am trying to do a build of LibreOffice from Fedora RPMs (à la https://docs.fedoraproject.org/en-US/flatpak/), but fedpkg module-build keeps failing with "The modulemd libreoffice.yaml is invalid. Please verify the syntax is correct." after https://src.fedoraproject.org/flatpaks/libreoffice/c/6aad9bd0db5a067c71a0dcfbc27185466fc3a7dc?branch=master "Restrict builds to x86_64".

Judging from strace and what little information the --verbose option of fedpkg provides, it looks like that error message is reported back from mbs.fedoraproject.org:443. Could it be that that installation is missing https://github.com/fedora-modularity/libmodulemd/commit/c54a0fff7ece446603835464a394a3f854408e47 "Add support for new ModulemdBuildopts arches attribute"?


Metadata Update from @smooge:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: mbs, releng

a month ago

@merlinm @sgallagh @otaylor Any insight?

That patch is for libmodulemd2? would that need to be on the mbs backend host or in the build?

This option is not currently supported in MBS - see https://pagure.io/fm-orchestrator/issue/1557 (it doesn't look like a big project to implement)

There might be a workaround - if the MBS configuration was changed to add 'libreoffice' to the configuration key: ALLOWED_PRIVILEGED_MODULE_NAMES, then arches could be configured as:

xmd:
mbs:
koji_tag_arches: ["x86_64"]

There's nothing very dramatic you can do as a "privileged module" that I can I see - it allows overriding the arches and changing the disttag, so this is probably OK - and libreoffice is definitely "special" in the size of the module - we don't need to do this for every Flatpak module.

"if the MBS configuration was changed to add 'libreoffice' to the configuration key: ALLOWED_PRIVILEGED_MODULE_NAMES"

Whom to ping for that? (I assume the relevant people are already subscribed to this issue?) A solution here would substantially improve turnaround times for me in development.

"if the MBS configuration was changed to add 'libreoffice' to the configuration key: ALLOWED_PRIVILEGED_MODULE_NAMES"

Whom to ping for that? (I assume the relevant people are already subscribed to this issue?) A solution here would substantially improve turnaround times for me in development.

I'd check with @mohanboddu - he's made most of the changes to the MBS configuration recently.

Mohan - do you think it's OK if we special case libreoffice this way?

Metadata Update from @mohanboddu:
- Issue assigned to mohanboddu

a month ago

ALLOWED_PRIVILEGED_MODULE_NAMES is not what is needed here. That is for special modules that can influence the architectures that a module is built for when that special module is buildrequired. This was added for RHEL layered product modules and is not applicable in Fedora.

The module build is failing because the version of libmodulemd is too old on the MBS servers, so libmodulemd thinks your modulemd is invalid. Even if you updated libmodulemd, MBS would just ignore the arch restriction since it does not yet support that part of the modulemd specification.

@breilly has a PR open for that at:
https://pagure.io/fm-orchestrator/pull-request/1593

Please work with @breilly and @mikem to get support for this. They are the MBS maintainers.

@mprahl - do you mean that it woudn't work, or that it's not the right way to do this? I've put enough roadblocks in the way of @sbergmann getting Libreoffice built as a Flatpak, that if there's a way to make things easier for him, I'd like to do that without blocking on getting MBS enhancements deployed in Fedora. :-) I reviewed the patch you linked to and added some comments.

@otaylor I mean that it wouldn't work. The work-around without the enhancement in the PR I linked is to set ExclusiveArch on every modular component which is a terrible experience. Our best best is to update libmodulemd and update MBS in Fedora with just that patch once it's merged.

sbergmann got libreoffice built by the way, see https://koji.fedoraproject.org/koji/packageinfo?packageID=11024

Yes, a first cut is done. Which means that this issue is currently of less importance to me. (What seems to have helped is that once there were successful builds of all the dependency components, subsequent changes apparently reused existing builds of those components that were not affected by the changes. The last few builds that it took me to get to a working flatpak felt quicker than the previous ones and went more smoothly.)

However, I suspect that the issue would reappear in the future, e.g. when doing a LibreOffice flatpak build based on F32 instead of F31.

Login to comment on this ticket.

Metadata