My notes about packaging for Fedora
These personal notes serve for me, when trying not to get lost in the amount of guides and links there are and in effort of keeping some outlines and avoid asking the same questions more times. It is very probably full of mistakes and inaccuracies. Please don’t use this as a guide and if you find a mistake, let me know about it in the comments.
How to make a Fedora package
When a program has enough functionality, maybe it’s time to package it. Cranc has 4 working commands. It can list PRs and issues, merge PR and create PR. First thing to do is to create a Vagrantfile with Fedora 29. I used an example Fedora Vagrantfile and modified it with the latest version of Fedora and also made some adjustments.
The next thing to do is writing a spec file. I checked how a spec file should look like in a popular Fedora package - python-requests. I was following several Fedora guides. First one was providing general info about Packaging and maintaining Python applications. There are useful links to Fedora packaging guidelines and Python packaging guidelines and it is strongly recommended to get familiar with them. It’s also necessary to add the license. I decided to use the GPLv3 license.
Then it is time to create a tarball. First I tagged the last commit of
cranc with the version tag:
git tag -a v.0.1 -m "[tag message]"
To see all the tags:
To see info about specific tag:
git show v.0.1
Tagged commits are stored as full objects in git database and are checksummed. About tagging
Then I made a new repo on pagure called
On local repo I placed the
cranc.spec file and
Vagrantfile, added, commited and pushed to
remote python-cranc repo.
I configured git like this:
git config --global user.name "Lenka Seg"
git config --global user.email firstname.lastname@example.org
The next step was installing Koji which is the developer client tool to request package builds and get information about the buildsystem. Koji builds RPM packages.
dnf install fedora-packager
dnf install fedora-review
I added myself to the mock group:
usermod -a -G mock [myusername]
I changed from the root user to my user name and run
id to confirm that the mock group appears in the group list.
After that I continued with the Koji build:
This starts a build request for the branch. Hopefully it builds succesfully. With this I get the srpm file.
There is a useful tool for package review called rpmlint. It checks if the spec file passes in all the MUST items and SHOULD items and leaves a report.
yum install -y rpmlint
To test the rpm file:
rpmlint [PATH]/rpmbuild/SRPMS/[RPM FILE]
When all the complaints are solved, it’s time to upload a release.
Upload the srpm file and file a bug in Bugzilla
From pagure.io I clicked on Releases button and Upload a new release. That means to upload the src.rpm file. The file will appear in the Release folder.
Now it’s time to go to Bugzilla and file a bug. I need urls of the spec file and SRPM file. It was my first package and I needed to find a sponsor. After the reviews and some changes my package was finally approved. One very kind sponsor took care of me, so I could request a repo and a branch.
Requesting repo and branch
I want to be a maintainer of my package, thus I have to request a new git repo.
(from the devel directory in vagrant)
fedpkg request-repo cranc [bugnumber]
Requesting a branch:
fedpkg request branch f29 or f30 or rawhide (master)
Requests were reviewed and processed pretty quickly. Now I have access to commit and build the package.
Import, commit and building a package
Checkout the module from the SCM:
fedpkg clone cranc
Now it’s time to test the package with Koji scratch build.
First use kerberos auth with Fedora:
Otherwise run just
After that run fedpkg to import the contents of the SRPM into the SCM:
fedpkg import PATH_TO_SRPM
fedpkg import ../rpmbuild/SRPMS/[cranc src.rpm]
This will import the contents of the SRPM into the SCM.
Next step in the guide is to review changes, commit with the bug number:
git commit -m "Initial import (#[bug number])"
Update in Bodhi
Bodhi is Fedora update system, serves for pushing updates on branches.
Requesting another branch
Now I need to request new branch. I requested it again with
fedpkg request-branch f30 from the devel/cranc in vagrant
this will return a url to pagure.io/releng and open an issue with new branch request
and it was approved.
Now from the same diectory:
- go to master
- git pull
it shows there is a new branch available:
* [new branch] f30 -> origin/f3
git branch -f f30 origin/f30 this command fetches the new branch from the origin, which is the
remote repo rpms/cranc which was created by fedora people.
Checkout that new branch:
git checkout f30
it should contain the same stuff as in the remote:
(if there are some extra things, remove them)
The guide recommends to test the package making the scratch build It’s building a package against the buildroot without actually including it in the release.
rpmbuild -bs cranc.spec
`koji build –scratch rawhide cranc.srpm
More info in the link.
First run git status, add and commit the files. Usually it’s
kinit for logging in.
Time to import! Run:
fedpkg import PATH_TO_SRPM
fedpkg import /home/vagrant/rpmbuild/SRPMS/cranc-0.2.2-3.fc29.src.rpm
It does not matter, that I want f30 and in the path there is f29.
For rawhide (master)
If there are some more changes (for example in .gitignore and sources) add them, commit, push:
git commit -m "commit [package review bug number]"
For updating branches
fedpkg switch-branch BRANCH (for example f30)
git merge master
If there is another branch, repeat “To switch to a branch”, import and commit again. Always rawhide (master) has to be build first.
If the build is succesful, there is this url: “https://koji.fedoraproject.org/koji/taskinfo?taskID=33401469” where the build is nicely visible in koji.
Update to Bodhi
Fedora update system. Always submit from branches, never rawhide (master).
Here it will be moved to testing and waiting for reviews (karma points). I set karma to 1, for such an obscure package as cranc I think it’s appropriate. If there are no reviews, apparently after 7 days the package is moved to stable.