Determine root.log vs build.log failures
by Miro Hrončok
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
4 years, 5 months
Copr builders moved to Fedora 30, added AARCH64 support
by Pavel Raiskup
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
4 years, 6 months
bootstrap_container option is broken in on F30 builders
by Pavel Raiskup
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
4 years, 6 months
Automatic rawhide rebuilds vs. src.fp.o Pull Requests
by Miro Hrončok
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
4 years, 6 months
builder-live.log: Can we get Content-Type: text/plain; charset=utf-8?
by Miro Hrončok
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
4 years, 6 months
API feedback: It's faster to grep HTML
by Miro Hrončok
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
4 years, 6 months
