$ fedpkg module-build --watch
Submitting the module build...
Could not execute module_build: The build failed with:
Cannot find any module builds for php:7.2
Of course php:7.2 (and 7.3) are official modules in RHEL 8.1
Can you let us know what module you are building, so we have an example of the yaml file you are using.
module is "php-extras"
From what I know, this isn't as simple as it sounds. When the EPEL8 infrastructure was setup, it couldn't pull over intact modules from RHEL8, only the packages. Thus the default modules were all that were available because otherwise there would be conflicting packages, and only the highest NVR would be available.
When modularity was added to the EPEL8 build infrstatucture, I'm not positive if it changed the fact that we couldn't pull over intact modules from RHEL8.
Someone from infrastructure can let me know, but I believe that is still the problem that needs to be solved.
So currently RHEL-8 modules get broken up by grobisplitter and all that data is not available. I think it would need someone in staging to test a change to the koji external repos from
That would get rid of the grobisplit and retain the modularity. Or we work out what is needed to get the modularity parts working when stuff is grobisplit.
Metadata Update from @smooge:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: mbs, releng
Please do something
I forgot to put something in here.
We discussed this in the EPEL Steering Committee. It was approved to have CPE work on this. It was assigned, but with the knowledge that the person it was assigned to wouldn't be able to even start it for at least a month, and then possibly a month of testing and trials. (Figuring out if it's better to get rid of grobisplitter, or hack it to do what we want)
We will continue to ping the person it was assigned to each week, but don't expect the work/testing to begin for another two weeks.
Thank you for your patience. We (the steering committee) feel this is an important issue, just complicated to implement.
@tdawson Do you have some more information about this? I am not aware of CPE working or planning to work on this.
This is/was a task that @mohanboddu agreed to work on.
I was/am hoping that @merlinm would be able to help him with it.
It sounds complicated, but hopefully do-able.
@maxamillion wanted to help in EPEL, so I forwarded this ticket to him.
Are there any ideas regarding how to go about fixing this issue? If not, the maintainers of fm-orchestrator might have some thoughts.
hi all. are we doing anything regarding this? it's been 5 months already, so fast.
The only fix I can think of is if someone writes a koji/mbs module importer. If we had something that could import module builds, we could possibly import the centos ones and build against that.
I'm not seeing any other way to solve this off hand.
I think we're missing really only two pieces here:
Mock has had the capability to enable and disable modules as part of buildroot setup for a few releases now, so the remaining need would be to plumb this through to Koji as a setting for build tags like we do for rpm macros.
In Mock 2.4 (which we have in production), it is now possible to configure modules in a much more straightforward fashion per build environment, using a module_setup_commands array.
config_opts['module_setup_commands'] = [
This can be used by MBS or even by plain builds.
I have filed issues with Koji and MBS about this:
Metadata Update from @smooge:
- Issue priority set to: Waiting on External (was: Waiting on Assignee)
- Issue tagged with: dev, high-trouble, medium-gain
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).
Metadata Update from @pingou:
- Issue untagged with: dev
to comment on this ticket.