copr-be's storage
by Miroslav Suchý
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
5 years, 6 months
new copr-frontend release
by Michal Novotny
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
6 years, 1 month
Release notes
by Michal Novotny
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....
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
6 years, 1 month
Fedora 28 chroots are available
by Jakub Kadlcik
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
6 years, 2 months
New release
by Michal Novotny
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
6 years, 2 months
Usefulness of `copr mock-config <PROJECT> <CHROOT>` feature?
by Pavel Raiskup
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
6 years, 2 months
aarch64 copr?
by Avi Kivity
Are there plans to add aarch64 copr support? If so, when can we expect it
to be live?
6 years, 2 months
building swing from f27 on el7 :: Traceback in copr-rpmbuild
by Adrian Sevcenco
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/sr...
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
6 years, 2 months
systemtap uninstallable in Rawhide
by Richard W.M. Jones
https://copr-be.cloud.fedoraproject.org/results/rjones/riscv/fedora-rawhi...
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/
6 years, 2 months
