On Tue, Jan 10, 2023 at 1:16 AM Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> wrote:
On Mon, Jan 09, 2023 at 09:37:44PM -0600, Richard Shaw wrote:
> Now I'm getting bit by the rpmautospec and COPR issue.

Please be more precise. How are you building the rpms?

The SRPMS? I'm using "rpkg build <PROJECT>"

 
If rpmautospec is used in COPR, and the build is started in a
compatible way, the release field should be the same as in koji.

> I'm trying to test rebuilds of all dependent packages for a new OpenColorIO
> release, but usd uses rpmautospec and in Fedora it's usd-<version>-16 but
> COPR is calculating it as usd-<version>-9 so the Fedora version has a
> higher NEVR.

First of all, if you e.g. want to test the rebuilt packages on your system,
you can always install a lower version than the one currently released.
Dnf allows both downgrades and installations of a specific package and
a specific package version.

I don't want to test the packages per say, I just need COPR to pull in the rebuilt package instead of the one in Fedora, otherwise I get dnf conflicts:

 Problem: package usd-libs-22.05b-16.fc38.x86_64 requires libOpenColorIO.so.2.1()(64bit), but none of the providers can be installed
  - cannot install both OpenColorIO-2.1.2-5.fc38.1.x86_64 and OpenColorIO-2.2.0-1.fc38.x86_64
  - package usd-devel-22.05b-16.fc38.x86_64 requires usd-libs(x86-64) = 22.05b-16.fc38, but none of the providers can be installed
  - package OpenColorIO-devel-2.2.0-1.fc38.x86_64 requires libOpenColorIO.so.2.2()(64bit), but none of the providers can be installed
  - package OpenColorIO-devel-2.2.0-1.fc38.x86_64 requires OpenColorIO(x86-64) = 2.2.0-1.fc38, but none of the providers can be installed 
- cannot install the best candidate for the job

 
Second, how exactly are you building the package?
Looking at [1], you used "Source Type: SRPM or .spec file upload".
How was it generated?

[1] https://copr.fedorainfracloud.org/coprs/hobbes1069/OIIO/build/5210045/

Both 'fedpkg srpm' and uploading that to copr, and letting copr build from
dist-git should result in the expected release. (Though without other steps
it'll still be the same as the version in Fedora release, so you'll need
to tell dnf to install that specific build.)

Looks like the problem is using `rpkg` but that's the easiest method and has worked great until now...

Thanks,
Richard