Just to be more pedantic and probably bit more secure, what about making
networking in copr opt-in (at least for new projects)?
If build of my package used internet arbitrarily, I would be warned very
Also, in Koji we also do not have networking, so we can faster teach
(future) Fedora packagers.
Thanks for considering,
It is my pleasure to announce new version of Copr.
What's new? Group projects!
When you log in. You can see in right column link "My Groups". There you can see list of your FAS groups and you can
activate them. In fact, you actually create alias for them. E.g. FAS group "gitmock" can be named "mock" in Copr.
You can click on Copr group in right column. That navigate you to url in format:
Where are listed all projects of this group. And you can create new group project there too.
Every member of that FAS group can administer it and build there. Due to the OpenID limitations, you have to
log-out/log-in to see your groups (or whenever you join new group in FAS).
Since copr-cli-1.45 (in updates-testing right now) you can submit package to group project like:
copr-cli build @GROUP/PROJECT
copr-cli build @mock/mock-dev
Creation of group project is not possible from command line right now due OpenID restriction and you have to use WebUI.
This may change in near future.
There is no API method in APIv1. But we provide APIv2
which has methods to manipulate with groups.
To create new group in FAS, just follow:
If you have some personal project and you want to change it to group project, then please let me know and we change it
Miroslav Suchy, RHCA
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys
I've the need of using copr-cli in other distros so I've decided to upload
it to PyPI. In order to do that I had to change the setup.py file in both
copr-cli and copr-python projects.
The problem is that the setup.py was importing the code it was supposed to
install and breaking because the dependencies weren't installed yet. To fix
that I've added a function that parses the content of the file looking for
it's version instead of importing it.
Doing that the installer is able to build the dependencies tree and look
for each dependency on the package index.
Also the Alpha classifier used was wrong so I've changed it from:
"Development Status :: 1 - Alpha"
"Development Status :: 3 - Alpha"
Last, I've updated the versions to use the tagged versions. You will find
my commits attached.
The attached patch implements a progress bar for uploading SRPMs.
Basically I've added a new "progress_callback" parameters to the
create_new_build (copr/python) function which is called for each chunk of
8192 bytes sent to the server. Then I've implemented the callback on the
copr-cli to update a bar object.
The bar format and library is the same than pip uses (see the screenshot
attached).[image: ss_progressbar.jpg] The lib I've used is available in the
fedora package python-progress but it's not available in EPEL. For that
reason I did not made that a hard dependency: if the python-progress is
installed the bar will show up, if not the lib just work as previously.
Is it possible to add python-progress to EPEL repo? If so I'd change the
spec to make copr-cli depend on it.
It is my pleasure to announce that we just upgraded
It includes several major improvements:
* UI converted to PatternFly . Most visible change is that tables
(e.g. list of builds) can be sorted using any column and you can filter
visible rows using any value.
* dist-git support -- We store your SRPM in dist-git now. It is not
accessible directly using fedpkg (it is in plan later). Dist-git is
browsable via cgit . This allows us to offer you upload of SRPM
directly from your workstation. Just navigate to:
New Build -> Upload SRPM
or if you upgrade to python-copr-1.58-1 (submitted to updates just
today) then you can do:
copr-cli build name/project ./some.src.rpm
While we assume that uploading SRPM will be most popular method, we
preserved option to pass SRPM url.
You can see new state of your build - "Importing". It is obviously the
moment when we import your SRPM into dist-git.
* In project properties (Edit tab) you can now add you email if you want
to be contacted by users in case of some problems with your project.
* We improved queue handling of various architectures. This should fix
those long waiting time of PPC64LE builds.