What is packit? Helps automate builds of rpm packages to avoid having to do so manually. Could be set up for builds for every commit, release or pull request.

Well explained in Fedora magazine Packit documentation

https://developers.redhat.com/articles/2022/08/16/how-set-packit-simplify-upstream-project-integration#setting_up_packit_in_3_steps

First it’s necessary to install the Packit-as-a-service to a github repo. Packit people need to approve the namespace on github.

For copr build, copr namespace or project have to be created manually and aksed for authentication of the packit service in packit team.

Create a packit.yml file

With packit init or manually. packit.yml file is where the configuration of packit is written and has to be located at the root of the repo.

Example of packit.yml:

# See the documentation for more information:
# https://packit.dev/docs/configuration/

specfile_path: unicorn.spec

# add or remove files that should be synced
files_to_sync:
    - unicorn.spec
    - .packit.yml

# name in upstream package repository or registry (e.g. in PyPI)
upstream_package_name: unicorn
# downstream (Fedora) RPM package name
downstream_package_name: unicorn
sync_changelog: true

Spec files

For packit it’s the best when spec files are located upstream. On the other hand, spec files are distribution specific and they need to be available for changes made by other maintainers or automated tooling. Fedora’s git repository is the canonical location for spec files.

Local build

Before sending the PR (job) to packit, it’s better to check the package builds locally. With rpmbuild or mock.

Mock: https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds

packit srpm or rpmbuild -bs package.spec => both build srpm.

mock -f fedora-rawhide (on other branch) <path/to/srpm>

Only when it builds successfuly with rpmbuild or mock, push to the pull request to trigger packit build.

fedpkg prep fedpkg mockbuild

If it complains about release, specify release:

fedpkg --release f36 mockbuild

To see releases: fedpkg --release-info

fedpkg srpm builds src.rpm for a branch, latest by default fedpkg diff

Koji scratch build is a build against buildroot without including it in the release.

koji build --scratch rawhide <package>.src.rpm => creates scratch build fro changes that were not commited

And linter in the end: fedpkg lint. Everything has to pass.

When the pull request is merged, it’s a good idea to tag and release new version. On src.fedoraproject.org there should be the new release version with updated spec file. Then create a pull request downstream with packit propose-downstream.

Propose downstream

packit propose downstream creates a new pull request on fedora dist-git using selected or latest upstream release. Source: https://packit.dev/docs/fedora-releases-guide/

Challenges

Packit does not support donwstream patches. They need to be merged upstream or moved to a branch and merged there. Also packit does not support monorepos for the moment. What is a monorepo? When one repo is split into several subpackages, for example the current situation in bodhi and datanommer.

Testing packit in a container

Good idea for excluding local interferences. podman run -it -v repo:repo dockerhub:fedora<release> dnf install packit packit init packit srpm packit local-build