Since ld.gold segfault on Fedora 33 and rawhide when it uses more than
one thread , I switched my Chromium builds to use ld.bfd a few months
ago. The change increased the build time, but at least the build didn't
fail in 1 hour due to ld.gold segfault.
It seems that Chromium 87 increases the build time further with its
Ozone platform. Now it is very hard to get successful builds of Chromium
87 on Copr. After submitting Chromium 87.0.4280.66 builds for more than
10 times, I still couldn't get successful builds for all chroots. Even
if there were successful builds in some chroots, the build time was
pretty close to the limit. For example, this build  took 29h 50m for
Fedora 33, and this build  took 29h 52m for Fedora rawhide.
Is it possible to raise the limit again? Given that Chromium keeps
increasing the build time for the past 2 years, I think we should raise
the limit to 48 hours this time.
due to not yet known issue, copr-keygen machine stopped responding and
we had to reboot it. As a consequence, we experienced a ~4 hours
outage window during which every submitted build failed.
The unplanned outage:
- started: 2020-12-29 07:22 UTC
- was reported: 2020-12-29 09:48 UTC
- ended: 2020-12-29 11:14 UTC
And builds between 1850184 and 1850351 were affected. Please consider
resubmitting them. Everything is up and running now.
Sorry for the inconvenience,
We just had an interesting discussion in our team and we'd love to ask
you, copr devs, about your opinion.
Would that be a big of a deal if packit-service sent thousands of
build requests within a short period of time?
Context: right now in our packit github app we only allow builds being
triggered by "trusted" contributors. So if a person opens a PR on a
project and is not a contributor, that request is not being built -
the project maintainer needs to trigger the build manually. We
received suggestions to drop this and build all PRs no matter who
Our main concern is that someone could create a malicious contribution
which would get into copr or some bot would open thousands of useless
PRs, thus DoSing CI systems.
Did you already have problems with this? Would this be a concern?
[using user-cont-team@ ML since that's our only public list]
The Fedora 31 and EPEL 6 chroots are marked as EOL in Copr now (for the epel
case, it's not even easily possible to build there nowadays because CentOS
already stopped mirroring of the repos).
There's additional 180 days period when we keep the build results. If you want
to keep the results longer than that, don't forget to periodically check your
EOLed chroots: https://copr.fedorainfracloud.org/user/repositories/
Today there will be a Copr outage starting at:
$ date --date '2020-12-01 13:00 UTC'
The outage will last approximately 1 hour. The copr-backend storage (copr
build results) will stay online.
Reason for outage:
We're updating copr packages to the new versions which will bring new features
copr-frontend - https://copr.fedorainfracloud.org
Please join #fedora-admin in irc.freenode.net or add comments to the ticket for
this outage above.