This section contains information for users of Copr Build System. You can find a running Copr instance at http://copr.fedorainfracloud.org/. You may also be interested in Developer Documentation and Downloads.
If you are completely new to COPR build system, those steps will get you setup quickly:
setup a FAS account here: https://accounts.fedoraproject.org
log in into COPR (link at the top right corner of COPR HP: https://copr.fedorainfracloud.org/)
copy the generated auth token into
install copr-cli tool:
sudo dnf install copr-cli(if you are on Fedora)
copr-cli create first-project --chroot fedora-rawhide-x86_64to create your first project
copr-cli build first-project <path to your srpm>to run your first build
If you don’t have an srpm yet, see https://pagure.io/rpkg-util on how to build one.
Build Source Types¶
Copr supports several types of build sources.
This is currently the only method to submit multiple builds at once. First, you need to upload your SRPM package(s) on a public server and then provide the URL(s) separated by space or a newline. Note that the build order of the individual launched builds is not guaranteed.
You can also just input a URL to an rpm .spec file (package metadata) that describe the package without including the actual build sources. The build sources, being again available on a public server under https, will be then downloaded by COPR automatically during the SRPM build process.
In case, you have your .spec file or srpm stored locally, you can use this method to upload it directly to COPR from a command-line (by using copr-cli tool) or through COPR web UI.
This method allows you to build RPM(s) from any Git, DistGit, or SVN repository containing a valid .spec file. The only required argument is Clone URL and if the target repository places the .spec file together with package sources in the root directory and you want to build from master HEAD, it will simply work. There are more things to configure for more complex cases. E.g. you might want to specify Subdirectory of the target repository if that is where the repository has the package sources placed. See the following list for the full option description:
Type: SCM type of the repository being pointed to by Clone URL (in other words, whether we should use plain git or git svn for subsequent cloning).
Clone URL: What repository we should clone to obtain the sources.
Committish: What tag, branch, or commit we should check out from the history of the cloned repository. By default HEAD of master branch.
Subdirectory: Where the subsequent SRPM build command (see below) should be executed. The path is relative to the repository root.
Spec File: Path to the spec file relative to the given Subdirectory. Note that you can optionally anchor the path with / (e.g. /rpm/example.spec). If not specified the .spec file will be auto-located.
The last optional thing to configure (except for common build configuration option) is the SRPM build method. There are four choices available: rpkg, tito, tito test, and make srpm:
rpkg: The default choice and the most versatile one. Apart from building packages from any Git or SVN repository, it also supports building directly from any DistGit repository. Note that rpkg (as well as tito) is not only a tool to generate SRPMs but, in fact, it is also a full-fledged package manager that you can use from your command-line to maintain your packages. You can read more about this tool here.
tito: is a robust RPM package manager with lots of features and if your project is managed with Tito, this is the tool you want to pick for SRPM generation (which is
one of the many package manager’s features). When this option is selected, the latest package GIT tag will be used to build an SRPM. Note that this utility has currently
no support for specifying an alternative .spec file, which means the Spec Field is simply ignored when this option is used and .spec file will be always auto-located.
Note that the basic difference between this tool and rpkg is that the target repository needs to be initialized with
tito init first before this tool can be used
to build SRPMs from it. You can read more here.
tito test: With this option selected, again the tito utility will be used to build an SRPM but this time, the Committish
value specified above (or HEAD of the master branch if no Committish is specified) will be used to build an SRPM. This corresponds to using
--test switch for
tito when it is invoked to generate the SRPM.
make srpm: With this method, the user himself/herself will provide the executable script to be used for SRPM generation. If you
would like to use this method, you need to provide
.copr/Makefile (path being relative to the repository root) with
in your repository. Into that
srpm target, you can put whatever it takes to generate the SRPM. You can use network and clone another
repository, you can install new packages, and you can do pretty much everything as this is script is run with root privileges inside
a mock chroot. Note that it is run in the mock chroot of the same OS version as the builder host’s (usually the latest released Fedora
version). The Makefile’s target is invoked like this:
make -f <cloned_repodir>/.copr/Makefile srpm outdir="<outdir>" spec="<spec_path>"
spec parameter is what you specify in the Spec File field for the SCM source specification and the script
is run in the Subdirectory that you can optionally specify in the source section as well. Note that you can just ignore
spec file parameter in the script if there is no use for it. The
outdir parameter specifies where to put the resulting
SRPM so that COPR can find and build it afterwards.
Example of what can be put into
$ cd myrepo $ cat .copr/Makefile srpm: dnf -y install tito tito build --builder=SomeBuilder --test --srpm --output=$(outdir)
Note that the other tools (tito and rpkg) are run in the specified Subdirectory as well.
There’s a new option to build from existing DistGit instances in Copr (e.g., from Fedora or CentOS DistGit). To build the foo package from CentOS 8, one can do:
$ copr build-distgit <project> --name foo --distgit centos --commit c8
It’s even easier for a Fedora Rawhide package:
$ copr build-distgit <project> --name foo
because ‘fedora’ distgit is the default, and we automatically pick the default branch.
If you want have your copr project deleted automatically after some time
(because it is some CI/CD project, some testing stuff, etc.) you can set the
“delete after days” option in web UI or on command-line:
copr-cli create your-project ... --delete-after-days 10
Webhooks allows you to automatically trigger build.
First you need to go to your Copr project and tab “Packages” and define some package. The only source type which make sense together with webhooks is “SCM”. Check the “Webhook rebuild” option. You may hit “rebuild” and test the build actually works.
Now you can navigate to “Setting” tab and then “Webhooks” There is your webhook url in the form of https://copr.fedorainfracloud.org/webhooks/github/<ID>/<UUID>/.
Then in your GitHub project, go to Settings / Webhooks and services. Click on the Add webhook button. Fill in the Payload URL field with the url you noted previously. Set the other fields to the values: content: application/json; send just push event; no secret. Click the Add webhook button.
And next time you push anything to your git, Copr will automatically rebuild your package.
For any pagure instance (including src.fedoraproject.org), you can setup Copr auto-rebuilding and pr/commit flagging on new changes landing into a pagure repository and its open pull requests.
On the Pagure side, you need to set Fedmsg to ‘active’ in your project settings (in ‘Hooks’ section almost at the bottom). For some instances (e.g. src.fedoraproject.org), this might already be active by default so you don’t even need to perform this step.
In Copr, you need an SCM package definition, which may be as simple as specifying a public clone URL of the remote Pagure repository, see SCM if you need more detailed settings. Also make sure, “Auto-rebuild” checkbox is checked.
Now your SCM package will get rebuilt on new commits into the main repo as well as into open PRs.
Note that built changes coming from pull requests are not actually placed into the main copr repository. Instead, they are being placed into side repositories
of the names
<pr_id> is ID of the pull request opened in Pagure. On Fedora, you can enable the side repository to test the changes with:
$ sudo dnf copr enable <ownername>/<coprname>:pr:<pr_id>
If you would like to get your commits and pull requests in Pagure flagged with build results for each change, go to project settings in your Pagure project. Then:
In the section “API keys”, create a new API key (check for ‘Flag a …’ options) if you don’t have one created already and copy it
In Copr, go to Settings->Integrations and insert the copied API key into the second field in ‘Pagure’ section
Into the first field, insert Pagure project URL that you can just copy from browser address bar if you are on the project homepage
Click ‘Submit’ and you are done.
You can look here for how to do this: COPR auto-rebuilds with custom Git repositories
In Copr, you cannot build an i386 package into x86_64 repository (also known as
multilib package) like e.g. in Koji. You can though build for both
multilib-pair chroots (e.g.
separately, and users can enable both multilib-pair repositories - so in turn
all built 32bit and 64bit packages will be available concurrently.
If you want to automatize this, specify that your project is supposed to be “multilib capable”. Either in commandline:
copr create --multilib=on [other options]
or by checkbox on
Project -> Settings web-UI page.
When (a) this feature is enabled for project and (b) the project also contains
multilib-pair chroots, the relevant copr web-UI project page will also provide
multilib repo files button (aside the normal one) so user can pick those. On
top of that,
dnf copr enable <owner>/<project> installs the multilib
repofile automatically instead of the normal one on multilib capable system.
Users can also manually install the multilib repofiles on multilib capable system regardless of the project settings, those repofile can e.g. look like:
$ cat /etc/yum.repos.d/rhughes-f20-gnome-3-12.repo [copr:copr.fedorainfracloud.org:rhughes:gnome-3-12] name=Copr repo for f20-gnome-3-12 owned by rhughes baseurl=http://copr-be.cloud.fedoraproject.org/results/rhughes/f20-gnome-3-12/fedora-$releasever-$basearch/ skip_if_unavailable=True gpgcheck=0 enabled=1 [copr:copr.fedorainfracloud.org:rhughes:gnome-3-12:ml] name=Copr repo for f20-gnome-3-12 owned by rhughes (i386) baseurl=http://copr-be.cloud.fedoraproject.org/results/rhughes/f20-gnome-3-12/fedora-$releasever-i386/ skip_if_unavailable=True gpgcheck=0 cost=1100 enabled=1
Do you want to add such badge:
to your page? E.g. to GitHub README.md? You can use those urls:
And this badge will reflect current status of your package.
Copr can sustain mass-rebuilds and projects with thousands of packages and builds. A typical use-case for this can be rebuilding all Fedora packages with some proposal change or rebuilding programming-language modules (PyPI, RubyGems) as RPMs.
Please follow these recommendations to have the smoothest experience:
If possible, let us know in advance, so we pay closer attention to the server load and making sure everything functions as it should. Please see the preferred communication channels
Creating AppStream metadata is too slow for large repositories, you might want to disable it. Users cannot do this by themselves yet, so please ping any admin to touch
.disable-appstreamfile into your project directory on the backend
When submitting builds, please use
--backgroundparameter to make them deprioritized by scheduler (compared to normal builds). It’s a nice gesture to other users.
If possible, don’t submit all builds at once but rather 1k-5k at the time and wait for Copr to process them
Use Build batches to specify the order of your builds in advance. This is useful when some of the packages use other packages in the project as dependencies and need to wait until they are built
Use pagination when accessing the project packages and builds through API
A build batches feature allows you to define the order of your builds in advance. This feature is also available in the web-UI, but it is more convenient from the command-line:
$ copr build <project> --no-wait <first.src.rpm> Created builds: 101010 $ copr build <project> --no-wait <second.src.rpm> --after-build-id 101010 Created builds: 101020 $ copr build <project> --no-wait <third.src.rpm> --with-build-id 101020 Created builds: 101030
This will create two batches (first with one build 101010 and second with two builds 101020 and 101030), where second batch isn’t started till Copr finishes the first one. This way, you can build a tree of dependant build batches according to your project needs. See also a related blog post <https://pavel.raiskup.cz/blog/build-ordering-by-batches-in-copr.html> which goes a little bit more into detail.
Automatic run of Fedora Review tool¶
There’s a new per-project config option (e.g.
copr create --fedora-review)
that triggers an automatic run of Fedora Review after each build in such
project, for now only in the
We don’t mark the build failed when the review tool fails for now, and it is up
to the end-user to check the review results in the new
that is created in build results.
Quick HOWTO for the Package Review time:
$ copr create review-foo-component --chroot fedora-rawhide-x86_64 --fedora-review $ copr build review-foo-component ./foo.src.rpm ... # wait and see the results!
What is the purpose of Copr? ¶
Copr is a build system available for everybody. You provide the src.rpm and Copr provides a yum repository. Copr can be used for upstream builds, for continuous integration, or to provide a yum repository for users of your project, if your project is not yet included in the standard Fedora repositories.
You will need a FAS account in order to get started.
What I can build in Copr? ¶
You agree not to use Copr to upload software code or other material (“Material”) that:
you do not have the right to upload or use, such as Material that infringes the rights of any third party under intellectual property or other applicable laws;
is governed in whole or in part by a license not contained in the list of acceptable licenses for Fedora, currently located at https://fedoraproject.org/wiki/Licensing, as that list may be revised from time to time by the Fedora Council;
is categorized as a “Forbidden Item” at https://fedoraproject.org/wiki/Forbidden_items, as that page may be revised from time to time by the Fedora Council;
is designed to interfere with, disable, overburden, damage, impair or disrupt Copr or Fedora Project infrastructure;
violates any applicable laws and regulations.
It is your responsibility to check licenses and to be sure you can make the resulting yum repo public.
If you think that some repo may be violating a license, you can raise a legal flag - there is a dedicated text area in each project to do so. This will send a notification to the admins and we will act accordingly.
It would be nice if you stated the license of your packages in the Description or Install instructions.
Packages in Copr do not need to follow the Fedora Packaging Guidelines, though they are recommended to do so. In particular, kernel modules may be built in Copr, as long as they don’t violate the license requirements in point 2. above.
Is it safe to use Copr? ¶
This is a two-part question.
1) Can we trust Copr as a platform?
Copr is free software with its code publicly available for review by anyone. Internally, it uses the standard Fedora packaging toolset, and resulting repositories are signed. All Copr servers are deployed within Fedora infrastructure, and we work closely with the Fedora Infrastructure team.
2) Can we trust the software available in Copr?
Only people with FAS accounts are allowed to create projects and build packages in Copr. That means that you can find out more information about each project owner and decide for yourself whether you find them trustworthy or not. You can also see how exactly each build was submitted, download its SRPM file, and validate the sources and spec file for yourself.
How can I enable a Copr repository? ¶
See How to enable repo.
How can I package software as RPM? ¶
There are several tutorials:
Can I build for different versions of Fedora? ¶
Yes. Just hit the “Edit” tab in your project and select several chroots, e.g. “fedora-19-x86_64” and “fedora-18-x86_64”. After doing so, when you submit the src.rpm, your package will be built for both of those selected versions of Fedora.
You can build for EPEL as well.
Can I have more yum repositories? ¶
Yes. Each user can have more than one project and each project has one yum repository - to be more precise one repository per chroot.
Can I submit multiple builds at once? ¶
Yes. Just separate them by a space or a new line, but keep in mind that we do not guarantee build order.
What happens when I try to build a package with the same version number? ¶
Nothing special. Your package will just be rebuilt again.
Can I depend on other packages, which are not in Fedora/EPEL? ¶
Yes, they just need to be available in some yum repository. It can either be another Copr repo or a third-party yum repo (e.g jpackage). Click on “Edit” in your project and add the appropriate repositories into the “Repos” field. Packages from your project are available to be used at build time as well, but only for the project you are currently building and not from your other projects.
Can I give access to my repo to my team mate? ¶
Yes. If somebody wants to build into your project and you want give them access, just point them to your Copr project page. They should then click on the “Permission” tab, and request the permissions they want. “Builder” can only submit builds and “Admin” can approve permissions requests. You will then have to navigate to the same “Permission” tab and either approve or reject the request.
Do you have a command-line client? ¶
Yes. Just do
dnf install copr-cli and learn more by
Do you have an API? ¶
Yes. See the link in the footer of every Copr page or jump directly to the API page.
How long do you keep the builds? ¶
We keep one build for each package in one project indefinitely. All other builds (old packages, failed builds) are deleted after 14 days.
Note that we keep the build with the greatest EPOCH:NAME-VERSION-RELEASE, even though that build might not be the newest one. Also, if there are two builds of the same package version, it is undefined which one is going to be kept.
How is Copr pronounced? ¶
In American English Copr is pronounced /ˈkɑ.pɚ/ like the metallic element spelled “copper”.
Why another buildsystem? ¶
We didn’t start off to create another buildsystem. We originally just wanted to make building third party rpm repositories easier, but after talking to the koji developers and the developers who are building packages for CentOS we realized that there was a need for a maintainable, pluggable, and lightweight build system.
Did you consider OBS? ¶
Can I get notifications from Copr builds? ¶
Yes, you can. Enable email/irc/android notifications at Fedora notifications service.
See blog post how to consume copr messages from bus.
What does Copr mean? ¶
Community projects (formerly Cool Other Package Repositories)
How can I tell yum to prefer Copr packages? ¶
Building a package with the same version-release number in Copr as the package distributed in the official Fedora repos is discouraged. You should instead bump the release number. Should you build with the same version-release number, you can tell yum to prefer the Copr packages over the distribution provided packages by adding cost=900 to the .repo file.
Can Copr build directly from git? ¶
Yes, it can. See SCM source type.
If you want to know more about tools to generate srpm from a Git repo, see:
Why doesn’t Copr download my updated package? ¶
Sometimes people report that even though they have updated the src.rpm file and submitted the new build, Copr is still using the old src.rpm. This is typically caused when changes are made to the src.rpm file, but the release number was not bumped up accordingly. As a consequence the resulting files have the same URL, so your browser does not bother to fetch new log files and continues to show those files in its cache. Therefore you are still seeing old content from the previous task.
You should press Ctrl+Shift+R to invalidate your cache and reload page
How can I create new group? ¶
Groups membership is handled by FAS. It can add/remove members to existing group. However it cannot create new group. You can create new group by creating new fedora-infra ticket. You have to log out and then log in again to Copr so Copr can read your new settings.
Once copr knows the FAS groups you belong to, you still need to activate the
group. Go to my groups
page and click on the
Activate this group button.
I see some strange error about /devel/repodata/ in logs. ¶
This is intended. In fact in next release there will be something like “Please ignore the error above”.
This is part of feature where you can check in your settings “Create repositories manually”. This is intended for big projects like Gnome or KDE, which consist of hundreds of packages. And you want to release them all at the same time. But on the other hand it take days to build them. And of course during the buildtime you need to enable that repository, while at the same time have it disabled/frozen for users.
So if you check “Create repositories manually”, we do not run createrepo_c in normal directory, but in ./devel/ directory.
This is directory is always passed to mock with
So if Copr have it, then it is used, otherwise ignored. But if it is missing DNF/YUM print the warning above even if it
is ignored. Currently there is no way to tell DNF/YUM to not print this warning.
How can I affect the build order, is there a “chain” build support? ¶
Build batches can be used to guarantee the order in which the builds are processed (one build batch can depend on other build batch). See blog post with examples for more info.
Build succeeded, but I don’t see the built results? ¶
Fedora Copr uses the AWS CDN to spread the HTTP traffic on the built RPM repositories across the globe, and it implies a lot of caching on the AWS side.
When you (or anyone else in your territory) check the build directory while the build is still in progress, the web server directory listing gets cached in CDN - and then the contents of the directory appears unchanged for some time (even though the build might already be finished and thus the directory updated).
Don’t worry, this caching doesn’t affect the DNF/YUM behavior - so even though your browser is misled by caches, package managers always download the latest contents of the directories. Either please ignore the inconsistency, or visit the non-cached host variant.
I have a problem and I need to talk to a human. ¶
We do not provide support per se, but try your luck here: Communication