Dne 05. 11. 21 v 15:12 Ankur Sinha napsal(a):
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-glymur.spec 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-existing-packages 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
And then rebase. This is script I use: ~~~ #!/bin/sh git checkout main git remote set-url origin ssh://vondruch@xxxxxxxxxxxxxxxxxxxxxx/rpms/"$@" git fetch origin git branch main -t origin/main git rebase origin/main ~~~ Vít
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
