On 05. 11. 21 15:12, Ankur Sinha wrote:
On Fri, Nov 05, 2021 14:51:44 +0100, Miro Hrončok wrote:
> On 05. 11. 21 14:13, Ankur Sinha wrote:
>> Hi folks,
>>
>> I've been working with a few Outreachy candidates to help them learn
>> packaging. We're using `fedpkg` as much as we can, since it's what we
>> use to work with all packages after they're imported into Fedora.
>>
>> So, we first create git repo to work in, and after we write the spec,
>> we iteratively use `fedpkg mockbuild` to run mock and test builds before
>> running rpmlint and so on and submitting the package for review. Here, I
>> noticed we get an srpm which contains the spec where the `%autorelease`
>> and `%autochangelog` bits are already expanded.
>>
>> This is causing a couple of issues with reviews and imports:
>>
>> - this spec in the srpm now differs from the spec, and fedora-review
>> will flag this difference---which is confusing for newcomers (and had
>> me confused for a bit too)
>>
>> - after the review, when `fedpkg import` is used to initialise the SCM
>> using the approved srpm, again this spec with `%autorelease` and
>> `%autochangelog` already expanded is pulled in. Here's an example of a
>> package we only imported recently where we didn't realise this:
>>
https://src.fedoraproject.org/rpms/python-glymur/blob/rawhide/f/python-gl...
>>
>> This isn't necessarily a problem from a technical perspective, but it's
>> a little annoying that one now has to remember to manually revert the
>> spec back to use the macros before committing to SCM. If one has to
>> manually tinker with the changelog etc., it defeats the purpose of the
>> macros.
>>
>> Since we didn't realise this, the package is now not using
>> `%autochangelog` and the first build has a release value that isn't 1:
>>
https://koji.fedoraproject.org/koji/packageinfo?packageID=34682
>>
>> So we'll need to fix it (more work):
>>
https://docs.pagure.org/fedora-infra.rpmautospec/opting-in.html#for-exist...
>>
>> So, can anything be done to make this workflow better? Should we/can we
>> disable these when using mockbuild, or add an option to do so that can
>> be used for new packages to keep the value at 1? Or do we note that
>> these macros should only be used right before import (but that means
>> again editing the spec after running `fedpkg import` and more confusion
>> for newcomers)?
>
> The %autorelease/%autochangelog macros assume we are in a git repository.
>
> Hence if the package is created in a git repository before it is imported
> into Fedora, we should probably teach the packagers to push those commits to
> Fedora when he package is approved, instead of using `fedpkg import` which
> will also throw away their git history.
Hrm, but how would we do this? The new SCM repo that is created has a
completely different commit tree. I guess we can add the new remote and
then do a force push for the first time, but that then will remove
releng's initial commit. A rebase perhaps (not tested, and maybe not the
best thing to do for newcomers at the start of a repo)?
I use `fedpkg request-repo --no-initial-commit` for this. Unfortunately, it is
currently broken on releng's side :/
(this will also mean that we need to drop the `fedpkg import` way of
doing things or add additional notes there to the docs.)