On Tue, Jan 10, 2023 at 1:53 PM Richard Shaw <hobbes1069@xxxxxxxxx> wrote: > > On Tue, Jan 10, 2023 at 1:16 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> 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... Well, it was only a matter of time until rpkg stopped working. It was abandoned a while ago and was officially marked as "no longer maintained" last year: https://pagure.io/rpkg-util Fabio _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue