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 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)? (this will also mean that we need to drop the `fedpkg import` way of doing things or add additional notes there to the docs.) -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London
Attachment:
signature.asc
Description: PGP 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
