Since ld.gold segfault on Fedora 33 and rawhide when it uses more than
one thread [1], 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 [2] took 29h 50m for
Fedora 33, and this build [3] 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.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1873848
[2] https://copr.fedorainfracloud.org/coprs/lantw44/chromium/build/1782394/
[3] https://copr.fedorainfracloud.org/coprs/lantw44/chromium/build/1794997/
There will be an outage starting at:
$ date --date '2021-01-21 8:30 UTC'
The outage will last approximately 2 hours. The copr-backend storage (copr
build results) will be offline for ~20 minutes (we are going to assign ipv6
there and the box needs to be rebooted).
Reason for outage:
We're updating copr packages to the new versions which will bring new
features and bugfixes.
We should do some IPv6 accessibility improvements.
Affected Services:
copr-frontend - https://copr.fedorainfracloud.org
copr-backend - https://copr-be.cloud.fedoraproject.org/
Contact persons:
@praiskup/@frostyx
Infra ticket:
https://pagure.io/fedora-infrastructure/issue/9588
Please join #fedora-admin in irc.freenode.net or add comments to the ticket for
this outage above.
On 04. 01. 21 18:38, José Abílio Matos wrote:
> I have used copr to build the first alpha release of lyx-2.4:
>
> https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/build/1858028/
> <https://copr.fedorainfracloud.org/coprs/jamatos/lyx-devel/build/1858028/>
>
>
> For EPEL7 it build for x86_64 and it fails for aarch64, due to %{python3} not
> being defined.
>
>
>
> The spec file has BR: python3-devel.
>
>
> In the install stage I have this:
>
>
> %py_byte_compile %{python3} %{buildroot}%{_datadir}/%{name}/lyx2lyx
>
>
>
> This fails in epel-7-aarch64...
>
>
> Is this known?
Yes. The macro was added to EPEL 7 only after aarch64 was discontinued there:
https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedorapro…
No easy way to solve this except to stop building for aarch64 on EPEL 7. You
could use the %__python3 macro instead to workaround this particular problem,
but you will most likely hit another one later.
I wonder whether Copr should disable EPEL 7 aarch64 chroots or at least put a
big red sign next to them.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
Hello,
Your certificate (or certificates) for the names listed below will expire in 9 days (on 17 Jan 21 17:34 +0000). Please make sure to renew your certificate before then, or visitors to your website will encounter errors.
We recommend renewing certificates automatically when they have a third of their
total lifetime left. For Let's Encrypt's current 90-day certificates, that means
renewing 30 days before expiration. See
https://letsencrypt.org/docs/integration-guide/ for details.
copr-dist-git.aws.fedoraproject.org
For any questions or support, please visit https://community.letsencrypt.org/. Unfortunately, we can't provide support by email.
For details about when we send these emails, please visit https://letsencrypt.org/docs/expiration-emails/. In particular, note that this reminder email is still sent if you've obtained a slightly different certificate by adding or removing names. If you've replaced this certificate with a newer one that covers more or fewer names than the list above, you may be able to ignore this message.
If you are receiving this email in error, unsubscribe at http://mandrillapp.com/track/unsub.php?u=30850198&id=b55e677509ce440880b149…
Regards,
The Let's Encrypt Team