New Package Process for Existing Contributors

This is a short version of the New Package Process, streamlined to show how existing contributors can make new packages.

  1. Read the Packaging Guidelines and Package Naming Guidelines. Really. Be comfortable with them.

  2. Make a package.

  3. Upload your SRPM and SPEC files onto the internet somewhere.

  4. Make sure you have a Bugzilla account at

  5. Fill out Bugzilla Fedora review form to create a review request.

    • Make sure you put the name of the package in the Review Summary field, along with a very brief summary of what it is

    • Make sure that you put the URL paths for the SPEC file and the SRPM file in the Review Description

    • Put a description of your package (usually, this can be the same thing as what you put in the spec %description) in Review Description

    • The review process is described in detail in Package Review Guidelines.

  6. Watch the review request in Bugzilla. Fix any blockers that the reviewer(s) point out.

  7. When the package is approved by the reviewer, request a git module with fedpkg request-repo PACKAGE-NAME BUGZILLA-TICKET-NUMBER and when the repo is created request branches with fedpkg request-branch --repo PACKAGE-NAME BRANCH. You might need to get a pagure-API-token before being able to successfully request the repo. Wait until the requests are approved.

  8. Once the requests are approved, checkout the git module with fedpkg clone <packagename>. (Package Maintenance Guide has more information about fedpkg.)

  9. Import your srpm

    • First kinit username@FEDORAPROJECT.ORG

    • Then you can import the approved SRPM into the rawhide branch by running fedpkg import libfoo-x.x.x.src.rpm; git commit -m "Initial import (#nnnnnn)." (where nnnnnn is your Bugzilla package review bug number).

    • Obviously, replace libfoo-x.x.x.src.rpm with the full path to your approved SRPM.

    • You should see it upload the sources, and finish successfully. If you didn’t set up ssh-agent it will ask often for your ssh-key passphrase. This is normal.

    • Now run git push to get the final versions in your rawhide branch.

  10. You can now import the package to your branches (which you requested in Step 7) too

    • The quickest way to do this is to use fedpkg switch-branch BRANCH to switch the branch (where BRANCH can be f13 and so on).

    • Now you can git merge rawhide. This will get .spec file, .gitignore and source file together with any patches and other files from the rawhide branch and create an identical commit.

    • Previous step already created commit for you, now you can push the results using fedpkg push or git push.

  11. Request builds

    • For each branch that you’d like to request a build for, switch using fedpkg switch-branch and run fedpkg build.

    • If everything goes well, it should queue up your branch for building, the package will cleanly build, and you’re done!

    • If it fails to build, the buildsystem will send you an email to report the failure and link you to the logs. Commit any needed changes to git, bump the spec release number and request a new build.

  12. Close the Bugzilla ticket (assuming that the package built successfully)

    • You should close it with resolution NEXTRELEASE or RAWHIDE, depending on where you built the package. The resolution field will appear after you set the status field to CLOSED.

  13. If this package will be built for any version of Fedora that is already released please submit it for inclusion in the fedora-updates repository for those versions of Fedora. See Package Update Guide for more details.

  14. Add the package to the comps file(s) if appropriate.

  15. Consider enabling Upstream Release Monitoring for the package.

We know that this process can be as clear as mud sometimes, we’re always trying to make it better. If you run into any problems, or have any questions, please ask on the Fedora development list.

Package Maintenance Guide may also be of use.