Re: Expansion of rpmautospec macros when building new packages

[Vít Ondruch <vondruch@xxxxxxxxxx>]

Dne 05. 11. 21 v 15:43 Miro Hrončok napsal(a):
> On 05. 11. 21 15:35, Vít Ondruch wrote:
> > 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
> >
> > ~~~
>
> I suppose we could teach `fedpkg import` to be able to import git 
> history + tarball(s) rather than a SRPM.

I like the idea. However, I am not sure this would work, at least if the 
`import` action should be somehow modified to include this functionality.

Maybe there could be something like `fedpkg init-package`. I have 
actually another script I use for new packages:


~~~

#!/bin/sh
# A smarter way of importing a new package in Fedora
# 
http://blog.fedora-fr.org/bochecha/post/2011/02/A-smarter-way-of-importing-a-new-package-in-Fedora

cd ~/fedora-packages

git init --bare "$@".git
scp -r "$@".git vondruch@xxxxxxxxxxxxxxxx:~/public_git/
ssh vondruch@xxxxxxxxxxxxxxxx "touch 
~/public_git/${@}.git/git-daemon-export-ok"
rm -rf "$@".git

git clone vondruch@xxxxxxxxxxxxxxxx:public_git/"$@".git

cd "$@"

touch sources .gitignore
git add sources .gitignore
git commit -m "Initial setup of the local repo"
~~~


This creates the git repo and push it to fedorapeople.org to have it 
ready for review. It could also create .spec file via `rpmdev-newspec` 
or similar.

If this was followed by `fedpkg initial-import` doing something like the 
original script I posted + probably real `fedpkg import`, that would be 
super helpful.



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