What is copr ?

Copr is according to Fedora wiki

a Fedora project to help make building and managing third party package repositories easy. The instance to be installed within Fedora Infrastructure provides Fedora maintainers with the ability to create repos of packages to build against and share with others."

When I want to test software not packaged in Fedora’s official repos or RPMFusion, or when I want to get a more recent version of a packaged software, I always go there to check if some user built it already and can share a package. As far as my understanding goes, this is the equivalent of the Arch User Repositories, for Fedora systems (and RHEL, Mageia, and OpenSuse). The KDE special interest group uses a copr to build and test the new Plasma releases before pushing them to rawhide repositories and stable release repositories.

Using packages to test software instead of building from source has 2 big advantages :

  • uninstalling the package ensures that no orphan files are left back
  • installing the package from copr means no build dependencies has to be installed on the test machine

Creating a copr repository and package

Issues start to arise when neither packages nor copr has the packages you want to try. For me, the first time it happened was for kitty terminal emulator, which was packaged by Olivier Samyn only for Fedora 28 but not later versions. This is when I decided to go for it and try to create a package using copr to be able to try kitty’s latest versions on my Fedora rawhide main laptop.

Create a FAS account

In order to create a copr repository, you need to have a FAS (Fedora Account System) account. This basically means you can more easily check the reputation of the packager you want to get a repo from (the packages are installed using sudo). There are probably other implications for the load on the build servers and other pure infrastructure reasons, but the traceability is the most important feature here for me.

All contributors have accounts, and you can easily find their achievements or look in which groups they belong if that’s the case.

Create a copr repo

  • Log in on copr website and choose to create a repo.

Project settings

  • Choose a name for the repository (not the package), and fill in the description/information
  • In other options, I like to give internet access (for pip commands for example), and follow fedora branching (since I’m on rawhide)
  • Choose the chroots you want to build the packages in (it will build packages for all the chosen systems)

Package settings

I always build packages using these options :

Source Type: Build from an SCM repository

SCM type: git

Clone URL: https://framagit.org/gagbo/kitty-pkg (the url of the git repo with the spec file)

Build SRPM with: rpkg

In the project settings, there are help to configure automatic builds when there is a push event on the clone URL repository.

Create the .spec file

Arguably the hardest part of having a working repo is to get a .spec file working. Most of the time I just try to find a .spec for a project which looks like building just similarly to the one I want to build, and work starting from there. A few notes :

  • Using variables

    Using variables is good. Most of my updates now are just changing the version number of the package according to the naming scheme of the releases on the github API.

  • Setting BuildRequires and Requires correctly

    Requires will pull dependencies on systems you install the package, BuildRequires is only pulled in the chroot to build the package. Looking at the BuildRequires for my Kitty package, we can see how many packages I don’t have to install to be able to run kitty on my computer (just as all the people who trust me to deliver them kitty).

  • RPM macros

    I don’t master rpm macros for now, this is something I am still learning/copying from other spec files. The important ones are :

    • %prep : used to setup the folders for the build. I don’t think I ever needed to do something different than calling the %autosetup macro
    • %build : all the commands necessary to build. To follow the Fedora guidelines, I look for another package in the same language and copy the flags.
    • %install : the installation commands which put the files in their correct place.
    • %files : the list of files produced (therefore, owned) by the package. This list needs to be accurate so host systems are not corrupted by your package. Thankfully, the copr infrastructure will not update the repository if the package built does not strictly list all artifacts it produced. Reading the build log on failed builds helped me curate the list of %files.
    • %changelog : I don’t really want to become a true official Fedora packager, so keeping a clean changelog allows me to just send my spec file to eventual packagers so they can see the changes I made, if someone wants to start an official package from my .spec files.

Conclusion

Using copr to pull unofficially packaged software is a great way to test software on red hat distributions. And using copr to build unofficially packaged software is a great way to help other users test software.

For me, it started as an effort to learn how software is shipped in linux distributions, and I just build small repos when I want specific software now. I used to package latte-dock (but stopped as I don’t use it anymore, and packaging KDE software with translations is a little more work than just pulling the source code from github), and now I try to maintain the latest tagged versions of Kvantum and kitty terminals for Fedora 28+.

Take care,

Gerry