Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux