When including custom SRPMs with a scratch module build, Koji successfully completes building the custom package. However, when import_build() (in hub/kojihub.py) does sanity checking, it rejects the build with an error such as:
import_build()
hub/kojihub.py
GenericError: Unable to complete build: release mismatch (build: 9999.el8, rpm: 9999.scrmod+el8+281+0bf7d94f)
This apparently occurs because the release header in a custom SRPM doesn't match the final release header in the RPMs built from it.
release
It is understandable the headers don't match because there is no way to create the custom SRPM for uploading with the expected release ahead of time. This isn't a problem for SRPMs the builder auto-generates from dist-git, since the release information is available at the time it does so.
Note: rpkg uploads any SRPMs provided on the fedpkg/rhpkg command line directly to Koji.
rpkg
fedpkg
rhpkg
For RH folks: Module build 281 on the internal staging MBS is an example of this problem. Build 280 is a successful build of the same module that doesn't include any custom SRPMs.
@mikem It was suggested you may be able to offer some insights or suggest a workaround to this issue...
Is there a way to direct Koji to skip the NVR "sanity" check when a package build is imported upon completion--when the build is from a user-provided SRPM that is part of a scratch module build?
The call to Koji to build the uploaded SRPM can be found in near the end of KojiModuleBuilder.build() in module_build_service/builder/KojiModuleBuilder.py.
KojiModuleBuilder.build()
Is there a way to direct Koji to skip the NVR "sanity" check when a package build is imported upon completion
There is not, and it seems incorrect to bypass.
If you generate real builds from srpm (mbs may call these scratch, but to Koji they are not), then you need to generate your srpm correctly for the build target.
@mikem, Thank you for the reply.
Unfortunately, as suggested above, when the user generates and uploads an SRPM for a scratch module build, there is no way to know in advance what the %{dist} macro will end up being set to for the module build. In the error shown above, it ended up being .scrmod+el8+281+0bf7d94f rather that the .el8 that was embedded in the uploaded SRPM.
%{dist}
.scrmod+el8+281+0bf7d94f
.el8
In theory, the MBS API could be reworked so that the SRPM would first be uploaded to fm-orchestrator so it could rebuild the SRPM with the final value of the %{dist} macro before sending it to Koji. But that would be difficult, and it is exactly the first step Koji does when building from SRPM.
fm-orchestrator
Perhaps fm-orchestrator could pass some new optional build flag to Koji, and some minor changes to Koji would recognize that and allow the release header check to be skipped?
Other suggestions are welcome, but we need to figure out a way to make this work.
After the discussion earlier today, I have filed an rfe against Koji: https://pagure.io/koji/issue/1396
https://pagure.io/koji/pull-request/1462 has the fix for this.
This above PR was merged and this fix has been available for a long time, but this issue has remained open. Closing now.
Metadata Update from @merlinm: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.