=== Planned Outage - PHX2-Production - 2019-08-21 20:00 UTC
There will be an outage starting at 2019-08-21 20:00 UTC,
which will last approximately 6 hours.
To convert UTC to your local time, take a look at
date -d '2019-08-21 20:00UTC'
Reason for outage:
RHEL-7.7 came out and a lot of other updates for various Fedora issues
will need updates and reboots of systems.
All staging/production and related services will be affected.
Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
Stephen J Smoogen.
The EPEL Steering Committee is pleased to announce that the initial
EPEL-8 is ready for release. We would like to thank everyone in the
community for helping us get the initial set of builds out to mirrors
and to consumers worldwide. Special thanks go to Patrick Uiterwijk,
Jeroen van Meeuwen, Robert Scheck, and many others in the community
who helped in the last 6 months to get this release done.
EPEL-8.0 has packages for the x86_64, ppc64le, aarch64, and now the
## What is EPEL?
EPEL stands for Extra Packages for Enterprise Linux and is a
subcommunity of the Fedora and CentOS projects aimed at bringing a
subset of packages out of Fedora releases ready to be used and
installed on various Red Hat Enterprise Linux (RHEL). It is not a
complete rebuild of Fedora or even of previous EPEL releases. EPEL is
also a community and not a product. As such we need community members
to help get packages into the repository more than done in Fedora.
If you are interested in getting a package into EPEL, contact the
package maintainer through bugzilla. This way the request can be
tracked, and if the primary maintainer is not interested in branching
to EPEL, others can step in and do so. Optionally you can send a
request to the epel-devel(a)lists.fedoraproject.org mailing list. If you
do so, please include why the package is needed, to help other
volunteers decide whether they can support it.
## What is new?
### Playground for Rawhide like things
We have added an additional set of channels for EPEL-8 called
playground. It is similar to Fedora Rawhide so packagers can work on
versions of software that are too fast moving or will have large API
changes compared to versions in the regular channel.
To make this purpose transparent, when a package is built in epel8, it
will normally also be built in epel8-playground. This is done via a
packages.cfg file which lists the targets for fedpkg to build against.
A successful package build will then go through two different paths:
* epel8 package will go into bodhi to be put into epel8-testing
* epel8-playground will bypass bodhi and go directly into
epel8-playground the next compose.
If a packager needs to focus only on epel8 or epel8-playground they
can edit packages.cfg to change the target=epel8 epel8-playground to
Packages in epel8-playground are intended to be used in the following manner:
* To test out a new version of the package that might not be stable yet.
* To test out new packaging of the package
* To test a major version change of the package intended for the next
EPEL-8 minor release.
* To build a package that will never be stable enough for EPEL-8, but
still could be useful to some.
At minor RHEL releases (ie, 8.1, 8.2) people can pull in big changes
from playground to the main EPEL-8 packages. Since people will be
upgrading and paying more attention than usual anyhow at those points,
it’s a great chance to do that change, but you can test beforehand in
the playground to make sure these changes work.
Consumers should be aware that packages in EPEL8-playground are
without any Service Level Expectations. You may want to only cherry
pick packages from the playground as needed.
### New Architecture: s390x
We have added the s390x platform to builds. Some consumers have wanted
this platform for many years but we did not have the time to integrate
necessary changes. We have done this with EPEL-8, and hope to be able
to do so for EPEL-7 if there are continued requests for it.
## What is next? (Why is it called EPEL-8.0?)
The goal for EPEL-8.1 will be implementing modules into the
repository, which allows builds for packages that depend on
non-shipped devel packages. It also allows maintainers to supplement
and replace other packages they could not under standard EPEL rules.
## Known Issues:
1. EPEL-8.0 does not come with modules. Packages built for perl,
python and other modules are only built against “default” modules. For
example installing a perl library from EPEL will work with the
perl-5.26 but not with the perl-5.24 module.
2. RHEL-8.0 and RHEL-8.1 beta do not come with the same packages in
all architectures. There are 720 ‘desktop’ packages which were only
shipped for x86_64 and ppc64le. Packagers looking to deliver GNOME,
KDE, or other platforms will need to exclude s390x and aarch64 at this
3. The dnf in RHEL-8.1 beta does not work with the EPEL repository due
to zchunk code. This has been opened as an upstream bug as
4. Until modularity and module builds are implemented in EPEL, there
will be many packages which can not be built for EPEL. This is mainly
due to RHEL-8 not shipping many -devel packages and the need for us to
rebuild those packages in a module to make those -devel available to
build against. When running into this please open a ticket with
https://pagure.io/epel/new_issue for us to put in a request for it to
be added to Red Hat’s Code Ready Builder. Please list the package(s)
which is blocked from being built because of its absence. We will
collate these items into bugzilla tickets which will be reviewed by
the Red Hat product groups to see if they will be added in future Code
Ready Builder releases. Doing this will ensure that we do not have 70
requests for foo-devel but can have one with all the packages needing
5. /usr/bin/python does not exist in RHEL8. Developers should aim
towards /usr/bin/python3 or /usr/bin/python2 and patch appropriately.
Python2 packages are discouraged. RHEL-8 will contain python2.7 until
probably the end of life of RHEL-7. However support upstream will only
be minimal. When modularity occurs, we suggest that you make whatever
python2 packages modules which can be pulled out when RHEL-8.N no
longer has python2.
6. python2-sphinx is not shipped. Most packages should work with
python3-sphinx, and if it doesn’t please open a bug. The python team
has been good about making fixes for this.
7. When branching python packages, be aware that python in EL-8 is
python36 and not the version currently in rawhide. This has come up
with a couple of test packages where they assumed python37 or later.
8. While EL-8 comes with platform-python, it should NOT be used in
Requires: unless absolutely necessary. python3 should be used instead.
(Exceptions can be made but will be rare and need justification.)
* Accepted exception: Use python3.6dist(coverage) instead of
python3-coverage. This package is not shipped but is needed in %check
10. Sometimes RHEL8 only has a python3 package for a dependency you
need for your build. (Example: python-bleach requires
python2-html5lib, but RHEL8 provides only python3-html5lib). For
EPEL-8.0 we recommend strongly to only focus on python3 subpackages..
11. RHEL-8 was built with packages which were not shipped. In general
it is OK to branch these packages and build them in EPEL.
12. systemd-rpm-macros is not a separate packages. If needed, used
13. You will need to make sure you have a version of fedpkg greater
than fedpkg-1.37-4 to work with both `epel8` and `epel8-playground`.
Versions before that should work with just `epel8`.
## Developer requests for multiple branches
Branching is handled the same way as requesting a branch using fedpkg
request-branch. A maintainer can request an epel8 branch using fedpkg
request-branch epel8 which will create a ticket in
https://pagure.io/releng/fedora-scm-requests/issues and Release
Engineering will process these requests.
To branch multiple packages please use this or a variant of this script:
# Reminder to get an updated pagure token for releng tickets
# Usage: epel-8.sh package1 package2 package3 package4
if [ $# -lt 1 ]
echo "At least one package name should be provided"
TMPDIR=`mktemp -d /tmp/epel8.XXXXXX`
for pkg in "$@"
fedpkg clone "$pkg"
fedpkg request-branch epel8
fedpkg request-branch epel8-playground
rm -rfv "$TMPDIR"
Releng will then work through the tickets in the system which is
adding branches to the PDC and src.fedoraproject.org.
## Known RHEL-8 packages missing -devel
* Package maintainer. Person who has accepted responsibility to
package and maintain software in the Fedora Project ecosystem. The
main packager is usually someone focused on Fedora Linux, and
secondary packagers may be focused on particular use cases like EPEL.
* Consumer. A person who has subscribed to EPEL for packages but is
not a maintainer.
* PDC. Product Definition Center. A tool to help list the lifetime and
permissions that a product has so that branching and updates can be
Stephen J Smoogen.
Fedora 31 will be branched from rawhide today as per the Fedora 31
schedule. The process takes about a day and everything should be ready
by tomorrow. You can still be able to build packages normally until then,
but after the mass branching rawhide and F31 will be separated.
We will send another email once the branching is done.
Fedora Release Engineering.
Due to an issue with mbs authentication and then travel for FLOCK, we
couldn't run mass rebuilds of modules last week (mass rebuilds of modules
is run after mass rebuild of rpms are done). We are planning to try it
today. Please look out for module builds that we will be submitting as part
of mass rebuild and sorry for the delay.
There is a Mass Branching scheduled for next Tuesday, that is on Aug 13th
2019. There were some modules that are stuck in rawhide that shouldn't be
there, please create a ticket in https://pagure.io/releng with the list of
module builds that shouldn't be there and we will remove them from rawhide
and will not be branched.
After some discussions, we (the Stewardship SIG) have decided that we
cannot continue to maintain gradle in fedora.
- the current version packaged in fedora is outdated (4.4.1, from Dec.
2017, vs. 5.5.1 from July 2019)
- it currently doesn't build itself (not even in bootstrap mode), and
needs an older version tagged into rawhide as a buildroot override to
even build (this doesn't work anymore, due to rawhide gating)
- the current version has open CVE issues associated with it on fedora 30+
- it pulls in a lot of dependencies (and newer versions pull in even
more), which we don't have the manpower to maintain (including scala,
- other distros seem to have basically given up on building gradle as
well, since they mostly ship the same version as fedora (except Arch,
where they just package up the binaries upstream publishes)
The current plan is to drop support for building packages with gradle,
first by orphaning / retiring gradle, and then removing the gradle
support code from javapackages-tools (which produces the gradle-local
Since there is a very limited number of actively maintained Java
packages that are built with gradle (less than 10), we expect the
breakage not to be too bad.
Also, there is a possibility to "port" projects that currently use
gradle to be built with maven instead, which has already been done for
some fedora packages (testng, junit5, aqute-bnd, etc.). This might be
the way forward for packagers who don't want their packages to be
broken but also don't want to / cannot maintain gradle and its
The exact time of the retirement will depend on the fedora schedule
and our available time, but it will probably happen just before the
F31 branch point, to make sure there's enough time before the F31 beta
freeze to fix any breakage.
I've talked about this at flock, you can look at my slides here (the
gradle issue is towards the end):
The talks are also all being recorded, but I don't know when the
videos will be available.
Fabio, for the Stewardship SIG
Good Morning Everyone,
As you may remember from  the CPE team has started categorizing its
applications into the following categories:
1. We maintain it, we run it
2. We don’t maintain it, we run it
3. We don’t maintain it, we don’t run it
4. We turn it off
In this process we picked the following four applications that we want
to move from the first category to the third:
* elections 
However, we do not want to throw code over the wall to anyone, so we’re
setting up something we called “A Friday with Infra”. The goal is to
help on-boarding anyone interested in picking up the maintenance of any
of these apps by taking time on Friday to work on these apps with them.
We have prepared a wiki page describing this proposal, how to get
involved in it as well as all the work we believe should be done to have
a smooth hand-over of the applications:
Let us know if you have any questions or (even better) want to be
involved with any of them :)
– On behalf of the CPE team
 elections has actually already found a new maintainer
The list of release-blocking deliverables for Fedora 31 is now
available. If there are any changes that should be made that were
part of an already-accepted Fedora 31 Change proposal, please let me
know. If an edit is required that was not part of an accepted Change
proposal, please file a FESCo ticket.
Please note that this is the first time we have used an
announcement-based model instead of a poll-based model for blockers as
approved by FESCo. I am open to your suggestions on timing and
format for this in future releases.
He / Him / His
Fedora Program Manager