For my Fedora packaging sponsorees

01. 03. 2023 | Jakub Kadlčík | EN fedora packaging

You have just been sponsored to the Fedora packager group and your review ticket was formally granted the fedora-review+ flag?

Fedora profile

See your Fedora Accounts profile. You should be a member of packager, fedorabugs, and fedora-contributor groups.

Finishing the review

Go back to the Package Review Process documentation page. We already completed the following steps

  • The reviewer will review your package […] Once the reviewer is happy with the package, the fedora-review flag will be
    set to +, indicating that the package has passed review.

  • If you have not yet been sponsored, request sponsorship by raising an issue at packager-sponsors.

Continue by configuring fedpkg and requesting a DistGit repository for your package.


You will maintain your Fedora package within a DistGit repository. Please read more about DistGit and its client tool fedpkg. Here is how a typical packaging session looks like but I have a different approach. Choose what makes more sense to you.

Let’s say that you want to update to a new upstream version of the package (or add your initial package after the review). You already know how to create a SRPM file, so do it your favorite way. Be it tito, rpmbuild, download it from Copr, etc.

# You already know how to create a SRPM file, in this example your package
# is named `foo` and you have `foo.src.rpm` file.
ls /path/to/your/foo.src.rpm

Import it to the DistGit

# You will probably do this just once
fedpkg clone foo
cd foo

# Upload the new sources and commit the new spec file
fedpkg import /path/to/your/foo.src.rpm
fedpkg show

# Push the spec changes and build for rawhide
fedpkg push
fedpkg build

You need to update each branch, and submit a build for it manually. Do this for every active branch.

fedpkg switch-branch f38
git rebase rawhide
fedpkg push
fedpkg build
# repeat the previous steps for f37, f36, and so on

After you submitted all builds, go to the Bodhi website and create a New Update

Copr or Mock

For any future changes, before pushing them to DistGit and building the package in Koji, it is a good idea to build it in Copr or Mock and fix any potential bugs. We have a nice screenshot tutorial on how to use Copr, and using Mock is easy as well.

Keep in touch

If you have any questions, topics to discuss, or any worries that you’ll break something, please let me know.

You can also reach out to other packagers on #fedora-devel channel, and and mailing lists.