• copr-rpmbuild is not ported to epel7, coprs/g/copr/copr-rpmbuild is not a solution (and I can write here multiple reasons if you wish)
• work on epel6 needs to be done, copr mock-config works fine on epel6
• we need to find reasons to drop copr mock-config, and what's the business case
• I dislike the fact that we deprecate mock-config which is totally perfect feature in koji and brew
• copr-rpmbuild depends on tito/rpkg, which is useless for anything I've used copr mock-config for
• copr-rpmbuild is meant to be builder tool, as originally designed in https://bugzilla.redhat.com/show_bug.cgi?id=1357562 and as such it's OK to use for reproducing some builds, but not for development where people do mock -r the-config.cfg --shell

Can you please post the output of the copr-rpmbuild --copr <owner>/<project> --chroot <chroot> --dump-configs? The expected replacement should look like:

include('/etc/mock/fedora-rawhide-x86_64.cfg')

config_opts['root'] = 'unique-id'
config_opts['chroot_additional_packages'] = '<predefined set>'

config_opts['yum.conf'] += """
[copr_base]
name="Copr repository"
baseurl=https://example.org/results/<user>/<project>/<chroot>/
gpgcheck=...
enabled=1
metadata_expire=0
"""

That said, as long as there's no business case to drop copr mock-config which I continuously support, I'm -1.

Anyways, I really appreciate the work done on copr-rpmbuild tool, and the new functionality is very good new feature for reproducibility, very good job and thanks for that! It's not a replacement of copr mock-config, but that doesn't matter.

@praiskup: ping for progress.

A meeting agreement was to make copr-mock-config package that would substitute the functionality. Deprecation warnings should be changed to point to that package as the alternative. Do we have the package yet?

@clime, on the very same meeting we agreed that we have to discuss with @frostyx how the needed data should be obtained from frontend, since we did not port the needed API call to APIv3. Why the pressure? It is work is in progress, but I'm blocked.

Btw., copr-cli mock-config is now broken in master branch, because of the flip to APIv3. I am proposing to flip the one call back to API_V1 for the time being if we plan to have a copr-cli release.

@frostyx, the problem is the difference between those:

curl https://copr.fedorainfracloud.org/api/coprs/praiskup/ping/build-config/fedora-rawhide-x86_64/
curl 'https://copr.fedorainfracloud.org/api_3/project-chroot/build-config?ownername=praiskup&projectname=ping&chrootname=fedora-rawhide-x86_64'

That said, new 'copr-cli' has only copr://praiskup/ping instead of https://copr-be.cloud.fedoraproject.org/results/praiskup/ping/fedora-rawhide-x86_64/. Because copr-cli has no idea where backend is, we need to have some APIv3 change to get this information so client tools can expand the copr://praiskup/ping somehow. On the meeting, we discussed two ways:
- add a separate call, named e.g. /api_3/backend-results/
- add /project-chroot/build-config?expand_repourls=1

@clime, on the very same meeting we agreed that we have to discuss with @frostyx how the needed data should be obtained from frontend

That was a different meeting.

Ye, okay. I will merge this to have at least something and when you have a better alternative, please, open a PR.

Huh? This is not material for merge.

@msuchy, I'm going to have another PR with revert. OK?

This is very unfriendly again ... so let's re-evaluate the loop; I am not interested in maintaining separate package anymore.