CINXE.COM

<!DOCTYPE html> <html class="writer-html5" lang="en" data-content_root="./"> <head> <meta charset="utf-8" /><meta name="viewport" content="width=device-width, initial-scale=1" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>User Documentation — COPR documentation</title> <link rel="stylesheet" type="text/css" href="_static/pygments.css?v=fa44fd50" /> <link rel="stylesheet" type="text/css" href="_static/css/theme.css?v=330c1f8c" /> <link rel="stylesheet" type="text/css" href="_static/site.css?v=70d7d903" /> <script src="_static/documentation_options.js?v=5929fcd5"></script> <script src="_static/doctools.js?v=888ff710"></script> <script src="_static/sphinx_highlight.js?v=dc90522c"></script> <script src="_static/js/theme.js"></script> <link rel="index" title="Index" href="genindex.html" /> <link rel="search" title="Search" href="search.html" /> <link rel="next" title="Pagure Integration" href="user_documentation/pagure_integration.html" /> <link rel="prev" title="Copr Buildsystem" href="index.html" /> </head> <body class="wy-body-for-nav"> <div class="wy-grid-for-nav"> <nav data-toggle="wy-nav-shift" class="wy-nav-side"> <div class="wy-side-scroll"> <div class="wy-side-nav-search" > <a href="index.html"> <img src="_static/copr-logo-transparent.png" class="logo" alt="Logo"/> </a> <div role="search"> <form id="rtd-search-form" class="wy-form" action="search.html" method="get"> <input type="text" name="q" placeholder="Search docs" aria-label="Search docs" /> <input type="hidden" name="check_keywords" value="yes" /> <input type="hidden" name="area" value="default" /> </form> </div> </div><div class="wy-menu wy-menu-vertical" data-spy="affix" role="navigation" aria-label="Navigation menu"> <ul class="current"> <li class="toctree-l1 current"><a class="current reference internal" href="#">User Documentation</a><ul> <li class="toctree-l2"><a class="reference internal" href="#quick-start">Quick start</a></li> <li class="toctree-l2"><a class="reference internal" href="#tutorial">Tutorial</a></li> <li class="toctree-l2"><a class="reference internal" href="#how-to-enable-copr-repository">How to enable copr repository?</a></li> <li class="toctree-l2"><a class="reference internal" href="#public-copr-instances">Public Copr instances</a></li> <li class="toctree-l2"><a class="reference internal" href="#build-source-types">Build Source Types</a><ul> <li class="toctree-l3"><a class="reference internal" href="#urls">URLs</a></li> <li class="toctree-l3"><a class="reference internal" href="#direct-upload">Direct Upload</a></li> <li class="toctree-l3"><a class="reference internal" href="#scm">SCM</a></li> <li class="toctree-l3"><a class="reference internal" href="#distgit">DistGit</a></li> <li class="toctree-l3"><a class="reference internal" href="#pypi">PyPI</a></li> <li class="toctree-l3"><a class="reference internal" href="#rubygems">RubyGems</a></li> <li class="toctree-l3"><a class="reference internal" href="#custom-script">Custom (script)</a></li> </ul> </li> <li class="toctree-l2"><a class="reference internal" href="#working-with-packages">Working with Packages</a></li> <li class="toctree-l2"><a class="reference internal" href="#reproducing-the-builds-locally">Reproducing the builds locally</a></li> <li class="toctree-l2"><a class="reference internal" href="#ssh-access-to-copr-builders">SSH access to Copr builders</a></li> <li class="toctree-l2"><a class="reference internal" href="#temporary-projects">Temporary projects</a></li> <li class="toctree-l2"><a class="reference internal" href="#webhooks">Webhooks</a><ul> <li class="toctree-l3"><a class="reference internal" href="#triggerring-builds-by-tag-events">Triggerring builds by tag events</a></li> <li class="toctree-l3"><a class="reference internal" href="#github">GitHub</a></li> <li class="toctree-l3"><a class="reference internal" href="#gitlab">Gitlab</a></li> <li class="toctree-l3"><a class="reference internal" href="#bitbucket">Bitbucket</a></li> <li class="toctree-l3"><a class="reference internal" href="#custom-webhook">Custom webhook</a></li> </ul> </li> <li class="toctree-l2"><a class="reference internal" href="#pagure-integration">Pagure Integration</a><ul> <li class="toctree-l3"><a class="reference internal" href="user_documentation/pagure_integration.html">How to automatize Copr builds upon Pagure forge events</a></li> </ul> </li> <li class="toctree-l2"><a class="reference internal" href="#custom-location-webhooks">Custom-location Webhooks</a></li> <li class="toctree-l2"><a class="reference internal" href="#links">Links</a></li> <li class="toctree-l2"><a class="reference internal" href="#multilib">Multilib</a></li> <li class="toctree-l2"><a class="reference internal" href="#advanced-searching">Advanced searching</a></li> <li class="toctree-l2"><a class="reference internal" href="#status-badges">Status Badges</a></li> <li class="toctree-l2"><a class="reference internal" href="#mass-rebuilds">Mass rebuilds</a></li> <li class="toctree-l2"><a class="reference internal" href="#build-batches">Build batches</a></li> <li class="toctree-l2"><a class="reference internal" href="#automatic-run-of-fedora-review-tool">Automatic run of Fedora Review tool</a></li> <li class="toctree-l2"><a class="reference internal" href="#rpm-macros">RPM Macros</a></li> <li class="toctree-l2"><a class="reference internal" href="#creating-repositories-manually">Creating repositories manually</a></li> <li class="toctree-l2"><a class="reference internal" href="#high-performance-builders">High Performance Builders</a></li> <li class="toctree-l2"><a class="reference internal" href="#subprojects">Subprojects</a></li> <li class="toctree-l2"><a class="reference internal" href="#modularity">Modularity</a></li> <li class="toctree-l2"><a class="reference internal" href="#faq">FAQ</a></li> </ul> </li> <li class="toctree-l1"><a class="reference internal" href="release_notes.html">Upstream Release Notes</a></li> <li class="toctree-l1"><a class="reference internal" href="developer_documentation.html">Developer Documentation</a></li> <li class="toctree-l1"><a class="reference internal" href="maintenance_documentation.html">Maintenance Documentation</a></li> <li class="toctree-l1"><a class="reference internal" href="downloads.html">Downloads</a></li> <li class="toctree-l1"><a class="reference internal" href="brainstorming.html">Brainbox</a></li> <li class="toctree-l1"><a class="reference internal" href="features.html">Features</a></li> </ul> </div> </div> </nav> <section data-toggle="wy-nav-shift" class="wy-nav-content-wrap"><nav class="wy-nav-top" aria-label="Mobile navigation menu" > <a href="index.html">COPR</a> </nav> <div class="wy-nav-content"> <div class="rst-content"> <div role="navigation" aria-label="Page navigation"> <ul class="wy-breadcrumbs"> <li><a href="index.html" class="icon icon-home" aria-label="Home"></a></li> <li class="breadcrumb-item active">User Documentation</li> <li class="wy-breadcrumbs-aside"> <a href="_sources/user_documentation.rst.txt" rel="nofollow"> View page source</a> </li> </ul> <hr/> </div> <div role="main" class="document" itemscope="itemscope" itemtype="http://schema.org/Article"> <div itemprop="articleBody"> <section id="user-documentation"> <h1>User Documentation<a class="headerlink" href="#user-documentation" title="Link to this heading">¶</a></h1> This section contains information for users of the Copr Build System. You can find a running Copr instance at <a class="reference external" href="http://copr.fedorainfracloud.org/">http://copr.fedorainfracloud.org/</a>. You may also be interested in the <a class="reference internal" href="developer_documentation.html#developer-documentation">Developer Documentation</a> and <a class="reference internal" href="downloads.html#downloads">Downloads</a>. <section id="quick-start"> <h2>Quick start<a class="headerlink" href="#quick-start" title="Link to this heading">¶</a></h2> If you are completely new to the COPR build system, follow these steps to get set up quickly: <ol class="arabic simple"> <li>Set up a FAS account here: <a class="reference external" href="https://accounts.fedoraproject.org">https://accounts.fedoraproject.org</a>.</li> <li>Log in to COPR (link at the top right corner of the COPR homepage: <a class="reference external" href="https://copr.fedorainfracloud.org/">https://copr.fedorainfracloud.org/</a>).</li> <li>Visit <a class="reference external" href="https://copr.fedorainfracloud.org/api/">https://copr.fedorainfracloud.org/api/</a>.</li> <li>Copy the generated authentication token into your <code class="docutils literal notranslate">~/.config/copr</code> file.</li> <li>Install the copr-cli tool: <code class="docutils literal notranslate">sudo dnf install copr-cli</code> (if you are using Fedora).</li> <li>Run <code class="docutils literal notranslate">copr-cli create first-project --chroot fedora-rawhide-x86_64</code> to create your first project.</li> <li>Run <code class="docutils literal notranslate">copr-cli build first-project <path to your SRPM></code> to initiate your first build.</li> </ol> If you don’t have an SRPM yet, see <a class="reference external" href="https://rpm-packaging-guide.github.io/">https://rpm-packaging-guide.github.io/</a> for instructions on how to build one. </section> <section id="tutorial"> <h2>Tutorial<a class="headerlink" href="#tutorial" title="Link to this heading">¶</a></h2> Refer to <a class="reference internal" href="screenshots_tutorial.html#screenshots-tutorial">Screenshots tutorial</a> or <a class="reference internal" href="video_tutorial.html#video-tutorial">Video tutorial</a> for guidance on interacting with <a class="reference external" href="http://copr.fedoraproject.org/">copr.fedoraproject.org</a>. </section> <section id="how-to-enable-copr-repository"> <h2>How to enable copr repository?<a class="headerlink" href="#how-to-enable-copr-repository" title="Link to this heading">¶</a></h2> <a class="reference internal" href="how_to_enable_repo.html#how-to-enable-repo">How to enable repo</a> </section> <section id="public-copr-instances"> <h2>Public Copr instances<a class="headerlink" href="#public-copr-instances" title="Link to this heading">¶</a></h2> Copr is a free software and anyone can maintain their own instance in case the Fedora Copr instance doesn’t suit their needs. This is a list of known Copr instances: <table class="docutils align-default"> <thead> <tr class="row-odd"><th class="head">Instance</th> <th class="head">Description</th> <th class="head">Links</th> </tr> </thead> <tbody> <tr class="row-even"><td><a class="reference external" href="https://copr.fedorainfracloud.org">https://copr.fedorainfracloud.org</a></td> <td><div class="line-block"> <div class="line"> </div> <div class="line">Fedora Copr instance which is also</div> <div class="line">considered to be the default Copr</div> <div class="line">instance by many users and tools.</div> </div> </td> <td><a class="reference external" href="https://docs.pagure.org/copr.copr/index.html#communication">Contact</a>, <a class="reference external" href="https://github.com/fedora-copr/copr/issues">Issues</a></td> </tr> <tr class="row-odd"><td><a class="reference external" href="https://copr.stg.fedoraproject.org">https://copr.stg.fedoraproject.org</a></td> <td><div class="line-block"> <div class="line"> </div> <div class="line">Fedora Copr staging instance is useful for</div> <div class="line">testing the upcoming changes.</div> <div class="line">We periodically delete all its data.</div> </div> </td> <td></td> </tr> <tr class="row-even"><td><a class="reference external" href="https://eur.openeuler.openatom.cn">https://eur.openeuler.openatom.cn</a></td> <td>openEuler Copr instance</td> <td><a class="reference external" href="https://mailweb.openeuler.org/hyperkitty/list/infra@openeuler.org/">Contact</a>, <a class="reference external" href="https://quickissue.openeuler.org/en/issues/">Issues</a></td> </tr> </tbody> </table> </section> <section id="build-source-types"> <h2>Build Source Types<a class="headerlink" href="#build-source-types" title="Link to this heading">¶</a></h2> Copr supports several types of build sources. <section id="urls"> <h3>URLs<a class="headerlink" href="#urls" title="Link to this heading">¶</a></h3> 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. </section> <section id="direct-upload"> <h3>Direct Upload<a class="headerlink" href="#direct-upload" title="Link to this heading">¶</a></h3> 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. </section> <section id="scm"> <h3>SCM<a class="headerlink" href="#scm" title="Link to this heading">¶</a></h3> 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: <ul class="simple"> <li>Type: SCM type of the repository being pointed to by Clone URL (in other words, whether we should use plain <cite>git</cite> or <cite>git svn</cite> for subsequent cloning).</li> <li>Clone URL: What repository we should clone to obtain the sources.</li> <li>Committish: What tag, branch, or commit we should check out from the history of the cloned repository. By default HEAD of master branch.</li> <li>Subdirectory: Where the subsequent SRPM build command (see below) should be executed. The path is relative to the repository root.</li> <li>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.</li> </ul> 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 method. Apart from building packages from any Git or SVN repository, it also supports building directly from <a class="reference external" href="https://clime.github.io/2017/05/20/DistGit-1.0.html">DistGit</a> repositories. Note that rpkg (as well as tito below) 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 (upstream) projects. You can read more about this tool <a class="reference external" href="https://pagure.io/rpkg-util">here</a>. Note that starting from December 2021, Copr migrated to the rpkg-util v3, and so <a class="reference internal" href="rpkg_util_2_vs_3.html#rpkg-util-v3">your spec files need to use the {{{ }}} templates to comply</a>. 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 <code class="docutils literal notranslate">tito init</code> first before this tool can be used to build SRPMs from it. You can read more <a class="reference external" href="https://github.com/dgoodwin/tito">here</a>. tito test: With this option selected, again the <a class="reference external" href="https://github.com/dgoodwin/tito">tito</a> 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 <code class="docutils literal notranslate">--test</code> switch for <code class="docutils literal notranslate">tito</code> 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 <code class="docutils literal notranslate">.copr/Makefile</code> (path being relative to the repository root) with <code class="docutils literal notranslate">srpm</code> target in your repository. Into that <code class="docutils literal notranslate">srpm</code> 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: <div class="highlight-default notranslate"><div class="highlight"><pre>make -f <cloned_repodir>/.copr/Makefile srpm outdir="<outdir>" spec="<spec_path>" </pre></div> </div> The <code class="docutils literal notranslate">spec</code> 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 the <code class="docutils literal notranslate">spec</code> file parameter in the script if there is no use for it. The <code class="docutils literal notranslate">outdir</code> parameter specifies where to put the resulting SRPM so that COPR can find and build it afterwards. Example of what can be put into <code class="docutils literal notranslate">.copr/Makefile</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>$ cd myrepo $ cat .copr/Makefile srpm: dnf -y install tito tito build --builder=SomeBuilder --test --srpm --output=$(outdir) </pre></div> </div> Note that the other tools (tito and rpkg) are run in the specified Subdirectory as well. </section> <section id="distgit"> <h3>DistGit<a class="headerlink" href="#distgit" title="Link to this heading">¶</a></h3> There’s a new option to build from existing DistGit instances in Copr (e.g., from Fedora or CentOS DistGit). To build the <cite>foo</cite> package from CentOS 8, one can do: <div class="highlight-default notranslate"><div class="highlight"><pre>$ copr build-distgit <project> --name foo --distgit centos --commit c8 </pre></div> </div> It’s even easier for a Fedora Rawhide package: <div class="highlight-default notranslate"><div class="highlight"><pre>$ copr build-distgit <project> --name foo </pre></div> </div> because ‘fedora’ distgit is the default, and we automatically pick the default branch. <div class="admonition note"> Note Please note that an SRPM is downloaded from the specified DistGit instance only once per Copr build, regardless of the number of chroots you build for. It is not the case that within one Copr build, e.g. <code class="docutils literal notranslate">fedora-37-x86_64</code> chroot would be built from the <code class="docutils literal notranslate">f37</code> branch, <code class="docutils literal notranslate">fedora-38-x86_64</code> from the <code class="docutils literal notranslate">f38</code> branch, and <code class="docutils literal notranslate">fedora-39-x86_64</code> from the <code class="docutils literal notranslate">rawhide</code> branch. You can, however, use the Committish field to specify what DistGit branch should be used (by default, it is <code class="docutils literal notranslate">rawhide</code> for <a class="reference external" href="https://src.fedoraproject.org/">Fedora DistGit</a>). The sources from your DistGit branch (e.g. <code class="docutils literal notranslate">rawhide</code>) can be incompatible with some of the target chroots (e.g. <code class="docutils literal notranslate">epel-8-x86_64</code>) because of different dependencies, build tooling, etc. A typical workaround is to submit multiple builds, e.g.: <div class="highlight-default notranslate"><div class="highlight"><pre>copr build-distgit ping --name <package> --chroot fedora-rawhide-x86_64 --commit rawhide copr build-distgit ping --name <package> --chroot epel-8-x86_64 --commit epel8 </pre></div> </div> </div> </section> <section id="pypi"> <h3>PyPI<a class="headerlink" href="#pypi" title="Link to this heading">¶</a></h3> With this source type, you can build python packages directly from <a class="reference external" href="https://pypi.python.org/pypi">https://pypi.python.org/pypi</a>. COPR translates those packages to src.rpm packages automatically by using <a class="reference external" href="https://github.com/fedora-python/pyp2rpm">pyp2rpm</a> tool. </section> <section id="rubygems"> <h3>RubyGems<a class="headerlink" href="#rubygems" title="Link to this heading">¶</a></h3> Similarly to PyPI source type, this allows building gems from <a class="reference external" href="https://rubygems.org/">https://rubygems.org/</a>. The tool for package translation here is <a class="reference external" href="https://github.com/fedora-ruby/gem2rpm">gem2rpm</a>. </section> <section id="custom-script"> <h3>Custom (script)<a class="headerlink" href="#custom-script" title="Link to this heading">¶</a></h3> This source type uses a user-defined script to generate sources (which are later used to create SRPM). For more info, have a look at <a class="reference internal" href="custom_source_method.html#custom-source-method">Custom source method</a>. </section> </section> <section id="working-with-packages"> <h2>Working with Packages<a class="headerlink" href="#working-with-packages" title="Link to this heading">¶</a></h2> Specifying the source build method (see above) with each package build would be quite inconvenient. However, it is possible to define a package in a Copr project with the default source and then trigger the builds using just the command <code class="docutils literal notranslate">copr build-package OWNER/PROJECT --name PACKAGE_NAME</code>. To add or modify the <code class="docutils literal notranslate">PACKAGE_NAME</code> default source, check <code class="docutils literal notranslate">man copr</code> for the <code class="docutils literal notranslate">copr add-package-*</code> and <code class="docutils literal notranslate">copr edit-package-*</code> commands’ descriptions. For example, the <code class="docutils literal notranslate">copr build-distgit</code> build command has the <code class="docutils literal notranslate">copr add-package-distgit</code> and <code class="docutils literal notranslate">copr edit-package-distgit</code> counterparts. The <code class="docutils literal notranslate">PACKAGE_NAME</code> default source entry is also created with the very first package build in the project. Therefore, after the <code class="docutils literal notranslate">copr build-distgit</code> action, you can skip the <code class="docutils literal notranslate">add-package-*</code> command and go directly to the <code class="docutils literal notranslate">edit-package-*</code> command. See the <a class="reference external" href="https://www.youtube.com/watch?v=ASSqempxCSI">Demo: Working with packages</a> </section> <section id="reproducing-the-builds-locally"> <h2>Reproducing the builds locally<a class="headerlink" href="#reproducing-the-builds-locally" title="Link to this heading">¶</a></h2> There’s a separate document <a class="reference internal" href="user_documentation/reproducing_builds.html#reproducing-builds">Reproducing Copr builds locally</a>. </section> <section id="ssh-access-to-copr-builders"> <h2>SSH access to Copr builders<a class="headerlink" href="#ssh-access-to-copr-builders" title="Link to this heading">¶</a></h2> Sometimes it is useful to manually debug failed builds not locally but within the Copr infrastructure. That’s why it is possible to allow SSH access to a copr builder. More information in the <a class="reference external" href="https://frostyx.cz/posts/ssh-access-to-copr-builders">SSH access to Copr builders</a> blog post. </section> <section id="temporary-projects"> <h2>Temporary projects<a class="headerlink" href="#temporary-projects" title="Link to this heading">¶</a></h2> 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: <code class="docutils literal notranslate">copr-cli create your-project ... --delete-after-days 10</code> </section> <section id="webhooks"> <h2>Webhooks<a class="headerlink" href="#webhooks" title="Link to this heading">¶</a></h2> Set up an integration with a Git hosting website and get Copr rebuilds for pull requests, tags and commits. <dl class="simple"> <dt>Simple guide:</dt><dd><ol class="arabic simple"> <li>Create an SCM package and set its default source by specifying an <a class="reference external" href="https://">https://</a> “Clone URL”.</li> <li>Make sure the package auto-rebuild option is checked.</li> <li>Now you can navigate to Setting tab and then Integrations</li> <li>There is your webhook url in the form of <code class="docutils literal notranslate">https://copr.fedorainfracloud.org/webhooks/<GIT_FORGE>/<ID>/<UUID>/</code></li> <li>Finish it by following the Git host specific guide below.</li> </ol> </dd> </dl> And next time you push anything to your git, Copr will automatically rebuild your package. <section id="triggerring-builds-by-tag-events"> <h3>Triggerring builds by tag events<a class="headerlink" href="#triggerring-builds-by-tag-events" title="Link to this heading">¶</a></h3> One forge may have multiple packages. For this reason, Copr needs to know what package or set of packages should be rebuilt for the tag event. Copr gets this information from the name of the tag, so it is important that the tag contains the name of the package, in a predefined format, that will have to rebuild. The tag name should be in this format: <code class="docutils literal notranslate">PKGNAME-VERSION[-RELEASE]</code> with possibility of replacing the dash with an underscore. In case you use different tag name patterns (different Copr package name than tag name), Copr has no idea what package build should be triggered. You have to be explicit and tell Copr your copr package name in the webhook URL like this <code class="docutils literal notranslate">https://copr.fedorainfracloud.org/webhooks/<GIT_FORGE>/<ID>/<UUID>/<copr_package_name>/</code>. Consider this example: Your Copr package name is my-package and tag name on Github is only a version e.g. 1.22.3, in that case you have to add an optional argument to your URL containing your copr package name. So if your Copr package name is my-package your Github URL would be: <code class="docutils literal notranslate">https://copr.fedorainfracloud.org/webhooks/github/<ID>/<UUID>/my_package/</code> </section> <section id="github"> <h3>GitHub<a class="headerlink" href="#github" title="Link to this heading">¶</a></h3> <dl class="simple"> <dt>How to use it:</dt><dd><ol class="arabic simple"> <li>In your GitHub project, go to Settings / Webhooks</li> <li>Click on the Add webhook button.</li> <li>Fill in the Payload URL field with the url above.</li> <li>Select application/json as the content type.</li> <li>If you want to react to Tag push events click Let me select individual events. and then select Branch or tag creation.</li> <li>Click the Add webhook button.</li> </ol> </dd> </dl> </section> <section id="gitlab"> <h3>Gitlab<a class="headerlink" href="#gitlab" title="Link to this heading">¶</a></h3> <dl class="simple"> <dt>How to use it:</dt><dd><ol class="arabic simple"> <li>In your GitLab project, go to Settings / Webhooks.</li> <li>Fill in the URL field with the url above.</li> <li>Select Push events and Tag push events (if you want to react to tags) as event triggers.</li> <li>Click the Add webhook button.</li> </ol> </dd> </dl> </section> <section id="bitbucket"> <h3>Bitbucket<a class="headerlink" href="#bitbucket" title="Link to this heading">¶</a></h3> <dl class="simple"> <dt>How to use it:</dt><dd><ol class="arabic simple"> <li>In your Bitbucket project, go to Settings / Workflow / integrations / Add webhook.</li> <li>Name the hook, e.g., Copr.</li> <li>Fill in the URL field with the url above.</li> <li>Select to trigger on Repository Push.</li> <li>Click the Save button.</li> </ol> </dd> </dl> </section> <section id="custom-webhook"> <h3>Custom webhook<a class="headerlink" href="#custom-webhook" title="Link to this heading">¶</a></h3> How to use it: Use the GitLab/GitHub/Bitbucket steps above (when needed), or simply: <div class="highlight-default notranslate"><div class="highlight"><pre>$ curl -X POST https://copr.fedorainfracloud.org/webhooks/custom/<ID>/<UUID>/<PACKAGE_NAME>/ </pre></div> </div> Note that the package of name ‘PACKAGE_NAME’ must exist within this project, and that the ‘POST’ http method must be specified. With custom webhook(s), you can upload data like: <div class="highlight-default notranslate"><div class="highlight"><pre>$ curl -X POST --data "hook payload data" .... </pre></div> </div> If the <code class="docutils literal notranslate">PACKAGE_NAME</code> package configured in your project uses the script-like “Custom” build method, the POST data will be available as a <code class="docutils literal notranslate">$(CWD)/hook_data</code> file while generating RPM sources. You can handle this fila according to your needs in the custom script. There’s an advanced possibility to call the custom webhook like: <div class="highlight-default notranslate"><div class="highlight"><pre>$ curl -X POST https://copr.fedorainfracloud.org/webhooks/custom-dir/<OWNER>/<PROJECTNAME>:custom:<SUFFIX>/<UUID>/<PACKAGE_NAME>/ $ curl -X POST https://copr.fedorainfracloud.org/webhooks/custom-dir/<OWNER>/<PROJECTNAME>:pr:<INT_UID>/<UUID>/<PACKAGE_NAME>/ </pre></div> </div> This way, the build is placed into a custom directory (e.g. <code class="docutils literal notranslate">myproject:custom:pull-request:1</code> or <code class="docutils literal notranslate">myproject:pr:123</code>). The <code class="docutils literal notranslate">:pr:</code> sub-directories have a retention policy; every such directory is automatically removed after 40 days of build inactivity. </section> </section> <section id="pagure-integration"> <h2>Pagure Integration<a class="headerlink" href="#pagure-integration" title="Link to this heading">¶</a></h2> <div class="toctree-wrapper compound"> <ul> <li class="toctree-l1"><a class="reference internal" href="user_documentation/pagure_integration.html">How to automatize Copr builds upon Pagure forge events</a><ul> <li class="toctree-l2"><a class="reference internal" href="user_documentation/pagure_integration.html#auto-rebuilding">Auto-rebuilding</a></li> <li class="toctree-l2"><a class="reference internal" href="user_documentation/pagure_integration.html#pr-commit-flagging">PR/commit flagging</a></li> </ul> </li> </ul> </div> </section> <section id="custom-location-webhooks"> <h2>Custom-location Webhooks<a class="headerlink" href="#custom-location-webhooks" title="Link to this heading">¶</a></h2> You can look here for how to do this: <a class="reference internal" href="webhook_hacking.html#webhook-hacking">COPR auto-rebuilds with custom Git repositories</a> </section> <section id="links"> <h2>Links<a class="headerlink" href="#links" title="Link to this heading">¶</a></h2> <ul class="simple"> <li>For building package from git:</li> </ul> <ol class="arabic simple"> <li><a class="reference external" href="https://github.com/dgoodwin/tito">Tito</a> (<a class="reference external" href="http://miroslav.suchy.cz/blog/archives/2013/12/29/how_to_build_in_copr/index.html">blog post</a> and <a class="reference external" href="http://m0dlx.com/blog/Reproducible_builds_on_Copr_with_tito_and_git_annex.html">another about Tito+Git annex</a>)</li> <li><a class="reference external" href="https://github.com/pypingou/dgroc">dgroc</a> (<a class="reference external" href="http://blog.pingoured.fr/index.php?post/2014/03/20/Introducing-dgroc">blog post</a>)</li> </ol> <ul class="simple"> <li><a class="reference external" href="https://wiki.jenkins-ci.org/display/JENKINS/Copr+Plugin">Jenkins plugin</a> (<a class="reference external" href="http://michal-srb.blogspot.cz/2014/04/jenkins-plugin-for-building-rpms-in-copr.html">blog post</a>)</li> </ul> </section> <section id="multilib"> <h2>Multilib<a class="headerlink" href="#multilib" title="Link to this heading">¶</a></h2> 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. <code class="docutils literal notranslate">fedora-31-x86_64</code> and <code class="docutils literal notranslate">fedora-31-i386</code>) 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: <div class="highlight-default notranslate"><div class="highlight"><pre>copr create --multilib=on [other options] </pre></div> </div> or by checkbox on <code class="docutils literal notranslate">Project -> Settings</code> 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, <code class="docutils literal notranslate">dnf copr enable <owner>/<project></code> 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: <div class="highlight-default notranslate"><div class="highlight"><pre>$ 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 </pre></div> </div> </section> <section id="advanced-searching"> <h2>Advanced searching<a class="headerlink" href="#advanced-searching" title="Link to this heading">¶</a></h2> There is a large search box on the Copr homepage and a small search box at the top of every subpage. Both behave in the exact same way, so use which one you prefer. Input formats: <ul class="simple"> <li>A number - If the searched value is a valid build ID, the page is redirected to the build detail page. Otherwise, a fulltext search is performed.</li> <li>A string starting with <code class="docutils literal notranslate">@</code> (e.g. <code class="docutils literal notranslate">@copr</code>) - A fulltext search for a group name is performed. For example, searching <code class="docutils literal notranslate">@co</code> finds all <code class="docutils literal notranslate">@copr</code>, <code class="docutils literal notranslate">@CoreOS</code>, <code class="docutils literal notranslate">@cockpit</code>, etc, and all of their projects.</li> <li>A string without any formatting - Performs a fulltext search for user names, project names, summaries, descriptions, etc.</li> <li>A string containing a forward slash (e.g. <code class="docutils literal notranslate">frostyx/foo</code> or <code class="docutils literal notranslate">@copr/@copr</code>) - A fulltext is performed for the both owner name and the project name. For example, by searching <code class="docutils literal notranslate">@co/co</code> a <code class="docutils literal notranslate">@copr/copr-dev</code> can be found.</li> </ul> Additionally, a part of the search box is a dropdown menu (a button with a caret symbol) with more searching options: <ul class="simple"> <li>A fulltext search limited to the user name</li> <li>A fulltext search limited to the group name (this option is equal to searching a string that starts with <code class="docutils literal notranslate">@</code>)</li> <li>A fulltext search limited to the project name</li> <li>A fulltext search for package names within projects</li> </ul> </section> <section id="status-badges"> <h2>Status Badges<a class="headerlink" href="#status-badges" title="Link to this heading">¶</a></h2> Do you want to add such badge: <img alt="https://copr.fedorainfracloud.org/coprs/g/mock/mock/package/mock/status_image/last_build.png" src="https://copr.fedorainfracloud.org/coprs/g/mock/mock/package/mock/status_image/last_build.png" /> to your page? E.g. to GitHub README.md? You can use those urls: <ul class="simple"> <li><cite>https://copr.fedorainfracloud.org/coprs/<username>/<coprname>/package/<package_name>/status_image/last_build.png</cite></li> <li><cite>https://copr.fedorainfracloud.org/coprs/g/<group_name>/<coprname>/package/<package_name>/status_image/last_build.png</cite></li> </ul> And this badge will reflect current status of your package. </section> <section id="mass-rebuilds"> <h2>Mass rebuilds<a class="headerlink" href="#mass-rebuilds" title="Link to this heading">¶</a></h2> 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: <ul class="simple"> <li>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 <a class="reference internal" href="index.html#communication">communication channels</a></li> <li>Creating AppStream metadata is too slow for large repositories, you might want to disable it. Go to your project settings and turn off the “Generate AppStream metadata” option, or specify <code class="docutils literal notranslate">--appstream=off</code> when creating or modifying a project in <code class="docutils literal notranslate">copr-cli</code>.</li> <li>When submitting builds, please use <code class="docutils literal notranslate">--background</code> parameter to make them deprioritized by scheduler (compared to normal builds). It’s a nice gesture to other users.</li> <li>If possible, don’t submit all builds at once but rather 1k-5k at the time and wait for Copr to process them</li> <li>Use <a class="reference internal" href="#build-batches">Build batches</a> 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</li> <li>Use <a class="reference external" href="https://python-copr.readthedocs.io/en/latest/client_v3/pagination.html">pagination</a> when accessing the project packages and builds through API</li> </ul> You may consider using an already existing mass-rebuild tool, such as <a class="reference external" href="https://gitlab.com/fedora/packager-tools/mass-prebuild">mass-prebuild</a>, <a class="reference external" href="https://github.com/hroncok/mini-mass-rebuild">mini-mass-rebuild</a>, <a class="reference external" href="https://pagure.io/copr-autorebuilder">copr-autorebuilder</a>, or <a class="reference external" href="https://github.com/fedora-copr/copr-rebuild-tools">copr-rebuild-tools</a>. </section> <section id="build-batches"> <h2>Build batches<a class="headerlink" href="#build-batches" title="Link to this heading">¶</a></h2> 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: <div class="highlight-default notranslate"><div class="highlight"><pre>$ 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 </pre></div> </div> 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 <cite>blog post <https://pavel.raiskup.cz/blog/build-ordering-by-batches-in-copr.html></cite> which goes a little bit more into detail. </section> <section id="automatic-run-of-fedora-review-tool"> <h2>Automatic run of Fedora Review tool<a class="headerlink" href="#automatic-run-of-fedora-review-tool" title="Link to this heading">¶</a></h2> There’s a new per-project config option (e.g. <code class="docutils literal notranslate">copr create --fedora-review</code>) that triggers an automatic run of <a class="reference external" href="https://pagure.io/FedoraReview">Fedora Review</a> after each build in such project, for now only in the <code class="docutils literal notranslate">fedora-*</code> chroots. 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 <code class="docutils literal notranslate">review.txt</code> file that is created in build results. Quick HOWTO for the <a class="reference external" href="https://fedoraproject.org/wiki/Package_Review_Process">Package Review</a> time: <div class="highlight-default notranslate"><div class="highlight"><pre>$ 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! </pre></div> </div> </section> <section id="rpm-macros"> <h2>RPM Macros<a class="headerlink" href="#rpm-macros" title="Link to this heading">¶</a></h2> Copr defines custom RPM macros that are available for every build and can be used inside of a specfile. Please note that these macros are not available in other build systems, so you should use them as e.g. <code class="docutils literal notranslate">%?copr_username</code> instead of <code class="docutils literal notranslate">%copr_username</code>. <ul> <li><code class="docutils literal notranslate">%copr_username</code> - Owner of the project, can be either a user or group name, e.g. <code class="docutils literal notranslate">@copr</code></li> <li><code class="docutils literal notranslate">%copr_projectname</code> - Name of the project, e.g. <code class="docutils literal notranslate">copr-dev</code></li> <li><code class="docutils literal notranslate">%vendor</code> - This macro identifies the software maintainer of the distributed packages, for example: <blockquote> <div><ul class="simple"> <li><code class="docutils literal notranslate">Fedora Copr - user frostyx</code></li> <li><code class="docutils literal notranslate">Fedora Copr - group @copr</code></li> <li>Users can run <code class="docutils literal notranslate">rpm -qi <package-name> | grep -i vendor</code> to identify vendor of their installed packages</li> </ul> </div></blockquote> </li> <li><code class="docutils literal notranslate">%buildtag</code> - This macro contains an ID of a Copr build, e.g. <code class="docutils literal notranslate">.copr5925897</code></li> </ul> Macros for SRPM builds: <ul class="simple"> <li><code class="docutils literal notranslate">%dist</code> - Copr <a class="reference external" href="https://github.com/fedora-copr/copr/commit/2344ea3136f65b9ed04e0bff4b7b26ba06c6fcb1">undefines %dist for SRPM builds</a> to be distro-agnostic</li> <li><code class="docutils literal notranslate">%_disable_source_fetch</code> - We set this macro to <code class="docutils literal notranslate">0</code>. As a consequence, it is possible to submit a build from a specfile with a fully qualified <code class="docutils literal notranslate">SourceX</code> URL and allow the sources to be automatically downloaded.</li> </ul> Users are often interested in having parts of their spec file that are evaluated only in Copr and ignored by Koji. It is easy to do: <div class="highlight-default notranslate"><div class="highlight"><pre>%if 0%{?copr_projectname:1} # This happens only in Copr %endif </pre></div> </div> </section> <section id="creating-repositories-manually"> <h2>Creating repositories manually<a class="headerlink" href="#creating-repositories-manually" title="Link to this heading">¶</a></h2> After a build is finished, Copr automatically adds its results to the project RPM repository. When maintaining a large software stack consisting of hundreds of packages (e.g. KDE or Gnome), it may be useful to disable this feature and create repositories manually. That way you can atomically move your repository from one consistent state to another. In such case, after a build is finished, Copr adds the results only to an internal <code class="docutils literal notranslate">devel/repodata</code> repository. It’s results are not available to users but the repository is enabled for all subsequent builds in the project. Once you are ready to publish the changes to users, click the “Regenerate Repositories” button in your project overview. Please note that there are some historical inconsistencies in the naming of this feature. There is a “Create repositories manually” checkbox in the project settings, <code class="docutils literal notranslate">copr-cli create --disable_createrepo</code> in CLI, and <code class="docutils literal notranslate">devel_mode</code> in the API. They are all the same feature. </section> <section id="high-performance-builders"> <h2>High Performance Builders<a class="headerlink" href="#high-performance-builders" title="Link to this heading">¶</a></h2> About more powerful builders see <a class="reference internal" href="user_documentation/powerful_builders.html#high-performance-builders">Builders in Fedora Copr are too slow!</a>. </section> <section id="subprojects"> <h2>Subprojects<a class="headerlink" href="#subprojects" title="Link to this heading">¶</a></h2> This feature is also known as “CoprDirs”. Inside a single project, it is possible to create multiple subprojects, subprepositories, or subdirectories, depending on your point of view. Let’s show the feature on an example. First, you need to manually create a project. Then the subprojects are created dynamically when builds are submitted into them: <div class="highlight-default notranslate"><div class="highlight"><pre>copr create test --chroot fedora-rawhide-x86_64 PKG=https://github.com/fedora-copr/copr-test-sources/raw/main/hello-2.8-1.src.rpm copr build test $PKG copr build test:custom:foo $PKG copr build test:custom:bar $PKG </pre></div> </div> This will create a <code class="docutils literal notranslate">test</code> project under my namespace and submit one build directly into the project, one build to the <code class="docutils literal notranslate">test:custom:foo</code> subproject, and one into the <code class="docutils literal notranslate">test:custom:bar</code> subproject. The subproject builds are isolated from each other but they can all see builds from the main <code class="docutils literal notranslate">test</code> project repository. For the time being, the builds in the <code class="docutils literal notranslate">test:custom:foo</code> subproject don’t see other builds from the same subproject. This is not a design choice but rather a missing feature. The subproject name has to start with the project name. It is followed by either <code class="docutils literal notranslate">:custom:</code> or <code class="docutils literal notranslate">:pr:</code> and a suffix. The suffix can be whatever the user wants. A subproject can be enabled on a user system with: <div class="highlight-default notranslate"><div class="highlight"><pre>dnf copr enable frostyx/test:custom:foo </pre></div> </div> </section> <section id="modularity"> <h2>Modularity<a class="headerlink" href="#modularity" title="Link to this heading">¶</a></h2> Copr supports multiple <a class="reference external" href="https://docs.fedoraproject.org/en-US/modularity/">Fedora Modularity</a> features: <ul class="simple"> <li><a class="reference external" href="http://frostyx.cz/posts/how-to-build-modules-in-copr">Building modules</a></li> <li><a class="reference external" href="http://frostyx.cz/posts/module-hotfixes-in-copr">Module hotfixes repositories</a> - allowing non-module packages to override module packages</li> <li>Enabling/disabling modules in the packages buildroot. Let’s suppose that you need to install a module dependency, e.g. <code class="docutils literal notranslate">dnf module install nodejs:16</code> to build your package. This can be done in Copr by going to a project settings, picking a chroot, clicking its “Edit” button, and specifying the “Modules” field. Please note, that it can also disable modules.</li> </ul> </section> <section id="faq"> <h2>FAQ<a class="headerlink" href="#faq" title="Link to this heading">¶</a></h2> What is the purpose of Copr? <a class="reference internal" href="#what-is-the-purpose-of-copr">¶</a> 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 <a class="reference external" href="https://accounts.fedoraproject.org">FAS account</a> in order to get started. What I can build in Copr? <a class="reference internal" href="#what-i-can-build-in-copr">¶</a> You agree not to use Copr to upload software code or other material (“Material”) that: <ol class="loweralpha simple"> <li>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;</li> <li>is governed in whole or in part by a license not contained in the list of acceptable licenses for Fedora, currently located at <a class="reference external" href="https://docs.fedoraproject.org/en-US/legal/allowed-licenses">https://docs.fedoraproject.org/en-US/legal/allowed-licenses</a>, as that list may be revised from time to time by the Fedora Council;</li> <li>is categorized as a “Not-Allowed Item” at <a class="reference external" href="https://docs.fedoraproject.org/en-US/legal/not-allowed-licenses/">https://docs.fedoraproject.org/en-US/legal/not-allowed-licenses/</a> as that page may be revised from time to time by the Fedora Council;</li> <li>is designed to interfere with, disable, overburden, damage, impair or disrupt Copr or Fedora Project infrastructure;</li> <li>violates any rules or guidelines of the Fedora Project - especially the Fedora Project <a class="reference external" href="https://docs.fedoraproject.org/en-US/project/code-of-conduct/index.html">Code of Conduct</a> You do not need to comply with <a class="reference external" href="https://docs.fedoraproject.org/en-US/packaging-guidelines/">Packaging Guidelines</a>.; or</li> <li>violates any applicable laws and regulations.</li> </ol> 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 <a class="reference external" href="https://docs.fedoraproject.org/en-US/packaging-guidelines/">Fedora Packaging Guidelines</a>, 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. Can you lend me faster Copr builders? <a class="reference internal" href="#faq-high-performance-builders">¶</a> Yes, glad you asking! But you don’t always want this, see — <a class="reference internal" href="user_documentation/powerful_builders.html#high-performance-builders">Builders in Fedora Copr are too slow!</a>. Is it safe to use Copr? <a class="reference internal" href="#is-it-safe-to-use-copr">¶</a> 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? <a class="reference internal" href="#how-can-i-enable-a-copr-repository">¶</a> See <a class="reference internal" href="how_to_enable_repo.html#how-to-enable-repo">How to enable repo</a>. How can I package software as RPM? <a class="reference internal" href="#how-can-i-package-software-as-rpm">¶</a> There are several tutorials: <ul class="simple"> <li><a class="reference external" href="https://rpm-packaging-guide.github.io/">RPM Packaging Guide</a></li> <li><a class="reference external" href="http://youtu.be/H4vxkuoimzc">Packaging Workshop (video)</a> <a class="reference external" href="https://youtu.be/KdIsoYGSNS8">(and the same workshop from different conference)</a></li> <li><a class="reference external" href="https://fedoraproject.org/wiki/How_to_create_an_RPM_package">How to create an RPM package</a></li> <li><a class="reference external" href="http://documentation-devel.engineering.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Packagers_Guide/chap-Red_Hat_Enterprise_Linux-Packagers_Guide-Creating_and_Building_Packages.html">Creating and Building Packages</a></li> <li><a class="reference external" href="http://youtu.be/4J_Iksu1fgo">How To Make An RPM With Red Hat Package Manager (video)</a></li> <li><a class="reference external" href="http://www.rpm.org/max-rpm/">http://www.rpm.org/max-rpm/</a></li> <li><a class="reference external" href="https://access.redhat.com/videos/214983">Getting Started with RPMs (RH subscribers only)</a></li> <li><a class="reference external" href="https://youtu.be/vdWnyIbN8uw">Advanced packaging workshop (video)</a></li> </ul> Can I build for different versions of Fedora? <a class="reference internal" href="#can-i-build-for-different-versions-of-fedora">¶</a> 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? <a class="reference internal" href="#can-i-have-more-yum-repositories">¶</a> 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? <a class="reference internal" href="#can-i-submit-multiple-builds-at-once">¶</a> 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? <a class="reference internal" href="#what-happens-when-i-try-to-build-a-package-with-the-same-version-number">¶</a> Nothing special. Your package will just be rebuilt again. Can I depend on other packages, which are not in Fedora/EPEL? <a class="reference internal" href="#can-i-depend-on-other-packages-which-are-not-in-fedora-epel">¶</a> 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? <a class="reference internal" href="#can-i-give-access-to-my-repo-to-my-team-mate">¶</a> 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? <a class="reference internal" href="#do-you-have-a-command-line-client">¶</a> Yes. Just do <code class="docutils literal notranslate">dnf install copr-cli</code> and learn more by <code class="docutils literal notranslate">man copr-cli</code>. Do you have an API? <a class="reference internal" href="#do-you-have-an-api">¶</a> Yes. See the link in the footer of every Copr page or jump directly to the <a class="reference external" href="https://copr.fedorainfracloud.org/api/">API page</a>. How long do you keep the builds? <a class="reference internal" href="#how-long-do-you-keep-the-builds">¶</a> 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. Projects that opted-in for <a class="reference internal" href="#creating-repositories-manually">Creating repositories manually</a>, are exempt from the old package removal because of technical limitations. How is Copr pronounced? <a class="reference internal" href="#how-is-copr-pronounced">¶</a> In American English Copr is pronounced /ˈkɑ.pɚ/ like the metallic element spelled “copper”. Why another buildsystem? <a class="reference internal" href="#why-another-buildsystem">¶</a> 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? <a class="reference internal" href="#did-you-consider-obs">¶</a> Yes, we did. See <a class="reference external" href="http://miroslav.suchy.cz/blog/archives/2013/08/29/copr_and_integration_with_koji/index.html">Copr and integration with Koji</a> and <a class="reference external" href="http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs/index.html">Copr Implemented using OBS</a>. And the <a class="reference external" href="https://lists.fedoraproject.org/pipermail/devel/2013-August/188575.html">mailing list discussion</a>, as well as the <a class="reference external" href="https://lists.fedoraproject.org/pipermail/devel/2013-September/188751.html">conclusion</a>. Can I get notifications from Copr builds? <a class="reference internal" href="#can-i-get-notifications-from-copr-builds">¶</a> Yes, you can. Enable email/irc/android notifications at <a class="reference external" href="https://apps.fedoraproject.org/notifications/">Fedora notifications service</a>. See blog post <a class="reference external" href="https://pavel.raiskup.cz/blog/copr-messsaging.html">how to consume copr messages from bus</a>. What does Copr mean? <a class="reference internal" href="#what-does-copr-mean">¶</a> Community projects (formerly Cool Other Package Repositories) How can I tell yum to prefer Copr packages? <a class="reference internal" href="#how-can-i-tell-yum-to-prefer-copr-packages">¶</a> 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? <a class="reference internal" href="#can-copr-build-directly-from-git">¶</a> Yes, it can. See <a class="reference internal" href="#scm-ref">SCM</a> source type. If you want to know more about tools to generate srpm from a Git repo, see: <ol class="arabic simple"> <li><a class="reference external" href="https://github.com/dgoodwin/tito">Tito</a> (<a class="reference external" href="http://miroslav.suchy.cz/blog/archives/2013/12/29/how_to_build_in_copr/index.html">blog post</a>)</li> <li><a class="reference external" href="https://github.com/pypingou/dgroc">dgroc</a> (<a class="reference external" href="http://blog.pingoured.fr/index.php?post/2014/03/20/Introducing-dgroc">blog post</a>)</li> </ol> Why doesn’t Copr download my updated package? <a class="reference internal" href="#why-doesn-t-copr-download-my-updated-package">¶</a> 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? <a class="reference internal" href="#how-can-i-create-new-group">¶</a> Groups membership is handled by <a class="reference external" href="https://accounts.fedoraproject.org">FAS</a>. It can add/remove members to existing group. However it cannot create new group. You can create new group by <a class="reference external" href="https://pagure.io/fedora-infrastructure/new_issue">creating new fedora-infra ticket</a>. You have to log out and then log in again to Copr so Copr can read your new settings. Note also that you might need to wait a few minutes till the <a class="reference external" href="https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/ipsilon/#_known_issues">group list gets synchronized</a>. Users also reported that <a class="reference external" href="https://id.fedoraproject.org/logout">logging-out first from Ipsilon</a> might help with synchronization. Once copr knows the FAS groups you belong to, you still need to activate the group. Go to <a class="reference external" href="https://copr.fedorainfracloud.org/groups/list/my">my groups</a> page and click on the <code class="docutils literal notranslate">Activate this group</code> button. I see some strange error about /devel/repodata/ in logs. <a class="reference internal" href="#i-see-some-strange-error-about-devel-repodata-in-logs">¶</a> 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 <code class="docutils literal notranslate">skip_if_unavailable=1</code>. 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? <a class="reference internal" href="#how-can-i-affect-the-build-order-is-there-a-chain-build-support">¶</a> 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 <a class="reference external" href="https://pavel.raiskup.cz/blog/build-ordering-by-batches-in-copr.html">blog post</a> with examples for more info. Build succeeded, but I don’t see the built results? <a class="reference internal" href="#build-succeeded-but-i-don-t-see-the-built-results">¶</a> 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 <a class="reference external" href="http://copr-be.cloud.fedoraproject.org/results/">non-cached host variant</a>. My build failed because of a timeout, why? <a class="reference internal" href="#faq-build-timeout">¶</a> Builds are not allowed to run forever. The default limit is 5 hours (18000 seconds) but users can increase it up to 30 hours (108000 seconds). <div class="admonition-deployment-specific admonition"> Deployment specific The <a class="reference external" href="https://copr.fedorainfracloud.org/">Fedora Copr</a> instance increases the maximum limit to 50 hours (180000 seconds). </div> If the timeout limit is exceeded, the build will be killed with the following error message: <div class="highlight-default notranslate"><div class="highlight"><pre>!! Copr timeout => sending INT Copr build error: Build failed Shared connection to builder closed. </pre></div> </div> Weird SCM build failure? <a class="reference internal" href="#weird-scm-build-failure">¶</a> It worked for me before, but I newly see the <code class="docutils literal notranslate">rpkg</code> errors like: <div class="highlight-default notranslate"><div class="highlight"><pre>Running: rpkg srpm --outdir /var/lib/copr-rpmbuild/results ... Copr build error: error: Bad source: /var/lib/copr-rpmbuild/results/example-1.0.13.tar.gz: No such file or directory </pre></div> </div> Please take a look at <a class="reference internal" href="rpkg_util_2_vs_3.html#rpkg-util-v3">The rpkg-util v2 vs v3 differences</a>. What is difference between Koji vs. Copr? <a class="reference internal" href="#what-is-difference-between-koji-vs-copr">¶</a> See separate page <a class="reference internal" href="koji_vs_copr.html#koji-vs-copr">Koji vs. Copr</a>. How to deal with Copr and RPMAutoSpec? <a class="reference internal" href="#faq-autospec">¶</a> The easiest way is to use <a class="reference internal" href="#dist-git-method">DistGit source type</a>. It automatically expands <code class="docutils literal notranslate">%autorelease</code> and <code class="docutils literal notranslate">%autochangelog</code> from the cloned dist-git repository. If you need to fine tune the process and alter it somehow you can - Set the source type to “Custom”, and use the following script: <div class="highlight-default notranslate"><div class="highlight"><pre>#! /bin/sh -x package=<package> copr-distgit-client clone "$package" --dist-git fedora cd "$package" || exit 1 .. tweak the spec file or checkout the desired branch .. copr-distgit-client sources # download sources copr-distgit-client srpm --outputdir . bsdtar xf *.src.rpm -C "$COPR_RESULTDIR" </pre></div> </div> Set the Buildroot dependencies to <code class="docutils literal notranslate">copr-distgit-client bsdtar</code>. Alternatively you can go even deeper and use <code class="docutils literal notranslate">git rpmdevtools rpmautospec</code> deps with: <div class="highlight-default notranslate"><div class="highlight"><pre>git clone <git url> <project name> cd <project name> spectool -g <spec file> rpmautospec process-distgit <spec file> <spec file> </pre></div> </div> In this case specify the result directory to the same <code class="docutils literal notranslate"><project name></code> string used in the script. I have a problem and I need to talk to a human. <a class="reference internal" href="#i-have-a-problem-and-i-need-to-talk-to-a-human">¶</a> We do not provide support per se, but try your luck here: <a class="reference internal" href="index.html#communication">Communication</a> </section> </section> </div> </div> <footer><div class="rst-footer-buttons" role="navigation" aria-label="Footer"> <a href="index.html" class="btn btn-neutral float-left" title="Copr Buildsystem" accesskey="p" rel="prev"> Previous</a> <a href="user_documentation/pagure_integration.html" class="btn btn-neutral float-right" title="Pagure Integration" accesskey="n" rel="next">Next </a> </div> <hr/> <div role="contentinfo"> © Copyright . </div> Built with <a href="https://www.sphinx-doc.org/">Sphinx</a> using a <a href="https://github.com/readthedocs/sphinx_rtd_theme">theme</a> provided by <a href="https://readthedocs.org">Read the Docs</a>. </footer> </div> </div> </section> </div> <script> jQuery(function () { SphinxRtdTheme.Navigation.enable(true); }); </script> </body> </html>