Zbigniew Jędrzejewski-Szmek kirjoitti 2.1.2023 klo 22.44:
On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote:
> * Vitaly Zaitsev via devel:
>
>> On 30/12/2022 20:01, Ben Cotton wrote:
>>> This document represents a proposed Change. As part of the Changes
>>> process, proposals are publicly announced in order to receive
>>> community feedback. This proposal will only be implemented if approved
>>> by the Fedora Engineering Steering Committee.
>>
>> -1 until these known issues[1] are fixed, especially with changelogs
>> and using rpmautospec in COPR or mock.
>>
>> [1]:
>>
https://docs.pagure.org/fedora-infra.rpmautospec/peculiarities.html#known...
>
> The page doesnt discuss COPR/mock?
>
> COPR seems to work in some cases, specifically with the dist-git build
> (but not just building from dist-git).
>
> A quick check suggests that rpmautospec does the right thing and
> produces a portable source RPM that doesn't depend on rpmautospec
> anymore. As a result, the compatibility impact won't be too severe, I
> hope.
Also mock builds seem fine. I tested this now on F37 with a few different scenarios:
- fedpkg mockbuild
- git commit --allow-empty -m Rebuild && fedpkg mockbuild
- fedpkg srpm && mock *.src.rpm
seem to generate the expected versions numbers and changelogs.
All these examples work because 'fedpkg srpm' does the rpmautospec
conversion, and all the used fedpkg commands imply 'fedpkg srpm'.
If you generate an srpm which still contains %autorelease and
%autochangelog with 'rpmbuild -bs', mock will not convert them by
itself. Also, 'mock --buildsrpm' will not convert them. Perhaps Vitaly
meant mock should support such usage?
But I wonder, if that is really necessary? In many cases like local test
builds, the default values for uncoverted %autorelease and
%autochangelog are just fine, and if the real values are needed, 'fedpkg
srpm' can be called before invoking mock.