Bug 1729985 - Cannot make buildopts work
Summary: Cannot make buildopts work
Alias: None
Product: Fedora
Classification: Fedora
Component: module-build-service
Version: 30
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Ralph Bean
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2019-07-15 13:39 UTC by Milan Crha
Modified: 2019-08-06 13:39 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-08-06 12:50:56 UTC
Type: Bug

Attachments (Terms of Use)

Description Milan Crha 2019-07-15 13:39:14 UTC
I'm trying to influence how certain package should be built in a PROJECT.yaml file using the buildopts directive [1] (or whatever is the right terminology for it), but I cannot reference the added macro in the rpm .spec file for some reason. I have it very similarly as in the SPEC [2], but still nothing.

This is with libmodulemd-2.5.0-1.fc30.x86_64 (eventually libmodulemd1-1.8.11-1.fc30.x86_64, whichever is used).

I have this in my yaml file:

document: modulemd
version: 2
      macros: |
        %demomacro 3
        %eds_dbus_services_prefix org.gnome.Evolution

And in one of the rpm spec files this:

echo "dbusnamesprefix:%{?eds_dbus_services_prefix}|%{eds_dbus_services_prefix}|%{?demomacro}|%{demomacro}|"
%if 0%{?eds_dbus_services_prefix} == 0
	exit 1

and it always fails (the 'exit 1' is triggered), and the output on the stderr from the rpm build is:

DEBUG: dbusnamesprefix:|%{eds_dbus_services_prefix}||%{demomacro}|
DEBUG: RPM build errors:
DEBUG: + echo 'dbusnamesprefix:|%{eds_dbus_services_prefix}||%{demomacro}|'
DEBUG: + exit 1

I guess I do something wrong (I do not mean the second try of the macro expansion reference without the question mark), but I do not know what it is.

[1] https://modulemd.readthedocs.io/en/latest/modulemd.buildopts.html#module-modulemd.buildopts
[2] https://github.com/fedora-modularity/libmodulemd/blob/master/spec.v2.yaml#L217

Comment 1 Milan Crha 2019-07-15 13:58:12 UTC
A usability side note: what would be really interesting is a buildopts per package build, not global buildopts. I know it's out of scope of this bug report, I'm only mentioning it here.

Comment 2 Stephen Gallagher 2019-07-15 14:41:14 UTC
How are you performing the build? Is this something you're submitting through MBS (which should handle this itself) or are you attempting to reimplement the behavior in COPR?

libmodulemd doesn't do anything special with buildopts itself; it's just a lookup mechanism that MBS uses to find the macros. From libmodulemd's perspective, it's just an arbitrary string.

Comment 3 Milan Crha 2019-07-15 15:50:48 UTC
This is when trying to rpm2flatpak the evolution package. I just call:

   $ flatpak-module local-build --install

which (I believe) calls internally:

   $ mbs-manager build_module_locally --file evolution.yaml --stream master

Comment 4 Milan Crha 2019-07-15 16:39:09 UTC
(In reply to Milan Crha from comment #3)
> which (I believe) calls internally:
>    $ mbs-manager build_module_locally --file evolution.yaml --stream master

I just verified that running the above command fails in the same way as when running the flatpak-module command mentioned in the previous comment.

Comment 5 Stephen Gallagher 2019-07-15 18:13:21 UTC
Reassigning this to MBS.

Comment 6 Matt Prahl 2019-07-16 16:58:31 UTC
I filed a ticket for this in Pagure since that's where we track issues that aren't packaging related.

Comment 7 Milan Crha 2019-08-06 12:50:56 UTC
It turned out the problem was on my side, of course. You can close the upstream bug (I do not see a button to close it myself). More info is there. Thanks and I'm sorry for a false report.

Note You need to log in before you can comment on or make changes to this bug.