as suggested here: https://pagure.io/copr/copr/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.So...what new did we actually bring?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.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 :).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 :).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: https://github.com/fedora-Hello folks,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 entries.infra/fedmsg/issues/506 , I believe (but I might be wrong).fedorainfracloud.org/status/ ). We might do some minor tweaks to the graphics but otherwise I consider this work of our intern Dominik Turecek very nice.stats/
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:#! /bin/sh rust2rpm <pkgname> spectool -g *.specissue/246
Extended examples of how to use this method (source type) can be found here: https://docs.pagure.org/copr.copr/custom_source_method. . By the way, we plan to extend the custom webhook functionality to other source methods as well.html#custom-source-method 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 Save).
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 repo: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 https://pagure.io/copr/copr/issue/218 .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!COPR team**updates: