Bug 1729985

Summary: Cannot make buildopts work
Product: [Fedora] Fedora Reporter: Milan Crha <mcrha>
Component: module-build-serviceAssignee: Ralph Bean <rbean>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 30CC: cqi, fvalder, jkaluza, mprahl, nphilipp, rbean, sgallagh, vmaljuli
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-08-06 12:50:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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
data:
...
  buildopts:
    rpms:
      macros: |
        %demomacro 3
        %eds_dbus_services_prefix org.gnome.Evolution
  components:
    rpms:
...

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
%endif

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.
https://pagure.io/fm-orchestrator/issue/1346

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.