[EPEL-devel] Re: Announcing EPEL-8.0 Release
On Thu, 22 Aug 2019 at 03:54, Paul Howarth wrote: > > Hi, > > On Wed, 14 Aug 2019 10:50:24 -0400 > Stephen John Smoogen wrote: > > ## 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. > > Will this present a problem going forward when modules are available in > EPEL-8 and it's possible to build for both perl-5.24 and perl-5.26? > No it is not currently possible. perl-5.24 is not a default so anything depending on 5.24 needs to be also a module. > i.e. will the presence of non-modular perl packages built against 5.26 > cause any issues for people wanting to use the perl-5.24 module? > Those should all get uninstalled if you switch to perl-5.24 > Maybe if the perl modules become buildable at a point release, all the > perl packages could be removed from the main EPEL-8 repo at that time > and moved into modules? > That will be up to a maintainer doing so. EPEL as I have been reminded constantly in the last year is a community and not a product. If the maintainers have no interest in modules.. then modules aren't going to happen. If the maintainers do, then modules will happen. If the maintainers can't agree on making modules happen or not.. we will end up with a repeat of the Fedora java problems. In the end, it will be people problems versus technology problems. > Apologies if this is a stupid question but modularity is still > something of an unknown to me. > You and me both :). > Paul. > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org -- Stephen J Smoogen. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Announcing EPEL-8.0 Release
Hi, On Wed, 14 Aug 2019 10:50:24 -0400 Stephen John Smoogen wrote: > ## 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. Will this present a problem going forward when modules are available in EPEL-8 and it's possible to build for both perl-5.24 and perl-5.26? i.e. will the presence of non-modular perl packages built against 5.26 cause any issues for people wanting to use the perl-5.24 module? Maybe if the perl modules become buildable at a point release, all the perl packages could be removed from the main EPEL-8 repo at that time and moved into modules? Apologies if this is a stupid question but modularity is still something of an unknown to me. Paul. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Announcing EPEL-8.0 Release
On Fri, 16 Aug 2019 at 08:12, Miroslav Suchý wrote: > > Dne 14. 08. 19 v 16:50 Stephen John Smoogen napsal(a): > > 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 > > > > ## Known Issues: > > Can someone please update: > https://fedoraproject.org/wiki/EPEL > > Thanks.. I missed putting this on a checklist. I will do so now. > -- > Miroslav Suchy, RHCA > Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Announcing EPEL-8.0 Release
Dne 14. 08. 19 v 16:50 Stephen John Smoogen napsal(a): > 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 > > ## Known Issues: Can someone please update: https://fedoraproject.org/wiki/EPEL -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Announcing EPEL-8.0 Release
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-de...@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.
Announcing EPEL-8.0 Release
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-de...@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.
[EPEL-devel] Announcing EPEL-8.0 Release
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@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.
