Related to #52, just dropping these here so they don't get lost. Explanations are important because this git usage may be advanced for new comers.
TODO: add to docs somewhere
So, here's what to do with explanations.
Here, we are working with the python-pooch package, but replace it with whatever package you are looking to import:
git remote rename origin pagure
git remote add origin <SSH clone URL>
For example:
git remote add origin ssh://vanessakris@pkgs.fedoraproject.org/rpms/python-pooch.git
The remote URL is of the form: ssh://<FAS username>@pkgs.fedoraproject.org/rpms/<package-name>.git.
ssh://<FAS username>@pkgs.fedoraproject.org/rpms/<package-name>.git
git remote -v
git fetch origin
git log --graph --oneline --all
you should see commits from your current branch and remote, and also with the new remote
for clarity, we'll create a new branch called rawhide which will track the rawhide branch from the new src.fp.o remote:
git branch -t rawhide origin/rawhide
git rebase -i rawhide
This will open up a window for you.
if you added a README file, drop your first commit where you created the README, otherwise that will conflict with the README file that is in the src.fp.o repository. To do this, go to the line, where your commit is, and change "pick" to "drop". This drops this commit when re-basing.
if you didn't add a README, just save and quit the new window to complete the rebase
now check your git commit history again and see what changed:
git log --oneline --graph --all
So what we've done so far is taken the commits from your pagure repo and added them to the new src.fp.o repo. This way, the git commits that you had made during the review etc. are not lost and this means that the autochangelog and autorelease bits will continue to work correctly.
you've now finished rebasing correctly, note what branch you were working on (usually either master or main):
master
main
git branch
and now, let us update the rawhide branch to match the branch we were working on:
git checkout rawhide git merge <branch noted above>
Now, we need to do the other few bits that fedpkg import does for us, before we can push and build:
fedpkg import
git rm --cached pooch*tar.gz kinit <your Fedora username>@FEDORAPROJECT.ORG fedpkg new-sources <the Source0 tar.gz file>
Here, because this file was committed in the repo, we had to remove it first using git rm, otherwise fedpkg would throw an error.
git rm
The new-sources command will create the sources file and stage it for you, and it will add the tar.gz file to your .gitignore file also, to ensure that it is not committed to the git repo.
new-sources
.gitignore
Note the kinit command, this is required to authorise you to upload the source (because we don't want just anyone uploading software to our archives!). The FEDORAPROJECT.ORG bit must be in capitals.
kinit
FEDORAPROJECT.ORG
results_*
git rm *.src.rpm results* -r
git commit -m "initial import to src.fp.o"
git push fedpkg build
git remote remove pagure git branch -D main git branch -D master
Once your build for rawhide completes, also build for F35 (and F34 if applicable):
fedpkg switch-branch f35 git merge rawhide git push fedpkg build
https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/#update_your_branches
Is this really worth the effort?
What I've been doing in this case is very simple ... instead of "fedpkg import <srpm>", I do
Assuming the pre-import changelog is not essential for some reason, I would argue that this is much easier for newcomers than all the git-fu above :)
Yeh, I guess it comes down to personal preference (again). I like to keep commits around so that the review is also sort of tracked the way it would be when using a non-rpmautospec changelog, but that's not required by the guidelines as far as I know, so just copying stuff over should be fine.
If the community can agree that copying stuff over is fine, maybe fedpkg import can also be tweaked just to add a new empty changelog if rpmautospec was used I guess?
Sure, that's something every package maintainer has to decide for themselves. For new packagers, it would probably be easier to do the "simple" thing, but anybody who wants to explicitly keep old changelog entries, the "advanced" method can be documented as well.
Sorry, this has me confused. Having an empty changelog file is almost but not really equivalent to not having that file at all: you don't get generated %changelog entries for commits that change the changelog file, so adding an empy file is strictly worse than adding no file. :)
changelog
I like to keep commits around so that the review is also sort of tracked the way it would be when using a non-rpmautospec changelog
AFAIK, it's recommended to start changelogs with a single Initial import changelog entry and not have unrelated things from the package review.
Initial import
I like to keep commits around so that the review is also sort of tracked the way it would be when using a non-rpmautospec changelog AFAIK, it's recommended to start changelogs with a single Initial import changelog entry and not have unrelated things from the package review.
I'm not aware of this recommendation, indeed, my thinking was that the changes made during the review should be noted. I've also done that in the past when not using rpmautospec.
So, if this is documented somewhere, it'll make things a lot simpler---and perhaps allow fedpkg to be modified to import rpmautospec srcs.
In my opinion too, what is written in the issue description is a very complex operation that achieves very little in practice. I would not want to have that included as the recommended way of doing things. Of course, "alternative" and "advanced" methods can (and should) be documented.
The recommendation for the single commit when adding a new package is here: New Package Process for New Contributors / Import, commit, and build your package
For rpmautospec support in fedpkg import, it is not correct to say that it is not supported. A srpm containing a specfile with %autorelease and %autochangelog is imported correctly — those macros are just some macros in the specfile, nothing special there. What confuses many people is that e.g. fedpkg mockbuild first puts the specfile through rpmautospec process-dist-git. Obviously the packager did not mean to import such specfile, so fedpkg import is currently refuses to them. On the other hand, if you generate the srpm via plain rpmbuild, the rpmautospec macros are intact, and importing already works today.
%autorelease
%autochangelog
fedpkg mockbuild
rpmautospec process-dist-git
rpmbuild
For some recent progress on importing a resolved rpmautospec specfile, see rpkg#699 *pkg import: Undo rpmautospec processing.
Since that recommendation of just a single commit for new pacakges is there, can this issue be closed? Or do you want to keep it open to (eventually) document this as an advanced method?
Login to comment on this ticket.