Mock seems to fail to build packages with this error output: CentOS-8 - Base .. 1.5 MB/s | 2.2 MB 00:01 CentOS-8 - AppStream .. 2.3 MB/s | 5.8 MB 00:02 CentOS-8 - PowerTools .. 2.3 MB/s | 1.9 MB 00:00 CentOS-8 - Extras .. 28 kB/s | 7.3 kB 00:00 Extra Packages for Enterprise Linux 8 - Pla.. 1.7 MB/s | 6.1 MB 00:03 Error: Problem: conflicting requests - nothing provides fpc-srpm-macros needed by epel-rpm-macros-8-16.playground.noarch (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) I'm not sure we are doing this good on the mock side ... is epel playground supposed to work like 'CentOS + playground', or do we need to enable normal epel as well in buildroot? Or can we provide fpc-srpm-macros in epelplayground repo?
EPEL Playground is in the middle of changing. It will no longer be a "stand alone" repository. It will be for only those packages that people are using to "play with" large changes to their packages. There will be no more automatic builds of all packages. Because of this, you will need to have the regular EPEL repository enabled in order to use the EPEL-Playground repository. We're right in the middle of this change, but fixing mock now is the best time to do it. It won't hurt anything to add the regular EPEL repository now, when doing the EPEL-Playground mock.
Still, is is expected that 'fpc-srpm-macros' goes to epel, or should it live also in the playground repo?
People didn't, and won't *have* to have anything in EPEL-playground. They were free to opt-out of the playground automation. Because of this opt-out option, EPEL-playground is currently a mess. As you can see from this bug. fpc-srpm-macros is in regular epel. It is currently not in epel-playground. It looks like it isn't in playground because it didn't build correctly in playground. Unfortunately, this ticket isn't assigned to the person who built the package in EPEL. I've cc'ed them to this bugzilla. Anyway, to better answer your question. Currently, nothing is *expected* to be in playground. Because maintainers can always opt-out. In three weeks (hopefully), it is expected to *not* be in playground.
I went and fired a epel8-playground build off: https://koji.fedoraproject.org/koji/taskinfo?taskID=51522174 Should fix the issue...
Thank you Kevin for the build, I was on vacation when this has been reported and then it completely slipped off my attention. Troy, I read the draft about el8-playground, if I understand the situation correctly, I will have to untag the build from epel8-playground when the change goes live. Or there will be a mass untag process?
There will be a mass untag process. You shouldn't have to do anything.