`fedpkg module-build` fails with "The modulemd libreoffice.yaml is invalid. Please verify the syntax is correct." upon buildopts: arches: [x86_64]

sbergmann commented

2020-02-17 12:52:01 +00:00

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"?

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"?

smooge commented

2020-02-17 19:06:11 +00:00

Metadata Update from @smooge:

Issue priority set to: Waiting on Assignee (was: Needs Review)
Issue tagged with: mbs, releng

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

kevin commented

2020-02-18 21:55:48 +00:00

@merlinm @sgallagh @otaylor Any insight?

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

@merlinm @sgallagh @otaylor Any insight? That patch is for libmodulemd2? would that need to be on the mbs backend host or in the build?

otaylor commented

2020-02-26 15:09:46 +00:00

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.

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.

sbergmann commented

2020-02-28 08:19:09 +00:00

Author

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

otaylor commented

2020-02-28 14:56:40 +00:00

"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?

> "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?

mohanboddu commented

2020-03-03 19:24:26 +00:00

Metadata Update from @mohanboddu:

Issue assigned to mohanboddu

**Metadata Update from @mohanboddu**: - Issue assigned to mohanboddu

mprahl commented

2020-03-04 18:45:59 +00:00

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.

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

otaylor commented

2020-03-04 20:45:02 +00:00

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

kalev commented

2020-03-04 20:47:09 +00:00

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

mprahl commented

2020-03-04 22:06:33 +00:00

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

@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 commented

2020-03-04 22:25:38 +00:00

Author

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.

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

kevin commented

2020-04-09 18:08:59 +00:00

Whats the status here? Should we just close this and when mbs updates next it should be fixed? or?

sbergmann commented

2020-04-14 07:39:34 +00:00

Author

Whats the status here? Should we just close this and when mbs updates next it should be fixed? or?

In which case I would appreciate it if you would only close this issue once it is supposed to be fixed, or let me know through some other channel once it is supposed to work. I am still eager to do whatever is necessary to build the LibreOffice flatpak only for x86_64 and thereby improve build reliability and turnaround time.

> Whats the status here? Should we just close this and when mbs updates next it should be fixed? or? In which case I would appreciate it if you would only close this issue once it is supposed to be fixed, or let me know through some other channel once it is supposed to work. I am still eager to do whatever is necessary to build the LibreOffice flatpak only for x86_64 and thereby improve build reliability and turnaround time.

cverna commented

2020-05-27 08:13:49 +00:00

Metadata Update from @cverna:

Assignee reset

**Metadata Update from @cverna**: - Assignee reset

smooge commented

2020-12-02 19:23:44 +00:00

Metadata Update from @smooge:

Issue priority set to: Waiting on External (was: Waiting on Assignee)
Issue tagged with: dev, medium-gain, medium-trouble

**Metadata Update from @smooge**: - Issue priority set to: Waiting on External (was: Waiting on Assignee) - Issue tagged with: dev, medium-gain, medium-trouble

pingou commented

2020-12-03 09:03:42 +00:00

I'm going to remove "dev" from this ticket as this isn't something we can do, it needs dev for sure but not one we can provide (and I'd like to remove the ticket from the dev board since we can't actually work on it).

pingou commented

2020-12-03 09:03:49 +00:00

Metadata Update from @pingou:

Issue untagged with: dev

**Metadata Update from @pingou**: - Issue **un**tagged with: dev

asaleh commented

2021-06-29 10:29:34 +00:00

@sbergmann I have noticed https://pagure.io/fm-orchestrator/pull-request/1593 has been merged which should alleviate the issue and I checked we have the version with those improvement deployed. Is that correct? Or is there something else we need to do?

sbergmann commented

2021-06-29 11:49:05 +00:00

Author

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)

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) ```

kevin commented

2021-06-29 14:51:45 +00:00

Perhaps @breilly could look?

kevin commented

2021-11-04 17:27:06 +00:00

Refiled upstream at https://pagure.io/fm-orchestrator/issue/1734

We will track it there and when they have a solution, deploy it.

Refiled upstream at https://pagure.io/fm-orchestrator/issue/1734 We will track it there and when they have a solution, deploy it.

kevin commented

2021-11-04 17:27:07 +00:00

Metadata Update from @kevin:

Issue close_status updated to: Upstream
Issue status updated to: Closed (was: Open)

**Metadata Update from @kevin**: - Issue close_status updated to: Upstream - Issue status updated to: Closed (was: Open)

Rows
Columns

fedpkg module-build fails with "The modulemd libreoffice.yaml is invalid. Please verify the syntax is correct." upon buildopts: arches: [x86_64] #8657

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