Skip to main content

FAQ

Can I use the packit service as soon as I install it into my repository?​

Thanks for your interest in Packit Service! In order to start using the service, your repository or namespace needs to be allowed. Just be aware that we are now onboarding Fedora contributors who have a valid Fedora Account System account. For more details on how to get allowed for our service, please read about the process here.

Can I use packit service for any GitHub repository?​

Since Packit Service builds your PRs in Fedora Copr build service, by using Packit-as-a-service, your software needs to comply with Copr rules. If any of these points are violated, we'll remove the builds and may put you on a blocklist, so you won't be able to use the service again.

How can I contact you?​

If you encounter a problem while using packit or Packit Service, please open an upstream issue. In case of any other questions, feel free to contact us.

Why do I have to maintain .packit.yaml and a spec file upstream?​

We are working on simplifying the .packit.yaml so it's as small as possible. We will also handle all potentially backward incompatible changes of .packit.yaml. Spec file can be downloaded (see specific question below) from Fedora Pagure instead of having it included in the upstream repository.

But what are the benefits?​

Packit makes it trivial to run your project as part of an OS. It provides feedback to your project at the time when the changes are being developed so you can fix incompatible code when you are working on it, not when it's already released. When you push commits to a pull request, you'll get RPM build and test results right away.

Why Fedora?​

We've started with Fedora Linux because we work for Red Hat and we ❤ Fedora.

How is Packit different from other services?​

Packit connects the existing services (Copr, Fedora dist-git, Koji, Bodhi) together.

Can we use Packit with Gitlab?​

Yes! You can find instructions at the Packit Service page.

How can I download RPM spec file if it is not part of upstream repository?​

If you do not want to have the RPM spec file in your upstream repository, you can download it in actions section.

Add actions section to your packit.yaml configuration file and download the spec file in a hook post_upstream_clone. The environment where these commands are run is limited, so make sure to install relevant packages using the srpm_build_deps option.

The configuration file with downloading the RPM spec file now looks like this:

specfile_path: packit.spec
files_to_sync:
  - packit.spec
  - .packit.yaml
upstream_package_name: packitos
downstream_package_name: packit
actions:
    post-upstream-clone: "wget https://src.fedoraproject.org/rpms/packit/raw/main/f/packit.spec -O packit.spec"
srpm_build_deps:
  - wget

I have a template of a spec file in my repo: can packit work with it?​

Yes!

The solution is, again, actions and hooks. Just render the spec after the upstream repo is cloned:

specfile_path: my-project.spec
upstream_package_name: my-project-src
downstream_package_name: my-project
actions:
    post-upstream-clone: "make generate-spec"

Where the "generate-spec" make target could look like this:

generate-spec:
    sed -e 's/@@VERSION@@/$(VERSION)/g' my-project.spec.template >my-project.spec

As a practical example, cockpit-podman project is using this functionality.

Can I use CentOS Stream with packit service?​

Yes, you can! It's very simple, just add centos-stream-8-x86_64 as a target for the copr_build job:

jobs:
- job: copr_build
  trigger: pull_request
  targets:
    - centos-stream-8-x86_64

After adding tests I see error 'No FMF metadata found.'​

If you encounter this error when running tests via Testing Farm, it means you forgot to initialize the metadata tree with fmf init and include the .fmf directory in the pull request. See Testing Farm documentation for more information.

Does packit work with rpmautospec?​

Good that you ask. It does, packit works with rpmautospec quite nicely.

Before you start, please make sure that you follow latest documentation for rpmautospec.

rpmautospec utilizes two RPM macros:

  1. autorelease — to populate Release
  2. autochangelog — to figure out changelog

If you want your upstream spec file to also work well when rpmautospec-rpm-macros is not installed, set Release to this:

Release:  %{?autorelease}%{!?autorelease:1%{?dist}}

This construct uses autorelease macro if it's defined, and if it's not, it sets release to 1%{?dist}.

For %changelog, you don't need to include the changelog file upstream. You can have it downstream only, which makes sense - changelog is specific to a release.

How do I install dependencies for my commands in packit-service?​

For installations made before September 6, 2022, Packit runs all the commands, defined by you, in a sandbox which is locked-down.

As for the actions needed during SRPM builds, we are transitioning into a solution where SRPMs are built directly in Copr and therefore for these actions, you can define your dependencies via srpm_build_deps key in the configuration file. You can read more about this transition here.

A command failed in packit-service: how do I reproduce it locally?​

Please read this document on how to reproduce locally.

Why you should use Packit instead of external devices directly?​

  • Packit uses various services Testing Farm, Copr, Koji, Bodhi…
  • These services can be used without Packit, but Packit integrates them in a more user-friendly way reducing the manual labor that would be required from the contributor or maintainer. For example:
    • the build in Copr is created automatically when a new version is released
    • RPMs built by Copr are specifically passed to the Testing Farm for testing
    • RPM builds are verified against multiple releases (and also different OSs)
  • The user does not have to wait and look for the results but just interprets them.