Skip to content

Fedora Packager Onboarding

Hi ${NAME},

I have sponsored ${USER} into the packager group and approved your package. Congratulations!

Now, you should import your package. You can look at https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/#add_package_to_source_code_management_scm_system_and_set_owner for more information, but I will also outline the process for you here.

  1. Go to https://accounts.fedoraproject.org/user/${USER}/settings/keys/ and upload your SSH public key. You can also upload your GPG public key if you have one.

  2. Go to https://pagure.io/settings and create a new token with the “Create a new ticket” ACL only.

  3. Install the packager tools with sudo dnf install fedora-packager.

  4. Run fedpkg set-pagure-token "[token from step 2]".

  5. Go to https://src.fedoraproject.org and login. If you are already logged in, log out and log back in. You have to log out and log in after you’ve been sponsored to ensure that your new permissions propagate. It’s important to do this before requesting the repo so the request doesn’t get denied.

  6. Request a new repo with fedpkg request-repo [pkgname] [review bug id]. (pkgname = ${PKGNAME})

  7. Request branches for the currently supported Fedora stable and branched releases (F37-F39) with fedpkg request-branch --repo [pkgname] --all-releases. rawhide is created for you.

  8. Wait for the requests to be processed. You will get an email once this has occurred.

  9. Acquire a Fedora kerberos ticket with fkinit -u [Fedora username]

  10. Create a directory to store your fedora packages.

  11. Change into that directory and clone your package’s distgit repository with fedpkg clone [pkgname].

  12. Change into the directory and run fedpkg import /path/to/[pkg].srpm to import your package into dist-git. This will copy the specfile into the current directory and upload the package’s source tarball into the lookaside cache.

  13. Open the specfile and edit your initial changelog entry to include the text Closes rhbz#[review bug id]. This way, Bodhi (Fedora’s updates system) will automatically close the review bug when you build the package.

  14. Commit your changes and push them to rawhide. fedpkg also has some git-related functionality that makes certain tasks easier than they would be with just git directly. For instance, you can run fedpkg commit -cp which will commit your changes using your changelog entry as the commit message and git push all in one go. I prefer using git directly, but this functionality is there if you’d like to use it.

  15. Build your package for rawhide with fedpkg build --nowait. Then, you can git switch to f39, run git merge rawhide && git push and then run fedpkg build --nowait to build for that branch. Do the same thing for the f38 and f37 branches. After that, you can switch back to rawhide. Generally, you should make changes in rawhide first and then merge them back to the stable branches if appropriate.

  16. Next, you will have to submit updates on Bodhi for the stable releases. Bodhi updates are created automatically for rawhide.

    1. Navigate to https://bodhi.fedoraproject.org/updates/new.
    2. Fill in the Builds field with your Fedora 37, 38, and 39 builds. It autocompletes.
    3. Fill in the Description field. Something like Initial import for [pkgname]. Fixes rhbz#[review bug id] should suffice. You can set Type to newpackage and leave the other fields in that section alone.
    4. For Bugs, you can type in the review bug ID. It’s okay if it says that the bug is already closed.
    5. You can leave the other fields alone and push Submit.

That’s it! Of course, you can let me know if you have any questions. You can contact me by email or reach me at @gotmax:matrix.org on Matrix. Do you have a Matrix nick? Also, feel free to ask any questions on the devel mailing list or in #devel:fedoraproject.org on Matrix.

When you have a chance, you can read through the Package Maintenance Guide and the Package Maintainer Responsibilities. There are some other useful docs that you might want to take a look at in the Package Maintainers section besides those two. Don’t feel pressured to read everything at once or remember everything!