copr-devel May 2019

copr-devel@lists.fedorahosted.org

2 participants
9 discussions

Determine root.log vs build.log failures
by Miro Hrončok 25 Jun '19

25 Jun '19

Hey! Koji is always very nice and it tells me whether a build failure was caused by root.log or build.log. See for example: https://koji.fedoraproject.org/koji/taskinfo?taskID=28963878 BuildError: error building package (arch x86_64), mock exited with status 1; see build.log for more information Is Copr presenting this kind of information somewhere? (I need to fetch it for hundreds of builds.) I could probably HTTP HEAD the build.log and check Content-Length to guess a root.log failure, but it feels weird... Thanks for tips. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 3

Copr builders moved to Fedora 30, added AARCH64 support
by Pavel Raiskup 30 May '19

30 May '19

Hello, fyi, Fedora Copr builders were recently upgraded to Fedora 30 (from F28). The major change is that `yum` package is not working ideally on F30 anymore, and soon (on F31) there will be no `yum` at all [1]. Mock (which is used on builders) though uses /usr/bin/yum-deprecated (yum) by default for epel* chroots installation usually (on Fedora host), even though it may use /usr/bin/yum symlink to /usr/bin/dnf as a fallback. The major difference from mock perspective (and why yum-deprecated is actually preferred, when available) is that dnf might calculate the install transactions a little bit differently from yum. And repositories for epel are designed for/tested against yum; ... so using dnf can cause some unexpected problems.. We decided to move to dnf (dnf-yum) rather sooner in Copr, to have a bit more time for solving potential problems, and inform others. So if you face any related issues to this movement in copr (packages were installed fine before, but are not now), you might want to enable the bootstrap_chroot feature in your copr project; go to: Project -> Settings -> [x] Enable mock's use_bootstrap_container experimental feature .. and if useful, fill a bug report. For more info about bootstrap_chroot feature consult the man 1 mock. As a bonus, we now have builders (F30) for aarch64 architecture! Expect slightly slower queue processing there than on other architectures (only up 8 builders, and slightly slower boxes). Feel free to try them, and - as always - please report the issues :-) If you happen to work with epel* and mock on F30: - yum.rpm requires up2date urlgrabber package (rhbz#1707657) on highly python3-oriented F30, and to avoid unnecessary hassle you might want to rather uninstall yum package, but when you do this.. - using dnf (/bin/yum) for epel* builds might lead to problems with bootstrap chroot installation (elfutils from DTS from sclo* repos installed instead of default elfutils) [2] - also systemd-resolved running on host (even when it is unused) might cause some problems with name resolution in --bootstrap chroot, resp. if you happen to use --enable-network; work-around is to disable systemd-resolved.service [1] https://src.fedoraproject.org/rpms/yum/blob/master/f/dead.package [2] https://github.com/rpm-software-management/mock/pull/268 Hope that the transition will be smooth, happy building! Pavel

1 0

bootstrap_container option is broken in on F30 builders
by Pavel Raiskup 30 May '19

30 May '19

Hi all, we are in the process of migration builders to F30, and from recent build failures I deduce that the bootstrap_container feature is broken, or that we have the mock misconfigured on F30. If you see where the problem is, please let us know. Not really 100% work-around is to disable bootstrap_container feature (Settings -> uncheck the "Enable mock's use_bootstrap_container experimental feature"). In many cases it was enabled unintentionally; for a certain time period this was enabled by default. I'll have a look at the problem tomorrow morning (or sooner maybe), sorry for temporary inconvenience. Pavel

1 1

Automatic rawhide rebuilds vs. src.fp.o Pull Requests
by Miro Hrončok 28 May '19

28 May '19

I have several copr setup to automatically rebuild rawhide packages in various buildroots. The source of the package is set to: https://src.fedoraproject.org/rpms/<name>.git And committish is set to master. Yet when I made Pull Request on src.fp.o, Copr built that package. On the builds tab, I see that Copr understands what a PR is, as it lists it separately as a special "directory". See ":pr:11" at https://copr.fedorainfracloud.org/coprs/g/python/pypy36/builds/ It seems that the package is not available in the copr repo. Could you help me understand this feature? Can anyone build anything in my copr via this feature, but for obvious reasons, the builds are not added to the repo? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 6

