| Summary: | Cannot make buildopts work | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Milan Crha <mcrha> |
| Component: | module-build-service | Assignee: | Ralph Bean <rbean> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 30 | CC: | 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: | |
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. 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. 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 (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. Reassigning this to MBS. 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 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. |
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