Hello Fedora EPEL maintainers!
First I don't feel comfortable announcing this, I'm not happy about the
situation and so I don't want to be the lightning rod :-). But I believe
that we can come to acceptable Copr/Mock solution and this needs to be
discussed... so here we are.
By the end of the year 2021 we have to fix our default EPEL 8 Mock
configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as CentOS 8
goes EOL by then.
The same thing needs to happen in Fedora Copr, with the epel-8-* chroots
(side note, in Fedora Copr we use the mock-core-configs package for builds
without any deployment specific modifications).
I am proposing (as PR against mock upstream ATM [1]) to switch the default
epel-* configuration from CentOS+EPEL to RHEL+EPEL as soon as possible
(see the pull request [1]).
This would bring some consequences, namely newly with epel-8* chroots,
- builds will require a valid Red Hat subscription (the no-cost variant is
OK as well, though [2])
- we will miss some build-time packages that Red Hat is not shipping, at
least at the beginning till they are added (to RHEL CRB, or other
currently unknown place).
- cross-arch compilation can not be used, Red Hat subscriptions don't
allow that (using QEMU and rpm --forcearch), [3]
The positive thing is that the default configuration will be much closer
to the official EPEL builds (because Fedora Koji EPEL builds are actually done
also against RHEL).
For the Fedora Copr builders, we already have the necessary Red Hat
subscriptions in hand (will be deployed by the end of the year). So we will
only loose the opportunity to build on emulated epel-8-armhfp permanently, and
epel-8-s390x temporarily (as we already work on the native s390x support).
Any thoughts? Feedback is needed here.
[1] https://github.com/rpm-software-management/mock/pull/802
[2] https://rpm-software-management.github.io/mock/Feature-rhelchroots
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1912847
Pavel
Hello everybody,
I'd like to announce that all Modularity features in Copr (except for
module hotfixes) are now deprecated, and we have a plan to slowly remove
them from our codebase.
For more reasoning and the retirement schedule, please read my blog post -
https://frostyx.cz/posts/copr-modularity-the-end-of-an-era
I will personally reach out to everybody who has submitted a module build
in Copr in the last two years and make sure they don't rely on this
functionality.
Jakub
Hello,
Due to ongoing issues with the following chroots that have not functioned
for the past year (tracked at [1]), I have temporarily disabled them until
a resolution is found:
- openmandriva-cooker-aarch64
- openmandriva-cooker-i686
- openmandriva-cooker-x86_64
- openmandriva-rolling-x86_64
- openmandriva-rolling-i686
- openmandriva-rolling-aarch64
I appreciate your understanding and I will keep you updated on any
developments regarding this issue. If you have any questions or concerns,
please feel free to reach out.
[1] - https://github.com/rpm-software-management/mock/issues/1066
Best regards,
--
Jiri Kyjovsky
Associate Software Engineer, CPT
Red Hat <https://www.redhat.com>
Brno, Czech Republic
<https://www.redhat.com>
Hi,
There will be an outage starting at:
```
$ date --date '2024-10-03 11:00 UTC'
```
The outage will last approximately 3 hours. The copr-backend storage (copr
build results) will stay mostly online during this outage but some downtime
is expected.
Reason for outage:
We're updating copr packages to the new versions which will bring new
features and bugfixes.
Affected Services:
copr-frontend - https://copr.fedorainfracloud.org
copr-backend - https://copr-be.cloud.fedoraproject.org/
Contact persons:
@frostyx / @praiskup / @nikromen
Please join Fedora Build System Matrix channel
https://matrix.to/#/#buildsys:fedoraproject.org
or comment on this mail.
Sorry for the inconvenience,
--
Jiri Kyjovsky
Associate Software Engineer, CPT
Red Hat <https://www.redhat.com>
Brno, Czech Republic
<https://www.redhat.com>