builder-live.log: Can we get Content-Type: text/plain; charset=utf-8?
by Miro Hrončok 27 May '19

27 May '19

It happens to me often that my browser displays the builder-live.log like this: /usr/include/bits/string_fortified.h:106:10: warning: â€˜__builtin_strncpyâ€™ specified bound depends on the length of the source argument [-Wstringop-overflow=] When in fact it should be: /usr/include/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=] I believe this is a text encoding problem. Both Firefox and Chromium read it as Windows 1252 and not UTF-8. The headers sent by the web server are: Content-Type: text/plain I wonder whether it can be changed to: Content-Type: text/plain; charset=utf-8 Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 3

Copr frontend "micro" release
by Pavel Raiskup 23 May '19

23 May '19

We updated copr frontend (web-ui) part two days ago, it was rather small update but still worth saying: - there's enhanced "outdated chroots" [1] user interface (the repositories/ tab), so that - it's more clear what chroot builds are going to be deleted (and when) - nicer "expire" button - there fixed one bug so when you now enable/disable chroots in your project (settings), the list of outdated chroots isn't affected (#712) - there's now icon (red fedora) for the rhel 8 beta chroot - fixed several tracebacks (usually leading to http error 500) List of fixed issues: https://pagure.io/copr/copr/issue/593 https://pagure.io/copr/copr/issue/700 https://pagure.io/copr/copr/issue/707 https://pagure.io/copr/copr/issue/712 https://pagure.io/copr/copr/issue/714 https://pagure.io/copr/copr/issue/724 https://pagure.io/copr/copr/issue/739 [1] http://frostyx.cz/posts/copr-removing-outdated-chroots Pavel

1 0

API feedback: It's faster to grep HTML
by Miro Hrončok 22 May '19

22 May '19

Hi, For each package in a Copr, I want to get: * latest build ID (doesn't matter if latest successful or latest any) * that build status To get it I can either use this: copr list-packages --with-latest-succeeded-build <copr> Or parse the HTML returned from the Monitor page. Here's my feedback: The API option should be faster. It isn't. For a copr with only 24 builds, the JSON option takes 29 seconds, the HTML option takes 1 second. For a copr with 10k+ builds, the JSON option takes longer than I was willing to wait, the HTML option takes 6 seconds. If getting the information I need by parsing HTML is more pleasant than getting it via the API, something is wrong with the API. Not sure if this is severe enough to file a bug report, but please consider this feedback in your future API design decisions. Thank you, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 1

copr-dist-git.fedorainfracloud.org down?
by Miro Hrončok 10 May '19

10 May '19

I have some trouble with copr dist git: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/copr_rpmbuild/providers/scm.py", line 145, in clone_and_checkout helpers.run_cmd(clone_cmd) File "/usr/lib/python3.6/site-packages/copr_rpmbuild/helpers.py", line 79, in run_cmd raise RuntimeError(result.stderr) RuntimeError: Cloning into '/tmp/tmp2o0qogr2/dnf'... fatal: repository 'https://copr-dist-git.fedorainfracloud.org/git/@python/python3.8/dnf.git/' not found https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/906973/ I cannot accesss the address either. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 1

Why is copr downloading the sources from the Source URL?
by Miro Hrončok 02 May '19

02 May '19

I found this in several builder-live.logs: Start: rpmbuild -bs warning: Downloading http://downloads.tryton.org/4.0/trytond-analytic-account-4.0.1.tar.gz to /builddir/build/SOURCES/trytond-analytic-account-4.0.1.tar.gz curl: (6) Could not resolve host: downloads.tryton.org error: Couldn't download http://downloads.tryton.org/4.0/trytond-analytic-account-4.0.1.tar.gz https://copr.fedorainfracloud.org/coprs/g/python/python3.8/build/899299/ Several other tryton packages in https://copr.fedorainfracloud.org/coprs/g/python/python3.8/builds/ have the same problem. Their sources indeed 404. Is Copr downloading sources a known thing? I upload SRPMS. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

copr-devel May 2019