epel-announce August 2019

epel-announce@lists.fedoraproject.org

2 participants
4 discussions

Please test python3X-chardet
by Orion Poplawski 22 Aug '19

22 Aug '19

I've submitted python3X-chardet to epel-testing: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-25334ee372 If you use this, please test that is doesn't break anything. -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 https://www.nwra.com/

1 0

Announcing EPEL-8.0 Release
by Stephen John Smoogen 14 Aug '19

14 Aug '19

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 s390x platforms. ## 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 target=epel8. 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 time. 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 https://bugzilla.redhat.com/show_bug.cgi?id=1719830 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 it. 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 code. 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 BuildRequires: systemd 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: ``` #!/usr/bin/sh # Reminder to get an updated pagure token for releng tickets # Usage: epel-8.sh package1 package2 package3 package4 if [ $# -lt 1 ] then echo "At least one package name should be provided" else TMPDIR=`mktemp -d /tmp/epel8.XXXXXX` pushd "$TMPDIR" for pkg in "$@" do fedpkg clone "$pkg" pushd "$pkg" fedpkg request-branch epel8 fedpkg request-branch epel8-playground popd done rm -rfv "$TMPDIR" fi ``` 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 * libblueray-devel * liba52-devel * libXvMC-devel * libdvdnav-devel * gfbgraph-devel * libuv-devel * rest-devel * qgpgme-devel ## Definitions * 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 better managed. -- Stephen J Smoogen.

1 0

EPEL-8 appearing on dl.fedoraproject.org (not an announcement)
by Stephen John Smoogen 01 Aug '19

01 Aug '19

So I was hoping that I would have 24 hours to finish writing my announcements.. but I found out that mirrormanager works better than I thought. Packages for an initial EPEL-8.0 are beginning to appear on the mirrors. That said they are in the 'I have built these and need people to test things' stage versus the 'please put these in your production environment stage'. We will hopefully have things fully tested and ready by FLOCK next week. -- Stephen J Smoogen.

1 0

EPEL-8 package requests are now open
by Stephen John Smoogen 01 Aug '19

01 Aug '19

I would like to thank everyone for their patience and for the people who have put in a lot of work to get us to where we can start building packages. The following is a general outline of what we have for packaging procedures for EPEL-8. The master document is currently at https://hackmd.io/@ssmoogen/B1p2QM-eS It will be stored with other EPEL documents shortly. # EPEL-8 Packaging Procedures ## Introduction When a new Red Hat Enterprise Linux occurs, one of the steps to get EPEL going for it is branching of various packages into new namespace. The EPEL Steering Committee does not mass branch all existing packages into the namespace because it has caused multiple problems: 1. The package maintainers did not want to support the package in the newer version of EPEL. Package maintainers may only want to support certain versions of Enterprise Linux or may want to wait until their favourite derivative appears. 2. The package does not work in the latest version of RHEL. With multiple years between releases, software which worked on Fedora 18 which would branch to EPEL-7 may not exist anymore with Fedora 28 and EPEL-8 would need a completely different version. ## Consumer request for packages People who are interested in getting packages into EPEL should contact the package maintainer through [bugzilla](https://bugzilla.redhat.com/). This allows for the requests to be tracked and if the primary maintainer is not interested in branching to EPEL, other ones can step in and do so. ## EPEL Playground We have added an additional set of channels for EPEL-8 called playground. It is meant to be sort of like Fedora Rawhide so that packagers can work on versions of software which are too fast moving or will have large API changes from what they are putting in the regular channel. To try and make this transparent, we have made it so 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 2 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 ```target= epel8 ```. Packages in epel8-playground are primarily to be used in the following manner: * To test out some new version of the package that might not be stable yet. * To test out some new packaging of the package * To test a major version change of the package that they want to land at the next epel8 minor release. * To build a package that will never be stable enough for epel8, 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 epel8 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 also you want to make sure it’s panned out, so you can test before hand in playground. Consumers should be aware that packages in EPEL8-playground are there without any Service Level Expectations. You may want to only cherry pick packages from there as needed. ## Developer request for branching multiple packages 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: ``` #!/usr/bin/sh # Reminder to get an updated pagure token for releng tickets # Usage: epel-8.sh foo bar goo blah blech if [ $# -lt 1 ] then echo "At least one package name should be provided" else TMPDIR=`mktemp -d /tmp/epel8.XXXXXX` pushd "$TMPDIR" for pkg in "$@" do fedpkg clone "$pkg" pushd "$pkg" fedpkg request-branch epel8 fedpkg request-branch epel8-playground popd done rm -rfv "$TMPDIR" fi ``` Releng will then work through the tickets in the system which is adding branches to the PDC and src.fedoraproject.org. ## Known Issues 1. /usr/bin/python does not exist. Choose ``/usr/bin/python3`` or ``/usr/bin/python2`` and patch appropriately. 2. ``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. 3. 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. 4. ``systemd-rpm-macros`` is not a separate packages. If needed, used ``BuildRequires: systemd`` 5. While EL-8 comes with platform-python, it should NOT be used in ``Requires:`` unless absolutely neccessary. python3 should be used instead. (Exceptions can be made but will be rare and need justification.) **Accepted Exceptions:** * Use python3.6dist(coverage) instead of python3-coverage. This package is not shipped but is needed in %check code. 6. 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 only suggest one choice: * Choose not to have the python2 part of your package and patch whatever to use python3. 7. 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. 8. While a RHEL src.rpm might produce a -devel package, it may not currently be in the build repository. 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. After modularity is enabled, changes to what is done will be needed. 9. EPEL-8.0 may not work with the RHEL-8.1 beta. There seem to be changes in dnf and zchunk which we have not worked out. This line will be updated. 10. 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. ## Definitions 1. 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. 2. Consumer. A person who has subscribed to EPEL for packages but is not a maintainer. 3. PDC. Product Definition Center. A tool to help list the lifetime and permissions that a product has so that branching and updates can be better managed. -- Stephen J Smoogen.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

epel-announce August 2019