So apparently copr caches SRPMs based on the URL. If you create a new
build using the same URL as a previous failed build it doesn't download
the new SRPM. I suspect that the behavior should be to never cache for
Alternatively, if you want to cache in that case, you should cache not
based on URL but based on the Etag header. This ensures that if the
contents change, you will always get the new SRPM.
Repository : http://git.fedorahosted.org/cgit/copr.git
On branch : master
Author: Pierre-Yves Chibon <pingou(a)pingoured.fr>
Date: Sun Mar 10 09:35:57 2013 +0100
Add a README file with basic instruction on how to setup the CLI
copr_cli/README.rst | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/copr_cli/README.rst b/copr_cli/README.rst
new file mode 100644
@@ -0,0 +1,51 @@
+Copr is designed to be a lightweight buildsystem that allows contributors
+to create packages, put them in repositories, and make it easy for users
+to install the packages onto their system. Within the Fedora Project it
+is used to allow packagers to create third party repositories.
+This part is a command line interface to use copr.
+About this project:
+- Webiste: https://fedorahosted.org/copr/
+- Git: http://git.fedorahosted.org/cgit/copr.git
+- Test instance: http://copr-fe.cloud.fedoraproject.org/
+.. _python-requests: http://docs.python-requests.org/en/latest/
+.. _python-argparse: https://pypi.python.org/pypi/argparse
+The CLI depends on:
+- python (should work on 2.5, not tested)
+- `python-argparse`_ (for python < 2.7)
+.. _test instance: http://copr-fe.cloud.fedoraproject.org/
+- Create an account on copr `test instance`_
+- Go to the API page: http://copr-fe.cloud.fedoraproject.org/api
+- Retrieve your API token
+- Create the file ``~/.config/copr``
+- In this file add the following content
+ username = <insert here your username>
+ token = <insert here your API token>
+You should then be able to use copr-cli to list, create and build on copr.
+.. note:: You can use directly copr-cli to list someone's copr repo but to create
+ a copr or build packages into an existing repo you need to authenticate
+ via the API token.
Can some of you guys please tell me what the Copr.repos class member is
I understand that it contains .repo files, but where will these come
from and where will they go? Are they .repos for pointing to
coprs/chroots created within the copr application, or will they be used
as external repos submitted by users for build time or even something
Does the variable hold URLs or a list of strings or something else? Now
I dont't really know what the variable does and/or if I'm supposed
to touch it when implementing the generation of repo files for
coprs/chroots (TRAC ticket 21 ).
Thanks a lot, TR
Tomas Radej <tradej(a)redhat.com>
the previous mail  from Tomas Radej made me wondering, whether we should allow adding arbitrary repos to copr. Most importantly, anyone can build package A that is totally ok in copr, but make it depend on "evil" package B from an outside repo. So when a user would try to install all the dependencies of package A, that would also require installing package B (and user might just trust that B is ok, add the outside repo and go on). So from my point of view, we can't add third party repos to generated .repo files, that's for sure.
But that brings a question whether it even makes sense to add these to copr repos. Because they would only be good for building packages, but users would never be able to reach them.
So here is my proposal:
- For now, keep the posibility of adding arbitrary repos to copr, but never make them available through .repo files.
- Consider dropping these ^^ completely (I'm not sure about this point, I'd like to hear some opinions).
- A very nice functionality would be to only add other coprs to repos. This way, we could make sure that anything user tries to install will have dependencies met and also we will have them under control. Also, that would allow us to generate RPMs with .repo files that would depend on other (e.g. copr X depends on copr Y, generated RPM for X depends on RPM for Y, Yum can download that somehow). Thoughts?
And I still hope that this would actually not destroy any of Tomas's work :)
Please comment, I'd really love to hear some opinions on this.
Bohuslav "Slavek" Kabrda.
On 03/01/2013 02:26 AM, Bohuslav Kabrda wrote:
> - For now, keep the posibility of adding arbitrary repos to copr, but never make them available through .repo files.
+1 this allows the most flexibility, while keeping things relatively
safe (ie, clearly don't ever want to enable arbitrary stuff via .repos