Hello, I have just deployed copr-frontend with additional fixes for module
building and custom method. There was a problem for both when running from
On Mon, Feb 26, 2018 at 11:04 PM, Michal Novotny <clime(a)redhat.com> wrote:
last week on Friday, we released the latest version of our stack. It was
quite a big release, probably the biggest we have done so far...so as
expected some problems occured - mainly, fedmsg sending didn't work up
until Saturday 11pm UTC, rpm download counting was a bit off (counting in
also hits from copr builders), and fas group list didn't contain any
The first problem was, in the end, solvable pretty easily by upgrading
python3-fedmsg from version 1.0.1-4 to 1.1.0-1. In 1.0.1-4, there is a bug
in signing by x509 that makes the message sending fail during json
serialization (on error: type 'bytes' is not json-serializable). The same
problem is there for gpg crypto backend even in master:
, I believe (but I might
The second problem was solved by excluding copr-builder-gateway
(communication bridge between builders and copr-backend) from hit-counting.
But this was done as late as today so some projects will have an excessive
number of rpm downloads reported for the next ~6 days :).
And finally the third problem, was in python2->python3 conversion. Namely,
in python3, 'filter' built-in method returns an iterator and if you do
something like: some_list = [x for x in filter_iter] and then you try to
do: another_list = list(filter_iter), then another_list will be empty due
to the previously done iteration. Not so surprising once you know it but
before...quite hard to find :).
So all of these problems should be pretty much resolved now. I don't
expect this will be everything but I still consider this release to go
relatively smoothly so far.
So...what new did we actually bring?
Well, the first thing you can notice are the cool graphs showing number of
running builds during last day and last 90 days (https://copr
). We might do some minor tweaks to the
graphics but otherwise I consider this work of our intern Dominik Turecek
Then there is a new "custom" srpm build method together with a custom
webhook (!) thanks to Pavel Raiskup! This method makes it possible to very
easily tweak the dynamic source rpm generation procedure by giving you
anything-to-type text-area so you can e.g. write:
spectool -g *.spec
as suggested here: https://pagure.io/copr/copr/issue/246
Extended examples of how to use this method (source type) can be found
html#custom-source-method. By the way, we plan to extend the custom
webhook functionality to other source methods as well.
Another thing is Fedora DistGit auto-rebuilding!
You can now setup a package in COPR that will be auto-rebuilt by a commit
into your package repo at src.fedoraproject.org
_super_ easily. All that
is needed is to create a new SCM package, fill in "Clone URL" field with
https:// clone url of your package repo and check "Webhook rebuild" (and
Note that you don't need to enable anything at src.fp.o settings page for
your package if your package repo is a "main repo" (unforked). I will
probably send a note about this feature even to fedora-devel mailing list.
Next thing is that we reworked how "modules" are built in COPR, which is a
great work done by Jakub Kadlcik. The main difference is that we no longer
use MBS (Module Build Service) for building modules but we are building
them ourselves, which brought many simplifications. Jakub will give you
more information about this in his blog at http://frostyx.cz/
Another quite important thing is that we improved our queuing mechanism to
prevent queue jamming that tend to occur quite frequently recently. We
should be able to increase our throughput by a100% at least (in case anyone
is building in COPR).
Oh, we also added support for auto-rebuilding from BitBucket (!), which is
a great work done by Peter Oliver (mavit).
Next, we actually added tracking of srpm build progress (in case of
dynamic source-generation methods like SCM). COPR now shows the progress of
the srpm build as pending->starting->running(->suceeded), the same as for
rpm build. The last item is in parentheses because when srpm build
succeeds, then rpm (chroot) builds start (until then they are in "waiting"
state) and the whole build status will start to follow the rpm builds.
We also converted most of the stack to python3 (or python2+python3 as is
the case for python-copr). The exception is copr-dist-git subpackage
because there we needed to wait for python3-rpkg lib to be released first.
Finally there was also some work done in copr-rpmbuild (the COPR builder
package). You can now e.g. execute an rpm build _directly_ from a Github
copr-rpmbuild scm --clone-url https://github.com/<user>/<repo>
...of course that target repo needs to contain a spec file (at a given
path, by default /) but still this is quite nice.
There were probably more minor changes and some bugfixes but I am out of
ideas right now. Please, check, the release notes at Bodhi** to get
changelogs with full info. I think I covered the major things pretty
well...but there is probably still something important I left out.
So what's next?
Well, we are making a new API (API number 3. :)). If you are interested
or you have some ideas how this API should look like, please, comment on
We will continue to work on copr-rpmbuild to make it more user-friendly
and there is also an upcoming hot event of migrating the COPR stack to a
new cloud environment :) (that hopefully will not have memory leaks like
the current one has).
Finally, copr-dist-git auto-importing is likely to become a very optional
feature but that might take a little bit of time.
Take care and enjoy!