Oracle Linux chroots (temporarily) available in Fedora Copr
by Pavel Raiskup
Hello,
just a quick note - we enabled Oracle Linux chroots in Fedora Copr today,
this is temporarily needed by OAMG/LEAPP team for their CI/CD system.
Feel free to test those chroots, but please don't heavily depend on them
as we don't know when we'll again drop them (preferably use
epel/centos-stream chroots instead, they should provide similar build results).
Pavel
7 months, 3 weeks
rpkg-util v3 change, moving copr builders to F35
by Pavel Raiskup
Hello,
we are currently preparing Copr build system for migration to Fedora 35,
including the builder workers.
There's though, at least from the builder perspective, a major `rpkg-util`
behavior change [1] (removal of `auto_pack` feature) that many of the Copr
projects rely on. This is a bit unexpected as `auto_pack = True` has been
the default in Copr for a long time, and the rpkg-util upstream intentions
behind the feature were generally misunderstood (even in Copr team).
That being said, some of the currently working builds on F34 would fail
after the migration to F35.
In order to make the migration a bit less dramatic, we plan to migrate in
the following steps:
1. Document the feature drop and possible fixes/workarounds see [1], and
properly announce the change in advance (here we are _now_).
2. Change the default, and turn off the `auto_pack` feature for
relatively short period of time on the current F34 builders
(ie autopack=False). This will happen soon in December 2021.
The change will naturally trigger the build failures, but a bit
earlier so users will be informed sooner ... with a _temporary_
work-around in hand => everyone can provide the file
<git-root>/rpkg.conf upstream, and opt-in the old behavior with with
content like:
[rpkg]
# temporary work-around for rpkg-util v2, auto_pack is going to be
# removed soon! See:
# https://docs.pagure.org/copr.copr/rpkg_util_2_vs_3.html#rpkg-util-v3
auto_pack = True
3. Migrate to Fedora 35, early in January 2022. This will make the
`auto_pack = True` work-around non-working, and users will have to
adapt, again, see [1].
Of course, anyone is encouraged to migrate to the new syntax **right now**,
sooner the better. If done correctly, package can be built both with rpkg-util
v2 and v3 [2].
Sorry for inconvenience! Any comment, idea or help is welcome!
[1] https://docs.pagure.org/copr.copr/rpkg_util_2_vs_3.html#rpkg-util-v3
[2] https://pagure.io/copr/copr-hello/c/739ff9910ee8a9c76d7e97de2f6176106dc19...
Pavel
1 year
Mock/Copr default epel-8-* configuration to be changed
by Pavel Raiskup
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
1 year, 2 months