COPR-CLI(1)

πŸ“¦
version 2.7 Β· 6 versions
, in epel 10, fedora 43, fedora 44

πŸ’– COPR-CLI(1) β€” the Copr command line interface, bestie edition πŸ’–

manual: COPR Β· section 1


✨ NAME ✨

copr-cli β€” command line interface for the Copr service πŸŽ€


🌸 SYNOPSIS 🌸

copr-cli [-h] [--version] [--config CONFIG] {list,create,build} ...

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so this command is literally your little backstage pass to the Copr service, right from the terminal πŸ’… You can poke at it, build stuff with it, all of it.

But fr fr, you gotta set up authentication first before any of this works β€” the AUTHENTICATION section down below has the tea β˜• (it's not in this part, so hold that thought, bestie 🫢).


⭐ OPTIONS ⭐

  • -h, --help β€” shows this help message and dips out. iconic behaviour.
  • --version β€” prints the program's version number and exits. quick lil flex πŸ’β™€οΈ
  • --config β€” path to an alternative configuration file. the default is ~/.config/copr, so if yours lives somewhere else, this is how you tell it 🌈

πŸ‘‘ ACTION LIST πŸ‘‘

  • list [username|@groupname] β€” lists all the projects of the username you hand it. give it nothing and it lists your projects, main character 🫢
  • create β€” makes a brand new project ✨
  • delete β€” nukes an entire project πŸ’€
  • build β€” builds packages for a project you specify
  • status β€” gets the status of the build
  • cancel β€” cancels a build of a given id
  • download-build β€” downloads a build to your local directory
  • modify β€” modifies an existing copr
  • regenerate-repos β€” regenerates repository metadata for a project
  • add-package-* β€” adds a new package of the specified source type (like add-package-tito)
  • edit-package-* β€” edits the source definition and type of an existing package (like edit-package-tito)
  • list-packages β€” lists all packages from a copr, in json format
  • list-package-names β€” outputs just the package names from the given copr, nothing extra
  • get-package β€” shows details of a single package, in json format
  • delete-package β€” removes a package from a copr and all its builds too 😭
  • reset-package β€” clears the source definition of a package and its source type
  • build-package β€” builds a package from its source definition
  • mock-config β€” gets the mock profile (similar to koji mock-config)
  • edit-permissions β€” edits roles/permissions on a copr project
  • list-permissions β€” prints the copr project roles/permissions
  • request-permissions β€” requests (or rejects) your role in the copr project

πŸŽ€ PROJECT ACTIONS πŸŽ€

🧚 copr-cli create [options] 🧚

usage: copr-cli create [-h] --chroot CHROOTS [--repo REPOS]
[--initial-pkgs PKGS] [--description DESCRIPTION] [--instructions
INSTRUCTIONS] [--disable_createrepo DISABLE_CREATEREPO] [--enable-net
{on,off}] [--unlisted-on-hp {on,off}] [--persistent] [--auto-prune
{on,off}] [--isolation {default, nspawn, simple}] name
  • --chroot β€” chroot to use for this project. you can pass it multiple times, but at least one has to be there β€” no chroot, no project, periodt πŸ’…
  • --repo β€” repository to add to this project. can be specified multiple times.
  • --initial-pkgs β€” list of packages to build in this new project. can be specified multiple times.
  • --description β€” description of the project.
  • --instructions β€” instructions for the project.
  • --disable_createrepo β€” disables automatic repository metadata generation. accepted values for DISABLE_CREATEREPO: true/false.
  • --enable-net β€” whether net should be enabled for builds in this project.
  • --unlisted-on-hp β€” this project will not be listed on the COPR home page πŸ™ˆ
  • --persistent β€” project and its builds will be undeletable. this option can only be specified by a COPR admin πŸ‘‘
  • --auto-prune β€” whether the backend auto-prunning script should be run for this project. this option can only be specified by a COPR admin πŸ‘‘
  • --isolation ISOLATION β€” choose the isolation method for running commands in buildroot
  • name β€” can be just the name of the project, or in the form username/projectname or @groupname/projectname.

πŸ’œ copr-cli modify [options] πŸ’œ

usage: copr-cli modify [-h] [--repo REPOS] [--chroot CHROOTS]
[--description DESCRIPTION] [--instructions INSTRUCTIONS]
[--disable_createrepo DISABLE_CREATEREPO] [--enable-net {on,off}]
[--unlisted-on-hp {on,off}] [--auto-prune {on,off}] [--isolation
{default, nspawn, simple}] name

alters only the specified project property. just the one. don't come for the rest of them 🫢

  • --repo β€” repository to add to this project. can be specified multiple times.
  • --chroot β€” chroot to use for this project. can be specified multiple times. when this option is not used, chroots in the project remain unchanged. once you specify a chroot, it's going to be enabled in the project, but current chroots will not be preserved if they are not specified 😭 so like, be careful with this one, bestie.
  • --description β€” description of the project.
  • --instructions β€” instructions for the project.
  • --disable_createrepo β€” disables automatic repository metadata generation. accepted values for DISABLE_CREATEREPO: true/false.
  • --enable-net β€” whether networking should be enabled for builds in this project.
  • --unlisted-on-hp β€” this project will not be listed on the COPR home page πŸ™ˆ
  • --auto-prune β€” whether the backend auto-prunning script should be run for this project. this option can only be specified by a COPR admin πŸ‘‘
  • --isolation ISOLATION β€” choose the isolation method for running commands in buildroot
  • name β€” can be just the name of the project, or in the form username/projectname or @groupname/projectname.

🌈 copr-cli regenerate-repos [options] 🌈

usage: copr-cli regenerate-repos [-h] copr
  • copr β€” can be just the name of the project, or in the form username/projectname or @groupname/projectname.

πŸ’– ok that's part 1, we're just getting started β€” more is coming, don't go anywhere ✨

πŸ”¨ BUILD ACTIONS πŸ”¨


🌸 copr-cli build [options]

okay bestie, this is THE one, the main character of the whole page ✨

usage: copr-cli build [-h] [-r, --chroot CHROOTS] [--memory MEMORY]
[--timeout TIMEOUT] [--nowait] [--background] [--isolation {default,
nspawn, simple}] [--enable-net {on,off}] copr_repo PKG [PKG ...]
  • -r, --chroot β€” use this when you don't want the build for every single chroot in the project. Stack it up as many times as you need chroots, one per chroot. Glob patterns work here, so go wild πŸ’…
  • --exclude-chroot β€” the reverse vibe: when you don't want the build in certain chroots of the project. Repeat it for each chroot you're skipping. Also supports glob patterns ✨
  • --memory β€” override the memory for this build. ngl, this one is literally not used and has no effect. it's giving decorative πŸŽ€
  • --timeout β€” set the build timeout in seconds. if the build runs longer than that, it gets terminated and fails. the default is usually set to 5 hours on Copr Frontend.
  • --nowait β€” don't wait around for the build to finish. go live your life πŸ’…
  • --background β€” run the build at a lower priority.
  • --isolation ISOLATION β€” pick the isolation method for running commands in the buildroot.
  • --enable-net β€” whether networking should be enabled for this build.
  • copr_repo β€” the copr repository where the package gets built. it can be:
    • just the simple name of one of your projects, or
    • the fully specified username/project, or
    • @groupname/project

this way you can build into another user's or group's project, as long as you have the permissions for it πŸ‘‘ and finally β€” instead of just the project name, you can also pass project:tag. in that case the build lands in the project side repository instead of the main repository. the side repository named project:tag gets automatically created if it doesn't exist yet. like, you can use this feature to launch test builds while the main user-facing repository stays perfectly intact ✨ you can specify any tag that's appropriate for the given build(s).

  • PKG β€” this is either a file on your local workstation or a URL of the package to build. when it's a URL, the package has to live on a public web or ftp server. and heads up: you cannot combine local file paths and URLs in one command line, and local-file builds are limited to the first specified PKG. this limitation comes from the COPR API, so don't shoot the messenger 🫢

πŸŽ€ copr-cli uploadrpm [options]

usage: copr-cli uploadrpm [-h] [-r, --chroot CHROOTS] [--memory MEMORY]
[--timeout TIMEOUT] [--nowait] [--background] [--name NAME] [--version
VERSION] [--release RELEASE] [--epoch EPOCH] copr_repo TARBALL

publish a pre-built RPM upload tarball directly to a project, skipping the SRPM build phase entirely. so fast, so efficient, we love her πŸ’–

for the arguments, see the copr-cli build command above. πŸ‘†

  • TARBALL β€” local path to a .tar.gz file containing the RPM upload payload. the archive must contain exactly one top-level directory with payload files directly inside it (no nested subdirectories, bestie, don't try it).

Required contents πŸ“

  • at least one binary RPM (*.rpm, excluding *.src.rpm and *.nosrc.rpm)

Optional contents 🌸

  • up to one SRPM (*.src.rpm or *.nosrc.rpm)
  • arbitrary additional files (e.g. build logs, README.txt, LICENSE.txt); these are archived into uploaded-logs.tar.gz in the build results
  • sha256.json β€” a JSON object mapping file basenames to SHA256 hex digests; when present, every listed file is verified during the build

Example ✨

upload.tar.gz
└── upload/
    β”œβ”€β”€ package-1.0-1.fc40.x86_64.rpm
    β”œβ”€β”€ package-1.0-1.fc40.src.rpm
    β”œβ”€β”€ build.log
    └── sha256.json

binary RPM architectures must match the target chroot (or be noarch). and listen β€” package name, version, release, and optional epoch are provided via the options below and are not taken from the RPM headers. iykyk πŸ‘‘

  • --name NAME β€” package name.
  • --version VERSION β€” package version.
  • --release RELEASE β€” package release.
  • --epoch EPOCH β€” optional package epoch.

🐍 copr-cli buildpypi [options]

usage: copr buildpypi [-h] [-r, --chroot CHROOTS] [--memory MEMORY]
[--timeout TIMEOUT] [--nowait] [--background] [--with-deps]
[--pythonversions [VERSION [VERSION ...]]] [--packageversion
PYPIVERSION] --packagename PYPINAME project
  • --pythonversions [VERSION [VERSION ...]] β€” which Python versions to build for (by default: 3 2)
  • --packageversion PYPIVERSION β€” the version of the PyPI package to be built (by default the latest)
  • --packagename PYPINAME β€” the name of the PyPI package to be built. required, no skipping it πŸ’…
  • --with-deps β€” also build the dependencies of the package. the dependency tree is resolved by the coprtree library. this requires the python3-coprtree package to be installed. please report bugs in the dependency resolution to https://github.com/sundaram123krishnan/coprtree

for the rest of the arguments, see the copr-cli build command above. πŸ‘†


πŸ¦‹ copr-cli buildscm [options]

usage: copr buildscm [-h] --clone-url CLONE_URL [--commit COMMITTISH]
[--subdir SUBDIRECTORY] [--spec SPEC] [--type {git,svn}] [--method
{rpkg,tito,tito_test,make_srpm}] [--memory MEMORY] [--timeout TIMEOUT]
[--nowait] [-r CHROOTS] [--background] copr_repo

build a package straight from a Git/DistGit/SVN repository 🌈

  • --clone-url CLONE_URL β€” clone url to a project versioned by Git or SVN. required.
  • --commit COMMITTISH β€” branch name, tag name, or git hash to be built
  • --subdir SUBDIRECTORY β€” relative path from the repo root to the package content
  • --spec SPEC β€” relative path from the subdirectory to the .spec file
  • --type TYPE β€” specify the versioning tool. default is git.
  • --method METHOD β€” Srpm build method. default is rpkg.

for the rest of the arguments, see the copr-cli build command above. πŸ‘†


πŸ’œ copr-cli download-build [options]

usage: copr-cli download-build [-h] [-d, --dest DESTINATION] [-r,
--chroot CHROOT] build_id
  • build_id β€” download the built packages for the build identified by build_id.
  • -d, --dest β€” base directory to store the packages
  • -r, --chroot β€” fetch only selected chroots. can be specified multiple times πŸ’…

πŸ’€ copr-cli delete-build [options]

usage: copr delete-build [-h] build_id [build_id ...]
  • build_id β€” ID of the build to be deleted. can be specified multiple times. and listen bestie: specifying multiple build_id is much faster than calling copr delete-build multiple times, because in the first case createrepo is called only once. efficiency queen πŸ‘‘

✨ EXAMPLES ✨

copr-cli build myproject some.src.rpm
copr-cli build someone_else/project some.src.rpm
copr-cli build -r fedora-24-x86_64 -r fedora-24-i386 "@somegroup/project" some.src.rpm

🧚 CHROOT ACTIONS 🧚

πŸŽ€ copr-cli edit-chroot [options] coprchroot

usage: copr edit-chroot [-h] [--upload-comps FILEPATH | --delete-comps]
[--packages PACKAGES] [--repos REPOS] [--isolation {default, nspawn,
simple}] coprchroot

edit the specified coprchroot. tiny little surgery, so satisfying ✨

  • coprchroot β€” path to a project chroot as owner/project/chroot or project/chroot
  • --upload-comps FILEPATH β€” filepath to the comps.xml file to be uploaded
  • --delete-comps β€” deletes the already existing comps.xml for the chroot
  • --packages PACKAGES β€” space separated string of package names to be added to buildroot (e.g. "gcc ghc")
  • --repos REPOS β€” space separated string of additional repo urls for the chroot (e.g. "http://foo http://bar")
  • --isolation ISOLATION β€” choose the isolation method for running commands in buildroot

🌸 copr-cli get-chroot coprchroot

usage: copr get-chroot [-h] coprchroot [--output-format {json, text,
text-row}]

print info of the given chroot 🫢

  • coprchroot β€” path to a project chroot as owner/project/chroot or project/chroot
  • --output-format FORMAT β€” set the formatting style. we recommend using json, which prints the required data in json format. the text format prints the required data in a column, one piece of information per line. the text-row format prints all information separated by a space on a single line.

πŸ‘‘ PERMISSION ACTIONS πŸ‘‘

πŸ’… copr-cli edit-permissions [options]

usage: copr-cli edit-permissions [-h] [--admin USERNAME[=VALUE]]
[--builder USERNAME[=VALUE]] PROJECT

edit the roles/permissions on a copr project. main character energy only πŸ‘‘

  • PROJECT β€” an existing copr project.
  • --admin USERNAME[=VALUE] β€” set the admin role for USERNAME in PROJECT. VALUE can be one of approved|request|nothing (default=approved).
  • --builder USERNAME[=VALUE] β€” set the builder role for USERNAME in PROJECT. VALUE can be one of approved|request|nothing (default=approved).

🌈 copr-cli list-permissions [options]

usage: copr-cli list-permissions [-h] PROJECT

print the copr project roles/permissions. just a lil peek, no drama πŸ’–

  • PROJECT β€” an existing copr project.

πŸ¦‹ copr-cli request-permissions [options]

usage: copr-cli request-permissions [-h] [--admin [VALUE]] [--builder
[VALUE]] PROJECT

request (or reject) your role in the copr project. shoot your shot bestie ✨

  • PROJECT β€” an existing copr project.
  • --admin [VALUE] β€” request / cancel request / remove your admin permissions in PROJECT. VALUE can be one of request|nothing (default=request).
  • --builder [VALUE] β€” request / cancel request / remove your builder permissions in PROJECT. VALUE can be one of request|nothing (default=request).

πŸ“¦ PACKAGE ACTIONS πŸ“¦

okay bestie, this is the good part β€” everything about the actual packages living inside your project. pack it up, we're going in πŸ’–


copr-cli add-package-pypi [options]

usage: copr add-package-pypi [-h] [--pythonversions [VERSION [VERSION
...]]] [--packageversion PYPIVERSION] --packagename PYPINAME --name
PKGNAME [--webhook-rebuild {on,off}] [--chroot-denylist CHROOT_DENYLIST]
project

Adds a package of PyPI source type. yes, straight from the cheese shop πŸ§€βœ¨

  • --pythonversions [VERSION [VERSION ...]] β€” which Python versions we're building for. default is literally 3 2.
  • --packageversion PYPIVERSION β€” the version of the PyPI package to be built. default is the latest one, as it should be πŸ’…
  • --packagename PYPINAME β€” the name of the PyPI package to be built. required, no skipping it.
  • --name PKGNAME β€” the name of the package to be edited or created.
  • --webhook-rebuild {on,off} β€” turns on auto-rebuilding.
  • --chroot-denylist CHROOT_DENYLIST β€” comma-separated list of wildcard patterns of chroots to exclude from builds, e.g. fedora-,epel--i386.

copr-cli edit-package-pypi [options]

usage: copr edit-package-pypi [-h] [--pythonversions [VERSION [VERSION
...]]] [--packageversion PYPIVERSION] --packagename PYPINAME --name
PKGNAME [--webhook-rebuild {on,off}] [--chroot-denylist CHROOT_DENYLIST]
project

Edits the source definition and the type of a package that already exists. the options? shared with add-package-pypi, so scroll up bestie, nothing new down here 🫢


copr-cli add-package-scm [options]

usage: copr add-package-scm [-h] --clone-url CLONE_URL [--commit COMMITTISH]
                            [--subdir SUBDIRECTORY] [--spec SPEC]
                            [--type {git,svn}]
                            [--method {rpkg,tito,tito_test,make_srpm}] --name
                            PKGNAME [--webhook-rebuild {on,off}]
                            [--chroot-denylist CHROOT_DENYLIST]
                            copr

Adds a package of SCM source type β€” that's source control management, git girlies rise 🌈

  • --clone-url CLONE_URL β€” clone url to a project versioned by Git or SVN. required.
  • --commit COMMITTISH β€” branch name, tag name, or git hash to be built.
  • --subdir SUBDIRECTORY β€” relative path from the repo root to the package content.
  • --spec SPEC β€” relative path from the subdirectory to the .spec file.
  • --type TYPE β€” specify the versioning tool. default is 'git'.
  • --method METHOD β€” srpm build method. default is 'rpkg'.
  • --name PKGNAME β€” name of the package to be edited or created.
  • --webhook-rebuild {on,off} β€” enable auto-rebuilding.
  • --chroot-denylist CHROOT_DENYLIST β€” comma-separated list of wildcard patterns of chroots to exclude from builds, e.g. 'fedora-*,epel-*-i386'.

copr-cli edit-package-scm [options]

usage: copr edit-package-scm [-h] --clone-url CLONE_URL [--commit
COMMITTISH] [--subdir SUBDIRECTORY] [--spec SPEC] [--type {git,svn}]
[--method {rpkg,tito,tito_test,make_srpm}] --name PKGNAME
[--webhook-rebuild {on,off}] [--chroot-denylist CHROOT_DENYLIST] copr

Edits a package of SCM source type. same energy, new settings πŸ’…


copr-cli add-package-rubygems [options]

usage: copr add-package-rubygems [-h] [--gem GEM] --name PKGNAME
[--webhook-rebuild {on,off}] [--chroot-denylist CHROOT_DENYLIST] project

Adds a package of RubyGems source type. for the ruby besties, obviously πŸ’Ž

  • --gem GEM β€” specify the gem name.
  • --name PKGNAME β€” name of the package to be edited or created.
  • --webhook-rebuild {on,off} β€” enable auto-rebuilding.
  • --chroot-denylist CHROOT_DENYLIST β€” comma-separated list of wildcard patterns of chroots to exclude from builds, e.g. fedora-,epel--i386.

copr-cli edit-package-rubygems [options]

usage: copr edit-package-rubygems [-h] [--gem GEM] --name PKGNAME
[--webhook-rebuild {on,off}] [--chroot-denylist CHROOT_DENYLIST] project

Edits the source definition and type of an existing package. options are shared with add-package-rubygems, so it's the same menu, different day ✨


copr-cli add-package-custom [options]

usage: copr add-package-custom [-h] --script SCRIPT [--script-chroot
SCRIPT_CHROOT] [--script-builddeps SCRIPT_BUILDDEPS] [--script-resultdir
SCRIPT_RESULTDIR] [--script-repos SCRIPT_REPOS] --name PKGNAME
[--webhook-rebuild {on,off}] [--chroot-denylist CHROOT_DENYLIST]
[--max-builds MAX_BUILDS] [--timeout TIMEOUT] project

Adds a package of Custom source type β€” the "I'll do it myself" era 😀πŸ”₯

  • --script SCRIPT β€” text file (script) to be used to prepare the sources.
  • --script-chroot SCRIPT_CHROOT β€” mock chroot to build sources for the SRPM in.
  • --script-builddeps SCRIPT_BUILDDEPS β€” space separated list of packages needed to build the sources.
  • --script-resultdir SCRIPT_RESULTDIR β€” where SCRIPT generates the result, relatively to script’s $PWD (defaults to .).
  • --script-repos SCRIPT_REPOS β€” space separated string of additional repo urls for script dependencies.
  • --name PKGNAME β€” name of the package to be edited or created.
  • --webhook-rebuild {on,off} β€” enable auto-rebuilding.
  • --chroot-denylist CHROOT_DENYLIST β€” comma-separated list of wildcard patterns of chroots to exclude from builds, e.g. fedora-,epel--i386.
  • --max-builds MAX_BUILDS β€” keep only the specified number of the newest-by-id builds (garbage collector is run daily), zero disables (default).
  • --timeout TIMEOUT β€” number of seconds we allow the builds to run, default is 18000 (5h).

copr-cli edit-package-custom [options]

usage: copr edit-package-custom [-h] --script SCRIPT [--script-chroot
SCRIPT_CHROOT] [--script-builddeps SCRIPT_BUILDDEPS] [--script-resultdir
SCRIPT_RESULTDIR] [--script-repos SCRIPT_REPOS] --name PKGNAME
[--webhook-rebuild {on,off}] [--chroot-denylist CHROOT_DENYLIST]
[--max-builds MAX_BUILDS] [--timeout TIMEOUT] project

Edits the source definition and type of an existing package. options are shared with add-package-custom β€” same options, editing era πŸŽ€


copr-cli list-packages [options]

usage: copr list-packages [-h] [--with-latest-build]
[--with-latest-succeeded-build] [--with-all-builds] [--output-format
{json, text, text-row}] project

Lists all packages in the given project in json format. let's see what you've been cooking πŸ‘€

  • --with-latest-build β€” also display data related to the latest build for each package.
  • --with-latest-succeeded-build β€” also display data related to the latest succeeded build for each package.
  • --with-all-builds β€” also display data related to the builds for each package.
  • --output-format FORMAT β€” set the formatting style. we recommend using json, which prints the required data in json format. the text format prints the required data in a column, one piece of information per line. the text-row format prints all information separated by a space on a single line.

copr-cli list-package-names [options]

usage: copr list-package-names [-h] project

Only lists the package names in the given project, line by line. minimal, clean, no notes πŸ’…


copr-cli get-package [options]

usage: copr get-package [-h] --name PKGNAME [--with-latest-build]
[--with-latest-succeeded-build] [--with-all-builds] [--output-format
{json, text, text-row}] project

Similar to list-packages but returns just a single package directly as a json structure (not wrapped in a list). one package, main character energy πŸ‘‘

  • --output-format FORMAT β€” set the formatting style. we recommend using json, which prints the required data in json format. the text format prints the required data in a column, one piece of information per line. the text-row format prints all information separated by a space on a single line.

copr-cli delete-package [options]

usage: copr delete-package [-h] --name PKGNAME project

Deletes a package and all its builds from the given project. gone. deleted. not coming back 😭


copr-cli reset-package [options]

usage: copr reset-package [-h] --name PKGNAME project

Clears the default source of a package and its source type.

⚠️ bestie listen to me: all the package settings are lost after invoking this! like, ALL of them. fr fr.

copr-cli build-package [options]

usage: copr build-package [-h] [--memory MEMORY] [--timeout TIMEOUT]
[--nowait] [-r CHROOTS] --name PKGNAME project

Creates a new build of the given package from its source definition. the moment we've all been waiting for ✨πŸ”₯

  • --name PKGNAME β€” name of a package to be built.

For the rest of the arguments, see the copr-cli build command above. (it's up there, go look, iykyk 🫢)


copr-cli mock-config [options]

usage: copr mock-config [-h] project chroot

Gets the mock profile (similar to koji mock-config) and prints it to standard output. the configuration can be slightly different from the real mock configuration used by Copr Builders, but it should be similar enough for basic debugging (e.g. by mock --shell). basically a little preview of the vibe πŸ¦‹


🌸 EXAMPLES 🌸

here's the group chat receipts, copy-paste era:

copr-cli add-package-tito myproject --name pkgname --git-url http://github.com/clime/example.git --test on

copr-cli get-package myproject --name pkgname

copr-cli build-package myproject --name pkgname --nowait --timeout 10000 -r fedora-23-x86_64

copr-cli delete-package myproject --name pkgname

copr-cli mock-config myproject fedora-rawhide-x86_64

🚦 EXIT STATUS 🚦

Normally the exit code is 0 when everything goes well. but when it doesn't, bestie, we could get:

  1. 1 β€” bad request like wrong project name, insufficient rights etc. also might happen when the user interrupts the operation when they shouldn’t.
  2. 2 β€” wrong arguments given.
  3. 3 β€” bad or no configuration.
  4. 4 β€” build failed or was canceled.
  5. 5 β€” communication error between Cli and server. this issue probably means bug and should be reported.
  6. 6 β€” configuration error.
  7. 7 β€” authentication with Copr server failed.

πŸ” AUTHENTICATION πŸ”

Copr client supports token-based and GSSAPI authentication. two paths, pick your fighter πŸ’…

Visit the page https://copr.fedorainfracloud.org/api/ to obtain an API token. this token must be saved in the configuration file ~/.config/copr in the following format:

[copr-cli]
username = msuchy
login = Y57wcg==##fkfaxbkjhuoiebfafadl
token = vbfseelqdebzedukgombekmuvbkqwo
copr_url = https://copr.fedorainfracloud.org
# expiration date: 2023-01-01
🚨 be aware that API tokens have an expiration date! yes really. check the date.

To enable GSSAPI you need to obtain a Kerberos ticket. if you want to work with Fedora Copr, you can just do:

$ fkinit
Enter your password and OTP concatenated. (Ignore that the prompt is for only the token)
Enter OTP Token Value: <your password + OTP token>

To work with a different (non-Fedora Copr) instance, you will obtain the ticket differently and you still need to have a configuration file referring appropriate copr_url:

$ kinit username@EXAMPLE.COM
$ cat ~/.config/copr
[copr-cli]
copr_url = https://copr.example.com/

Copr client uses the python API internally, for more info take a look at the page https://python-copr.readthedocs.io/en/latest/ClientV3.html#example-usage 🐍✨

🌈 USING DIFFERENT COPR INSTANCE 🌈

Okay bestie, so you wanna point the copr client at a non-default Copr instance? Totally valid, we love range πŸ’…

Here's the tea: your API token for that instance lives right on the http://YOUR.COPR.URL/api/ page. Go grab it, it's just sitting there waiting for you ✨

Then you've got two vibes to pick from, and honestly both eat:

  • Replace your default config file β€” just swap out ~/.config/copr with the new one. Simple. Iconic.
  • Keep your default and make an alias instead β€” highkey the better move if you're juggling multiple instances, because then you get to keep both 🫢

For the alias route, drop this into your profile:

alias your_copr='copr --config ~/.config/your-copr'

Then whenever you type your_copr, it's talking to that instance with that config file. No cap, that's the whole trick πŸŽ€

Heads up bestie: make sure that alternative config file actually exists at the path you're pointing --config at, otherwise it's giving... nothing. πŸ™ˆ

πŸ‘‘ AUTHORS πŸ‘‘

The absolute legends who made this happen:

  • Miroslav SuchΓ½ <msuchy@redhat.com>
  • clime <clime@redhat.com>

Give them their flowers, fr fr 🌸


And that's a wrap on the whole COPR-CLI(1) page, bestie!! You read the entire thing and I'm so proud of you πŸ˜­πŸ’– This version is copr, dated 09/22/2026, and it goes by the name COPR-CLI(1). Now go build something, slay, and remember: the manpage is your friend πŸ¦‹βœ¨

πŸ“¦ where this page comes from