copr-devel February 2018

copr-devel@lists.fedorahosted.org

10 participants
10 discussions

copr-be's storage
by Miroslav Suchý 13 Oct '18

13 Oct '18

FYI I just resized copr-be storage for DNF repos from 4TB to 6TB. It was as easy as: umount /var/lib/copr/public_html systemctl stop var-lib-copr-public_html.mount copr-backend-service stop systemctls stop lighttpd.service in openstack dashboard, detach the volume, click "enlarge volume", set it to 6000GB. attach it back. Again: umount /var/lib/copr/public_html systemctl stop var-lib-copr-public_html.mount parted (parted) print free Number Start End Size File system Name Flags 17.4kB 1049kB 1031kB Free Space 1 1049kB 4398GB 4398GB ext4 4398GB 6442GB 2044GB Free Space (parted) resizepart Partition number? 1 End? [4398GB]? 6442GB resize2fs /dev/vdc1 systemctl start var-lib-copr-public_html.mount systemctls start lighttpd.service copr-backend-service start # df -H /var/lib/copr/public_html Filesystem Size Used Avail Use% Mounted on /dev/vdc1 6.4T 4.2T 2.3T 65% /var/lib/copr/public_html Mirek

1 1

new copr-frontend release
by Michal Novotny 28 Feb '18

28 Feb '18

Hello, we have just deployed and released copr-frontend-1.129. This package contains the latest fixes upon big work done in copr-frontend-1.128. Also new python-copr-1.87 was released with a fix in ClientV2 regarding build statuses ("forked", "waiting") that were recently added into copr-frontend and ClientV2 became out of sync. You can find the latest packages at https://copr.fedorainfracloud.org/coprs/g/copr/copr/ (dnf copr enable @copr/copr + dnf install <coprpkg>) if you are too impatient to wait for the Fedora package to get into stable :). Enjoy! COPR team --- copr-frontend changelog: - several tweaks for graphs of utilization - fix copr_update after user and group routes merge - custom build: single-line textarea placeholder - vanish '\r\n' in custom script - fix filter has no len() error - make the news box optional - fix group listing - remove workaround from copr_url macro - merge regular and group views

1 0

Release notes
by Michal Novotny 27 Feb '18

27 Feb '18

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. 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-infra/fedmsg/issues/506, I believe (but I might be wrong). 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.fedorainfracloud.org/status/stats/). We might do some minor tweaks to the graphics but otherwise I consider this work of our intern Dominik Turecek very nice. 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 *.spec as suggested here: https://pagure.io/copr/copr/issue/246 Extended examples of how to use this method (source type) can be found here: https://docs.pagure.org/copr.copr/custom_source_method.html#custom-source-m…. 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 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: frontend: https://bodhi.fedoraproject.org/updates/FEDORA-2018-38ce310035 backend: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2aee8c7217 keygen: https://bodhi.fedoraproject.org/updates/FEDORA-2018-17c38441a8 selinux: https://bodhi.fedoraproject.org/updates/FEDORA-2018-11f4dc252c rpmbuild: https://bodhi.fedoraproject.org/updates/FEDORA-2018-cc8f474468 python-copr: https://bodhi.fedoraproject.org/updates/FEDORA-2018-48a7c1ee1d copr-cli: https://bodhi.fedoraproject.org/updates/FEDORA-2018-7f93a72506 dist-git: https://bodhi.fedoraproject.org/updates/FEDORA-2018-027c334d03

1 1

Fedora 28 chroots are available
by Jakub Kadlcik 26 Feb '18

26 Feb '18

Hello, Fedora 28 chroots were added to Copr. For projects with "Follow Fedora branching" option enabled, the fedora-28-* chroots were auto-created in their projects and existing builds from the rawhide chroots were copied there. COPR team

1 0

New release
by Michal Novotny 23 Feb '18

23 Feb '18

Hello, we have just deployed the latest COPR stack to the production. I will talk more about it on Monday. For now, you can enjoy the new graphs that our _very_ talented intern has made :)... COPR team

1 0

Usefulness of `copr mock-config <PROJECT> <CHROOT>` feature?
by Pavel Raiskup 15 Feb '18

15 Feb '18

Because we are unable to find a consensus on implementation details, it's likely we'll drop this feature from copr API and it will be probably a bit more complicated to setup mock chroot for local tests in future (you'll need to have builder machine with copr-rpmbuild installed, which brings a lot more runtime dependencies at least). From user perspective, do you mind if we dropped `copr mock-config` command? Pavel

5 11

Give us a feedback on API situation
by Jakub Kadlcik 13 Feb '18

13 Feb '18

Hello, we are currently discussing how to deal with the current situation of inconsistent Copr API. If you are interested in this topic and want to give us some feedback, please see the https://pagure.io/copr/copr/issue/218 COPR team

2 1

aarch64 copr?
by Avi Kivity 07 Feb '18

07 Feb '18

Are there plans to add aarch64 copr support? If so, when can we expect it to be live?

3 2

building swing from f27 on el7 :: Traceback in copr-rpmbuild
by Adrian Sevcenco 02 Feb '18

02 Feb '18

Hi! I am trying to build a newer swig version for el7 starting from the srpm for f27 .. locally on a el7 machine i built the rpm (with java removal from original spec) and the resulting srpm i tried to build on copr .. but i have some errors that seems not related to package : https://copr-be.cloud.fedoraproject.org/results/asevcenc/science-utils/srpm… stdout: Downloading swig-3.0.12.tar.gz stderr: Could not execute srpm: 'ns2' Traceback (most recent call last): File "/usr/bin/copr-rpmbuild", line 96, in main action(args, config) File "/usr/bin/copr-rpmbuild", line 126, in build_srpm provider.produce_srpm() File "/usr/lib/python3.6/site-packages/copr_rpmbuild/providers/scm.py", line 115, in produce_srpm return run_cmd(cmd, cwd=self.repo_subpath) File "/usr/lib/python3.6/site-packages/copr_rpmbuild/helpers.py", line 66, in run_cmd raise RuntimeError(result.stderr) RuntimeError: Could not execute srpm: 'ns2' given that i am really new to copr usage i might miss some procedures .. does anyone have any idea about the error and/or workflow with copr? so far my experience is just using copr-cli to upload a srpm.. Thank you! Adrian

2 1

systemtap uninstallable in Rawhide
by Richard W.M. Jones 02 Feb '18

02 Feb '18

https://copr-be.cloud.fedoraproject.org/results/rjones/riscv/fedora-rawhide… Something to do with boost: DEBUG util.py:479: Error: DEBUG util.py:479: Problem: package systemtap-client-3.2-3.fc28.x86_64 requires systemtap-runtime = 3.2-3.fc28, but none of the providers can be installed DEBUG util.py:479: - package systemtap-3.2-3.fc28.x86_64 requires systemtap-client = 3.2-3.fc28, but none of the providers can be installed DEBUG util.py:479: - package systemtap-runtime-3.2-3.fc28.x86_64 requires libdyninstAPI.so.9.3()(64bit), but none of the providers can be installed DEBUG util.py:479: - conflicting requests DEBUG util.py:479: - nothing provides libboost_system.so.1.64.0()(64bit) needed by dyninst-9.3.2-7.fc28.x86_64 DEBUG util.py:617: Child return code was: 1 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

copr-devel February 2018