[EPEL-devel] Re: RHEL 8 Python 3.8 EOL
On Thu, May 18, 2023 at 3:17 AM Miro Hrončok wrote: > > Hello folks, > > just a heads up that according to > https://access.redhat.com/support/policy/updates/rhel-app-streams-life-cycle#rhel8_application_streams > the Python 3.8 application stream will be retired in May 2023 (I suppose at > the > end). Yes, at the end of May. For clarity, the content will still be available however it will no longer be updated or supported. Miro, do you have recommendations to the EPEL maintainers? E.g. Upgrade to python39/python3.11, or use the system-level python? josh > $ repoquery -q --repo=epel8 --whatrequires /usr/bin/python3.8 --whatrequires > 'python(abi) = 3.8' --whatrequires 'libpython3.8.so.1.0()(64bit)' | pkgname > git-revise > openscap-report > pagure-ev > pagure-milters > python38-click > python38-dateutil > python38-freezegun > python38-git-revise > python38-hvac > python38-hypothesis > python38-itsdangerous > python38-jmespath > python38-jsonschema > python38-ldap > python38-netaddr > python38-netaddr-shell > python38-ntlm-auth > python38-pyasn1 > python38-pyasn1-modules > python38-pynetbox > python38-pyrsistent > python38-pytest-runner > python38-radicale3 > python38-requests_ntlm > python38-setuptools_scm > python38-textfsm > python38-toml > python38-winrm > python38-xmltodict > radicale3 > > $ repoquery ... --source | pkgname > openscap-report > pagure > python-git-revise > python38-click-epel > python38-dateutil-epel > python38-freezegun-epel > python38-hvac > python38-hypothesis-epel > python38-itsdangerous-epel > python38-jmespath > python38-jsonschema-epel > python38-ldap-epel > python38-netaddr-epel > python38-ntlm-auth-epel > python38-pyasn1-epel > python38-pynetbox > python38-pyrsistent-epel > python38-pytest-runner-epel > python38-requests_ntlm-epel > python38-setuptools_scm-epel > python38-textfsm-epel > python38-toml-epel > python38-winrm-epel > python38-xmltodict-epel > radicale > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > ___ > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Ansible in EPEL 9
On Tue, May 9, 2023 at 11:24 PM Maxwell G wrote: > > Hello EPEL users and developers, > > > RHEL 9.2 was released today, > so I have updated ansible in EPEL 9 from 6.3.0 to 7.2.0 to match RHEL > 9.2's ansible-core bump from 2.13.3 to 2.14.2. > Each ansible major version is tied to a specific major version of > ansible-core, and we keep them in sync. > > Along with this change, RHEL 9.2 builds ansible-core for the python3.11 > stack instead of the default python3 (3.9) stack. > Therefore, ansible in EPEL now built for python3.11 as well. > > Here is the Bodhi update: > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f51a0ff8a1 > Please help test and give karma. Thank you for your efforts and clear communication! It is very much appreciated. josh > > Until this update is pushed to stable, you may receive an error like > this when running dnf upgrade > > ``` > Error: > Problem: package ansible-6.3.0-2.el9.noarch requires > python3.9dist(ansible-core) >= 2.13.3, but none of the providers can be > installed > - cannot install both ansible-core-2.14.2-4.el9.x86_64 and > ansible-core-2.13.3-2.el9_1.x86_64 > - cannot install both ansible-core-2.14.2-4.el9.x86_64 and > ansible-core-2.13.3-1.el9.x86_64 > - cannot install the best update candidate for package > ansible-core-2.13.3-2.el9_1.x86_64 > - cannot install the best update candidate for package > ansible-6.3.0-2.el9.noarch > (try to add '--allowerasing' to command line to replace conflicting packages > or '--skip-broken' to skip uninstallable packages or '--nobest' to use not > only best candidate packages) > ``` > > There are a couple potential solutions: > > 1. Run > $ dnf upgrade --exclude ansible-core >to skip ansible-core and upgrade everything else. > 2. In a couple hours from from now (now is 3:15 UTC), you'll be able to > install >ansible 7.2.0 from testing with > $ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core >and then run a plain `dnf upgrade` as usual. > > > -- > Happy automating, > > > Maxwell G (@gotmax23) > Pronouns: He/They > ___ > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Future of ClamAV on EPEL ?
On Tue, Mar 7, 2023 at 3:00 PM Andrew C Aitchison wrote: > > > This question is prompted by a question from kumar bava about EPEL7 > on the ClamaAV Users list: > https://lists.clamav.net/pipermail/clamav-users/2023-March/013338.html > > EPEL currently ship the anti-virus ClamAV v0.103.8 > > From September ClamAV 0.103 will be EOL, and all > supported versions will require Rust. > > Rust is available on RHEL 7, 8 and 9 as a part of Red Hat Developer Tools. Small clarification: Rust is available directly in RHEL 8 and 9, not as part of Red Hat Developer Tools. I mention it because it means the EPEL considerations are different in terms of buildroot availability and requirements. josh > Does that mean that EPEL will or will not be able to continue packaging > ClamAV ? > > ClamAV do provide rpms, so it may not be the end of the world if > ClamAV disappears from EPEL, but the details of the packing, > especially config locations and defaults may be different. > > Thanks, > > -- > Andrew C. Aitchison Kendal, UK > and...@aitchison.me.uk > ___ > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: gcc ee this bug on RHEL9 , How we reach RHEL team ?
On Tue, Jan 24, 2023 at 9:26 AM Troy Dawson wrote: > > Just so people don't need to go to the bug. > This has already been reported for RHEL 9. > https://bugzilla.redhat.com/show_bug.cgi?id=2140266 > > If I understand "Approved Release" correctly, the fix will come out in RHEL > 9.2 Most people can't see the field you're referencing. The bug is in VERIFIED state though, which means anyone should be able to test gcc in CentOS Stream 9 and confirm if it's fixed right now. josh ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: gcc bug on RHEL9 , How we reach RHEL team ?
On Tue, Jan 24, 2023 at 7:01 AM Sérgio Basto wrote: > > Hi, > Sorry, now subject is correct, the gcc have one patch for the error > above, that is seen on rhel 9 > > https://bugzilla.redhat.com/show_bug.cgi?id=1996330#c14 If you believe this is present in RHEL 9, please clone the bug to the Red Hat Enterprise Linux 9 bugzilla family. josh ___ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Tue, Jun 14, 2022 at 2:15 PM Mike Rochefort wrote: > > On Mon, Jun 13, 2022 at 4:18 PM Chris Adams wrote: > > > > Once upon a time, Josh Boyer said: > > > If the dependency is only needed at build time, which is what CRB > > > content is intended for > > > > If that's the intent, then it's not implemented correctly. For example, > > there are well over 100 perl modules in CRB 9. They may only be used > > _by Red Hat_ in building, but they are not exclusively build-time > > packages by a long shot. > > If it helps, I've updated my CRB scanner and the results (hopefully > it's accurate) for seeing what EPEL packages depend on CRB packages > (via "dnf rq --whatdepends ") for both EL8 and EL9. These > were run against RHEL 8 and 9 repositories with EPEL (so no EPEL > Next). I don't believe it'll catch everything (such as things in > epel-modular), but it could be a decent starting point for review. > Would also be useful to know if this methodology is flawed and > inaccurate. > > https://gitlab.com/omenos/crb-depends Not fully sure I understand the results, but this looks promising. Thanks for providing it! One thing I caught on initial glance, I think it's getting confused on multilib. For example, from: https://gitlab.com/omenos/crb-depends/-/blob/main/el9/FINAL_EPEL.json "gvfs.i686": [ "lutris-0:0.5.10.1-1.el9.x86_64" ], That seems to be highlighting that lutris.x86_64 depends on gvfs.i686. I don't think that's actually the case, because gvfs.x86_64 is shipped in AppStream and should satisfy the dependency for lutris.x86_64 in EPEL. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Mon, Jun 13, 2022, 4:17 PM Chris Adams wrote: > Once upon a time, Josh Boyer said: > > If the dependency is only needed at build time, which is what CRB > > content is intended for > > If that's the intent, then it's not implemented correctly. For example, > there are well over 100 perl modules in CRB 9. They may only be used > _by Red Hat_ in building, but they are not exclusively build-time > packages by a long shot. > I know. I'm actually looking at squaring this in one way or another, but whatever that results in doesn't change that content in CRB will have different considerations to take into account than other repos. The same has always been true of RHEL 7 Optional as well, so it's not a new dynamic. I also know most of those considerations don't matter to users or EPEL packagers, but I'm trying to avoid surprise in the long run. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Thoughts: epel-release auto-enable crb repo
On Sun, Jun 12, 2022 at 6:50 AM Sérgio Basto wrote: > > On Sun, 2022-06-05 at 00:54 +0200, Neal Gompa wrote: > > Let me start with examples that I get *regularly*: Pagure fails to > > install from EPEL on RHEL/CentOS/Alma/etc. because python3-markdown > > is > > not available. KDE Plasma fails to install because of a mass of > > missing dependencies. > > if epel use crb to build some package, crb should be enabled when we > install epel repo, yes , that is my opinion If the dependency is only needed at build time, which is what CRB content is intended for, then there is no reason to default to having CRB enabled because nothing will be installed from CRB anyway. The issue that people are running into is that EPEL packages have developed *runtime* dependencies on CRB content. For a subset of users, that is probably fine. However, if a package needs something at runtime it would be better to first inquire about putting that dependency in BaseOS or AppStream rather than just blindly using it from CRB. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term
On Fri, May 20, 2022 at 1:42 AM Thomas Stephen Lee wrote: > > The package I need is redhat-lsb-core. We have no plans to add redhat-lsb-core at this time. Most users are able to port their software to use the fields in /etc/os-release. josh > On Fri, May 20, 2022 at 1:57 AM Josh Boyer wrote: > > > > On Thu, May 19, 2022 at 4:11 PM Kevin Fenzi wrote: > > > > > > On Thu, May 19, 2022 at 07:37:46AM +0200, Branislav Náter wrote: > > > > Hi, > > > > > > > > On Thu, May 19, 2022 at 4:15 AM Thomas Stephen Lee > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I am trying to request a package for RHEL 9, but I cannot find RHEL > > > > > under Projects at issues.redhat.com. > > > > > What is the correct project for RHEL 9 ? > > > > > > > > > > > > > You have to file a bug for "distribution" component in Bugzilla. > > > > > > Please don't file it there. :) > > > > Small point of clarification. If you want to add a package to Red Hat > > Enterprise Linux 9 (the product), then you should likely open a > > support case via the Customer Portal and request it as an RFE. > > > > If you want to request a subpackage of an existing RHEL 9 package that > > is not included in RHEL, follow this and replace 8 with 9: > > https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages > > > > If you want to add a package to Extra Packages for Enterprise Linux 9 > > (the wonderful community project), then follow what Kevin says below. > > > > It really depends on the exact thing you are after. > > > > josh > > > > > > > Take a look at the handy doc: > > > > > > https://docs.fedoraproject.org/en-US/epel/epel-package-request/ > > > > > > If anything is unclear there, please do let us know. > > > > > > While RHEL may be moving to jira with RHEL10, EPEL is very likely to > > > stay with whatever Fedora is using (currently bugzilla). > > > > > > kevin > > > ___ > > > CentOS-devel mailing list > > > centos-de...@centos.org > > > https://lists.centos.org/mailman/listinfo/centos-devel > > > > ___ > > CentOS-devel mailing list > > centos-de...@centos.org > > https://lists.centos.org/mailman/listinfo/centos-devel > ___ > CentOS-devel mailing list > centos-de...@centos.org > https://lists.centos.org/mailman/listinfo/centos-devel ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term
On Thu, May 19, 2022 at 4:11 PM Kevin Fenzi wrote: > > On Thu, May 19, 2022 at 07:37:46AM +0200, Branislav Náter wrote: > > Hi, > > > > On Thu, May 19, 2022 at 4:15 AM Thomas Stephen Lee > > wrote: > > > > > Hi, > > > > > > I am trying to request a package for RHEL 9, but I cannot find RHEL > > > under Projects at issues.redhat.com. > > > What is the correct project for RHEL 9 ? > > > > > > > You have to file a bug for "distribution" component in Bugzilla. > > Please don't file it there. :) Small point of clarification. If you want to add a package to Red Hat Enterprise Linux 9 (the product), then you should likely open a support case via the Customer Portal and request it as an RFE. If you want to request a subpackage of an existing RHEL 9 package that is not included in RHEL, follow this and replace 8 with 9: https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages If you want to add a package to Extra Packages for Enterprise Linux 9 (the wonderful community project), then follow what Kevin says below. It really depends on the exact thing you are after. josh > Take a look at the handy doc: > > https://docs.fedoraproject.org/en-US/epel/epel-package-request/ > > If anything is unclear there, please do let us know. > > While RHEL may be moving to jira with RHEL10, EPEL is very likely to > stay with whatever Fedora is using (currently bugzilla). > > kevin > ___ > CentOS-devel mailing list > centos-de...@centos.org > https://lists.centos.org/mailman/listinfo/centos-devel ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Rhel 9 + Epel 9 - Amavis can't install
On Wed, May 18, 2022 at 6:21 AM Filip Bartmann wrote: > > Hello, > I try to install amavis in epel for RedHat 9 Stable: > > dnf install amavis > Updating Subscription Management repositories. > Last metadata expiration check: 0:02:16 ago on Wed 18 May 2022 12:16:52 PM > CEST. > Error: > Problem: conflicting requests > - nothing provides perl(Net::LibIDN) needed by amavis-2.12.2-3.el9.noarch > (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to > use not only best candidate packages) > It want's package Net::LibIDN, but it was not found. How can I install amavis > for RHEL 9? The perl-Net-LibIDN package will need to be built for EPEL 9. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-passlib for python38 module
On Mon, May 16, 2022 at 3:42 PM Leon Fauster via epel-devel wrote: > > Hi all, > > with the "upcoming" ansible-core migration, I wonder if its possible to > provide a python-passlib package (or stream) for the python38 > environment (ansible-core dependency). > > The current status: > > # rpm -q python3-passlib --requires |head -1 > python(abi) = 3.6 > > Whats the best approach. Upgrade the ABI compat or provide a module build? Modular build against the python38 module. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: RHEL 9 packages available in EPEL 9 (in different versions as well)
On Wed, May 4, 2022 at 4:00 PM Miro Hrončok wrote:
>
> On 04. 05. 22 15:40, Troy Dawson wrote:
> > I just want to make sure that you are querying RHEL 9.0 and not 9.1.
>
> Well, I was querying 9.1, so you have a point. However, with 9.0 it is almost
> the same:
>
> $ comm -12 <(repoquery -q
> --repo=RHEL9.0-{BaseOS,AppStream,CRB,HighAvailability} -a | pkgname | sort |
> uniq ) <(repoquery -q --repo=epel9 -a | pkgname | sort | uniq)
>
> libwmf
> libwmf-lite
> pybind11-devel
> python3-pybind11
> tesseract
> tesseract-devel
> tesseract-langpack-eng
> tesseract-tessdata-doc
>
> $ comm -12 <(repoquery -q
> --repo=RHEL9.0-{BaseOS,AppStream,CRB,HighAvailability}-source -a | pkgname |
> sort | uniq ) <(repoquery -q --repo=epel9-source -a | pkgname | sort | uniq)
>
> libwmf
> pybind11
> tesseract
> tesseract-tessdata
>
>
> The only difference I can spot is anthy-unicode-devel and
> double-conversion-devel, which apparently might be allowed in EPEL 9 for now.
Both of those were requested and added in the last month
(anthy-unicode-devel just this week). That should be reflected in
CentOS Stream 9 now(ish) and a future version of RHEL 9 at some point.
josh
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: [CentOS-devel] KDE ready for testing in RHEL9Beta / CentOS Stream 9
On Tue, Mar 22, 2022 at 11:01 AM Simon Matter wrote: > > Hi Troy and all, > > > For those of you who want to use KDE on RHEL9 Beta, or CentOS Stream 9, it > > is available via EPEL. It is currently plasma 5.23.5, kf5 5.90.0, qt5 > > 5.15.2. There might be an update before RHEL 9.0 is released. > > This is something I may want to try as I'm not happy with GNOME and I > can't use it with our nx-libs based remote desktop solution. > > Since you mention both RHEL9 Beta and CentOS Stream 9 a question comes up > and I don't remember if this has already been discussed: > > Consider I'm running CentOS Stream 9 on a host and RHEL9 is being > released, will there be a clean way to move a CentOS Stream 9 system over > to RHEL9? Not in a supported manner. > Will/should it be possible to use dnf distro-sync for this? It may be possible, but Red Hat recommends fresh installation for Red Hat Enterprise Linux systems. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: RHEL moving to issues.redhat.com only long term
On Mon, Mar 14, 2022 at 2:59 PM Dan Čermák wrote: > > Hi Adam, > > Adam Williamson writes: > > > snip > > > That could obviously have pretty significant consequences for Fedora. > > Bugzilla isn't only an issue tracker for Fedora; we run some > > significant processes through it, notably the Change process, the > > blocker/FE bug process, and the prioritized bug process. In A World > > Without Bugzilla all of those would need adapting (and their > > documentation updating). There's fairly tight integration between Bodhi > > and Bugzilla, which would need to be redesigned. Those are just things > > I can think of off the top of my head. There are also a couple of > > decades worth of internet links to Fedora issues on RH Bugzilla, of > > course. > > > > I guess the two big choices for Fedora if RH said "we're not > > maintaining Bugzilla any more" would be 1) take over maintaining > > Bugzilla or 2) switch to something else. 1) would probably be the path > > of least resistance, I guess. > > Short term it is the path of the least resistance, but at least what > I've heard from $dayjob, maintaining a Bugzilla instance is no easy > task, as they are often customized (via non-upstream patches) and this > all needs to be maintained. I cannot speak for our infra team, but I > really don't know if they'd like yet another huge service, because this > effectively means they'd have to take over maintenance of > bugzilla.redhat.com... > > > > > This does also kinda lead to a larger question for me, trying to wear > > both Red Hat and Fedora hats at the same time[0]. I wonder if we're > > kind of lacking a...mechanism, for want of a better word, to handle the > > *generic* case here. Let's rewind to Ye Olde Days, when "the Fedora > > project" first started. At that point Fedora and Red Hat shared a lot > > of tooling and infrastructure, and this was useful to both sides in > > many ways; it saves on development costs and it makes it easy for > > people to work in both worlds. With my Red Hat on, I think I'm allowed > > to say that internally we often talk about this being desirable - > > having consistency between how X is done in Fedora and how it's done > > for RHEL - and it obviously has benefits to Fedora too (it means we > > don't have to find the resources to do that same work at Fedora level). > > > > However, situations like this make me wonder if we might have an issue > > with keeping shared infra/tooling where it's desirable. It seems like > > this is a decision/conversation that's been happening within RH, about > > what makes sense for RH in terms of RHEL development. AFAIK this is the > > first time it's been formally talked about in a Fedora context, and the > > messaging is "RH has already decided to stop using Bugzilla for RHEL > > after 9". In other words, RH has decided on its own to move away from > > something that is part of the shared RH/Fedora "heritage way of doing > > things". > > > > I'm not saying that's wrong, but as I said it does make me wonder > > whether, if both sides do find shared tooling/approaches beneficial, we > > might want to approach this kind of potential change differently in > > future. Otherwise it does seem like we could sort of gradually drift > > apart, with no explicit intention to do so, and lose the benefits of > > shared tooling and process. Unless the ultimate outcome of this is > > "Fedora adopts issues.redhat.com for bug tracking" - which would be a > > possibility, but doesn't seem like a certainty - the result will be > > that we go from having a shared bug tracker, with the benefits of > > shared maintenance and being able to easily clone or reference bugs > > between Fedora and RHEL, to each maintaining our own bug tracker and > > not having those benefits. > > > > Of course, there would be sensitivities in developing such a process - > > it could look a lot like Red Hat telling Fedora how to do stuff, which > > I think isn't exactly the relationship we want to have. But at the same > > time I'm not sure "Red Hat or Fedora just deciding unilaterally to stop > > using this thing they'd previously both used" is always the best choice > > either. > > No, certainly not. I think it would have been nice if the tooling > discussion happened before RH decided to drop Bugzilla so that we can > all use a common tooling. However, I also know that in a business RHEL is choosing not to use Bugzilla for future versions of RHEL. I need to be clear in wording there, because Red Hat is a company, RHEL is one of its products, and we're only talking about newer versions of that product. I am not aware of any plans for Red Hat to drop Bugzilla. I am aware of plans for newer versions of RHEL to no longer use Bugzilla. > sometimes reaching such a consensus is everything but easy. It would > have been nice if someone at least tried though. Tried what, to be precise? If you mean try to find common tooling between Fedora and RHEL, well we have off and on for years.
[EPEL-devel] Re: RHEL moving to issues.redhat.com only long term
On Mon, Mar 14, 2022 at 11:12 AM Adam Williamson wrote: > > On Mon, 2022-03-07 at 12:44 -0500, Josh Boyer wrote: > > Hi Fedora, CentOS, and EPEL Communities! > > > > As part of our continued 3 year major Red Hat Enterprise Linux release > > cadence, RHEL 9 development is starting to wrap up with the spring > > 2022 release coming soon. That means planning for the next release > > will start in earnest in the very near future. As some of you may > > know, Red Hat has been using both Bugzilla and Jira via > > issues.redhat.com for RHEL development for several years. Our > > intention is to move to using issues.redhat.com only for the major > > RHEL releases after RHEL 9. > > > > What does this mean for Fedora and CentOS? This discussion is in part > > to figure that out. Based on some very brief analysis, the following > > should hold: > > > > - RHEL customers should continue to file support cases through the Red > > Hat Customer portal, which will remain consistent regardless of the > > backend tooling used. > > > > - There is no imminent retirement of the Red Hat Bugzilla instance > > being planned at this time. RHEL 7, 8, and 9 will continue to use > > bugzilla in some form and RHEL 9 has a very long lifecycle. > > > > - Fedora Linux and EPEL have their own Bugzilla product families and > > are not directly impacted in their own workflows by the choice to use > > only issues.redhat.com for RHEL. > > - There will be impacts on existing documentation that provide > > guidance on requesting things from RHEL in various places like EPEL. > > We will be happy to help adjust these. > > > > - CentOS Stream contribution and bug reporting workflows will be > > adjusted to use issues.redhat.com instead of bugzilla in the relevant > > places. This should apply to all versions of CentOS Stream for a > > unified contributor workflow. This will happen gradually as we > > discover the best workflow to use. > > > > If there are other impacts that you can think of, please raise them on > > this thread. We’d like to ensure we’re covering as much as possible > > as this rolls out. > > So if I'm understanding this correctly, the ultimate consequence here > is "Red Hat Bugzilla might go away, or stop being maintained, at > whatever point it's no longer needed for RHEL 9", right? I have no idea, to be honest. There's a lot of assumption in that statement and it certainly could be an outcome, but I'm not aware of any plans towards that directly. > That could obviously have pretty significant consequences for Fedora. > Bugzilla isn't only an issue tracker for Fedora; we run some > significant processes through it, notably the Change process, the > blocker/FE bug process, and the prioritized bug process. In A World > Without Bugzilla all of those would need adapting (and their > documentation updating). There's fairly tight integration between Bodhi > and Bugzilla, which would need to be redesigned. Those are just things > I can think of off the top of my head. There are also a couple of > decades worth of internet links to Fedora issues on RH Bugzilla, of > course. Those all sound like the things I'm familiar with. > I guess the two big choices for Fedora if RH said "we're not > maintaining Bugzilla any more" would be 1) take over maintaining > Bugzilla or 2) switch to something else. 1) would probably be the path > of least resistance, I guess. > > This does also kinda lead to a larger question for me, trying to wear > both Red Hat and Fedora hats at the same time[0]. I wonder if we're > kind of lacking a...mechanism, for want of a better word, to handle the > *generic* case here. Let's rewind to Ye Olde Days, when "the Fedora > project" first started. At that point Fedora and Red Hat shared a lot > of tooling and infrastructure, and this was useful to both sides in > many ways; it saves on development costs and it makes it easy for > people to work in both worlds. With my Red Hat on, I think I'm allowed > to say that internally we often talk about this being desirable - > having consistency between how X is done in Fedora and how it's done > for RHEL - and it obviously has benefits to Fedora too (it means we > don't have to find the resources to do that same work at Fedora level). Fedora and RHEL process and tooling has deviated significantly over the years. So much so that by the time I joined the RHEL team, it was already very different. That was almost 5 years ago, which means the individual decisions that led to it were even earlier. I don't really want to revisit those decisions because I wasn't around and can't speak to why they were
[EPEL-devel] Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term
On Wed, Mar 9, 2022 at 5:05 PM Davide Cavalca via CentOS-devel wrote: > > On Mon, 2022-03-07 at 12:44 -0500, Josh Boyer wrote: > > Hi Fedora, CentOS, and EPEL Communities! > > > > As part of our continued 3 year major Red Hat Enterprise Linux > > release > > cadence, RHEL 9 development is starting to wrap up with the spring > > 2022 release coming soon. That means planning for the next release > > will start in earnest in the very near future. As some of you may > > know, Red Hat has been using both Bugzilla and Jira via > > issues.redhat.com for RHEL development for several years. Our > > intention is to move to using issues.redhat.com only for the major > > RHEL releases after RHEL 9. > > Thanks for sharing this Josh. Would you be able to expand on why Red > Hat chose to use Jira specifically here, and what benefits do you > forsee this switch will bring to CentOS down the road? Red Hat has long used Jira in various parts of the company, with JBoss and other products being heavy users for quite some time. Within the past few years we've consolidated a number of different instances into the single issues.redhat.com instance. That has enabled us to more easily plan and coordinate across our product portfolio. RHEL's decision is certainly informed by that same overall direction, but also specifically influenced by the limiting factors of using multiple tools to accomplish similar things. We've been using Bugzilla since Red Hat Linux days, and while it has served us well as a defect tracking backend, it was never designed to handle the complexity we have for planning and coordinating the varying scope of work we have. Aligning to a single tool will help us refine our processes internally. As for benefits to CentOS, or any of the other upstream projects we interact with, we'll have to see. I think the intention is to minimize overall impact to start with, and then evolve our workflows to bring further benefit where we can. That being said, we are certainly aware that we need to default to open issues to allow us to collaborate directly in the open source manner we've long held to be fundamental to our communities. I expect that approach to behave very similarly to how Bugzilla is used today. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] RHEL moving to issues.redhat.com only long term
Hi Fedora, CentOS, and EPEL Communities! As part of our continued 3 year major Red Hat Enterprise Linux release cadence, RHEL 9 development is starting to wrap up with the spring 2022 release coming soon. That means planning for the next release will start in earnest in the very near future. As some of you may know, Red Hat has been using both Bugzilla and Jira via issues.redhat.com for RHEL development for several years. Our intention is to move to using issues.redhat.com only for the major RHEL releases after RHEL 9. What does this mean for Fedora and CentOS? This discussion is in part to figure that out. Based on some very brief analysis, the following should hold: - RHEL customers should continue to file support cases through the Red Hat Customer portal, which will remain consistent regardless of the backend tooling used. - There is no imminent retirement of the Red Hat Bugzilla instance being planned at this time. RHEL 7, 8, and 9 will continue to use bugzilla in some form and RHEL 9 has a very long lifecycle. - Fedora Linux and EPEL have their own Bugzilla product families and are not directly impacted in their own workflows by the choice to use only issues.redhat.com for RHEL. - There will be impacts on existing documentation that provide guidance on requesting things from RHEL in various places like EPEL. We will be happy to help adjust these. - CentOS Stream contribution and bug reporting workflows will be adjusted to use issues.redhat.com instead of bugzilla in the relevant places. This should apply to all versions of CentOS Stream for a unified contributor workflow. This will happen gradually as we discover the best workflow to use. If there are other impacts that you can think of, please raise them on this thread. We’d like to ensure we’re covering as much as possible as this rolls out. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Missing RHEL 9 buildroot packages in EPEL 9 buildroot
On Thu, Mar 3, 2022 at 12:27 PM Richard W.M. Jones wrote: > > On Wed, Mar 02, 2022 at 09:04:04AM -0500, Neal Gompa wrote: > > So why not have the OCaml toolchain exposed in RHEL CRB? It sounds > > like it would be very beneficial to have it there. > > It's a good question. I think we chose not to do that simply because > we were worried about handling CVEs in a timely way and general > support (I'm not sure if CRB is officially supported or not, but there > may be some "implicit" support if we're shipping stuff). I would not > be opposed to it though. This requires a Customer Portal account https://access.redhat.com/solutions/4180391 The CRB repo is documented heavily internally as well. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Missing RHEL 9 buildroot packages in EPEL 9 buildroot
On Tue, Mar 1, 2022 at 8:45 AM Stephen John Smoogen wrote:
>
>
>
> On Tue, 1 Mar 2022 at 08:19, Richard W.M. Jones wrote:
>>
>> On Tue, Mar 01, 2022 at 04:21:56AM -0500, Neal Gompa wrote:
>> > On Tue, Mar 1, 2022 at 3:07 AM Richard W.M. Jones
>> > wrote:
>> > >
>> > >
>> > > https://bugzilla.redhat.com/show_bug.cgi?id=2058274
>> > >
>> > > fails to build with:
>> > >
>> > > DEBUG util.py:444: No matching package to install: 'ocaml-dune >= 1.0'
>> > >
>> > > This package is in RHEL 9 buildroot (ocaml-dune-2.8.5-5.el9.x86_64).
>> > >
>> > > I read an earlier thread ("Subject: [EPEL-devel] Re: Packages
>> > > disappearing from the EPEL 9 buildroot") and it seems to indicate that
>> > > RHEL 9 buildroot packages aren't going to be available in EPEL 9.
>> > > This seems crazy, is it really correct?
>> > >
>> >
>> > It's not crazy. EPEL is intended to build on RHEL content, which means
>> > we can't depend on something RHEL doesn't publish. If Red Hat wants to
>> > publish their buildroot repo, then sure, we could use it.
>>
>> I wasn't very clear, but I was addressing my remark at Red Hat.
>> There's really no reason why we (Red Hat) don't publish buildroot, in
>> fact my personal view is we ought to for open source reasons.
>>
>
> I do not think you will find much disagreement here.. but after 3+ years of
> saying it and nothing changing, many of us have made our peace.
To be a bit more fair, we have not blindly added all buildroot content
to RHEL. However, we have made progress on coming up with a way to
request these packages be added and worked to help teams internally
understand the implications of this. We continue to add content to
every RHEL minor release.
That's not nothing. It's just not everything.
josh
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: The incredibly shrinking RHEL
On Sat, Jan 15, 2022 at 1:29 PM Orion Poplawski wrote: > > On 1/14/22 05:02, Josh Boyer wrote: > > On Fri, Jan 14, 2022 at 5:31 AM Miro Hrončok wrote: > >> > >> On 14. 01. 22 5:11, Orion Poplawski wrote: > >>> While working on EPEL9, it seems that even more packages are missing from > >>> RHEL9 > >>> than were in RHEL8. The latest I found was cppunit, which appears to be > >>> completely missing from the CS9 repos despite having been built (See > >>> https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and > >>> presumably in the CS9/RHEL9 buildroot. > >>> > >>> So I scraped some screens from pkgs.org: > >>> > >>> Stream 9: > >>> > >>> CentOS AppStream Official x86_64 8882 > >>> CentOS BaseOS Official x86_64 2357 > >>> CentOS CRB Official x86_64 1856 > >>> > >>> Stream 8: > >>> > >>> CentOS AppStream Official x86_64 15008 > >>> CentOS BaseOS Official x86_64 6721 > >>> CentOS PowerTools Official x86_64 3771 > >>> > >>> That's a pretty big difference. Now, I don't know how many were dropped > >>> completely and how many are of the "buildroot only" variety. But I > >>> suspect > >>> there is a fair amount of the latter and so a lot of make-work ahead of > >>> us for > >>> EPEL9. > > > > A fairly accurate list of packages removed in RHEL 9 can be found in > > our RHEL 9 Adoption documentation: > > > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages > > Thanks for that. > > >>> Packaging for EPEL9 is starting to feel more and more like cleaning the > >>> Augean > >>> stables with RedHat piling up more manure. > >> > >> If there is any Python stuff that's in Buildroot only, let me know and > >> I'll do > >> my best to persuade the maintainers to move it to CRB (but my powers are > >> limited). > > > > I will politely point out two things. > > > > 1) The entirety of the RHEL buildroot is available in the CentOS > > Stream koji buildroots. I know the EPEL stewards have qualms about > > using it, but they are there and the technical hurdles to consume them > > are not large. > > Well, we are making use of it via epel-next. But it's the "Stream" > buildroot. Once that diverges from the current released RHEL there > could be issues with trying to do updated builds for the current release > of RHEL. "...could be issues...". Yes, I agree it is possible to have issues. I do not believe the number that may be found is large enough to cripple EPEL or cause the community to have to request dozens of -devel packages be added to product repos just to build things. It is my hope that EPEL-next proves this out and EPEL proper can benefit from it in a similar manner. I can appreciate the caution the EPEL community is taking. > > 2) Moving content to CRB in RHEL is not a silver bullet solution in > > many scenarios. If it's strictly for build dependencies, CRB works > > well. If an EPEL package has a runtime requires on CRB content, that > > is less desirable. RHEL CodeReady Linux Builder (CRB) content is > > unsupported, not enabled by default, and not intended to be used at > > runtime in production. EPEL itself is clearly in the same unsupported > > category, but requiring another unsupported repo at runtime may lead > > to unintentional surprises for many users. > > > > josh > > I don't buy any of these arguments, and it doesn't really address the > situation of "missing -devel" packages. E.g. utf8proc - it's in I'm sorry, I did not mean to intend an argumentative tone. What I wrote is a factual statement from a product perspective, based on feedback we've heard directly from some customers. It's ok for you to not share the same view, of course. Feedback from some of our other customers highlights they don't share it either. > "AppStream" - so it's presumably "supported" and "intended to be used at > runtime in production". But without the -devel package available we > can't build anything in EPEL that uses it. So we have to go through > contortions to make sure we build the proper version of utf8proc-devel > and keep it in sync with RHEL. This is difficult to describe, both in approach and in actual customer facing documentation, even though we try. Conte
[EPEL-devel] Re: The incredibly shrinking RHEL
On Fri, Jan 14, 2022 at 5:31 AM Miro Hrončok wrote: > > On 14. 01. 22 5:11, Orion Poplawski wrote: > > While working on EPEL9, it seems that even more packages are missing from > > RHEL9 > > than were in RHEL8. The latest I found was cppunit, which appears to be > > completely missing from the CS9 repos despite having been built (See > > https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and > > presumably in the CS9/RHEL9 buildroot. > > > > So I scraped some screens from pkgs.org: > > > > Stream 9: > > > > CentOS AppStream Official x86_64 8882 > > CentOS BaseOS Official x86_64 2357 > > CentOS CRB Official x86_64 1856 > > > > Stream 8: > > > > CentOS AppStream Official x86_64 15008 > > CentOS BaseOS Official x86_64 6721 > > CentOS PowerTools Official x86_64 3771 > > > > That's a pretty big difference. Now, I don't know how many were dropped > > completely and how many are of the "buildroot only" variety. But I suspect > > there is a fair amount of the latter and so a lot of make-work ahead of us > > for > > EPEL9. A fairly accurate list of packages removed in RHEL 9 can be found in our RHEL 9 Adoption documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages > > Packaging for EPEL9 is starting to feel more and more like cleaning the > > Augean > > stables with RedHat piling up more manure. > > If there is any Python stuff that's in Buildroot only, let me know and I'll do > my best to persuade the maintainers to move it to CRB (but my powers are > limited). I will politely point out two things. 1) The entirety of the RHEL buildroot is available in the CentOS Stream koji buildroots. I know the EPEL stewards have qualms about using it, but they are there and the technical hurdles to consume them are not large. 2) Moving content to CRB in RHEL is not a silver bullet solution in many scenarios. If it's strictly for build dependencies, CRB works well. If an EPEL package has a runtime requires on CRB content, that is less desirable. RHEL CodeReady Linux Builder (CRB) content is unsupported, not enabled by default, and not intended to be used at runtime in production. EPEL itself is clearly in the same unsupported category, but requiring another unsupported repo at runtime may lead to unintentional surprises for many users. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: EPEL9 Rollout Proposals
On Thu, Dec 2, 2021 at 4:29 PM Leon Fauster via epel-devel wrote: > > Am 02.12.21 um 19:49 schrieb Carl George: > > On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson wrote: > >> > >> In our last EPEL Steering Committee meeting, Carl brought up a new > >> proposal for our epel9 / epel9-next rollout. Sometimes IRC isn't the best > >> way to explain things like that, it got a little confusing. Carl and I > >> had a good video chat to clean up confusion and talk about some pros and > >> cons of the various proposals. > >> Here are the three proposals. > >> > >> * PLAN A > >> Plan A is basically what we've been working towards for the past couple of > >> months. > >> - launch epel9-next now-ish (ideally aligned with c9s launch promotion) > >> - After RHEL9 goes GA > >> -- perform a mass branch and mass rebuild to populate epel9 > >> -- launch epel9 after RHEL9 GA is launched. > >> > >> ** Plan A Pros: > >> - epel9-next and epel9 are only set up once, and not changed > >> - ready to go now > >> > >> ** Plan A Cons: > >> - complexity and added work of mass branch and mass rebuild > >> - mass rebuild will have a moderate rate of failure due to buildroot > >> differences (unshipped devel packages) > >> - epel9 not available at rhel9 ga > >> - confusing messaging to packagers: > >> -- target epel9-next for ~6 months > >> -- after epel9 exists target that instead, only use epel9-next when needed > >> - confusing messaging to users: > >> -- use epel9-next now for c9s and rhel9 beta > >> -- use epel9-next temporarily at rhel9 launch but don’t leave it enabled > >> -- use epel9 primarily once it exists > >> > >> > >> * PLAN B > >> - epel9-next stays the way it is currently setup. > >> - Setup epel9 using RHEL9 Beta for the buildroot. > >> -- Pull in any errata as it comes. > >> -- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB > >> - Launch epel9 and epel9-next together (In 1-2 weeks). > >> - When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to > >> RHEL9 GA > >> > >> ** Plan B Pros: > >> - simple messaging to packagers: > >> -- epel9 is the primary target, use epel9-next only when needed (same as > >> epel8-next) > >> - simple messaging to users: > >> -- use epel9 everywhere (epel-next-release is a recommends on c9s) > >> - no mass branching > >> - no mass rebuild > >> - No confusion from using the full CentOS Stream buildroot > >> -- epel9 buildroot will only have AppStream, BaseOS and CRB > >> > >> ** Plan B Cons: > >> - potential for large divergence between rhel9 beta and ga > >> - changing our messaging right before the launch > >> > >> > >> * PLAN C > >> - epel9-next stays the way it is currently setup. > >> - setup up epel9 using c9s for the buildroot > >> -- Use the repos you would for RHEL9: AppStream, BaseOS, CRB > >> - freeze epel9 buildroot before c9s switches to 9.1 content > >> - launch epel9 and epel9-next together (1-2 weeks) > >> - switch epel9 buildroot from frozen c9s to rhel9 ga later > >> > >> ** Plan C Pros: > >> - simple messaging to packagers: > >> -- epel9 is the primary target, use epel9-next only when needed (same as > >> epel8-next) > >> - simple messaging to users: > >> -- use epel9 everywhere (epel-next-release is a recommends on c9s) > >> - no mass branching > >> - no mass rebuild > >> - No confusion from using the full CentOS Stream buildroot > >> -- epel9 buildroot will only have AppStream, BaseOS and CRB > >> > >> ** Plan C Cons: > >> - potential infrastructure complexity of freezing the epel9 buildroot > >> - changing our messaging right before the launch > >> > >> > >> Please let us know what you think. > >> If we do choose to go with Plan B or C we will need to make the decision > >> fairly quickly. > >> > >> Troy > > > > Closing the loop here, at the 2021-11-24 EPEL Steering Committee > > meeting we voted and selected plan C. > > > > https://meetbot.fedoraproject.org/teams/epel/epel.2021-11-24-21.00.html > > > > We are in the process of finishing up the EPEL9 implementation and > > plan to launch EPEL9 and EPEL9 Next together with a formal > > announcement very soon. Until then you may notice parts of that > > implementation coming online (repositories, release packages, etc.) > > but we recommend waiting until the announcement for official > > instructions. > > > > > That sounds nice! Just curious - what indicates the switch to 9.1 > content? Any sample point(s) that indicates such "branch"? There are none. C9S is a continuously delivered distribution which RHEL is derived from. Equivalency to distinct RHEL minor releases at point-in-time intervals isn't something that Stream does. In talking with Carl directly, he was using this as shorthand for instituting a freeze of the EPEL buildroot in preparation of solidifying it for a RHEL GA. RHEL's release cadence is publicly documented, so my understanding is that the EPEL team will do some of their own projections from the spring/fall RHEL release cadence (typically May and Nov) and work
[EPEL-devel] Re: python-gevent and pytest-cov in el9
On Fri, Sep 24, 2021 at 4:09 PM Neal Gompa wrote: > > On Fri, Sep 24, 2021 at 4:03 PM Josh Boyer wrote: > > > > On Fri, Sep 24, 2021 at 4:02 PM Neal Gompa wrote: > > > > > > On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer wrote: > > > > > > > > On Fri, Sep 24, 2021 at 3:46 PM Ken Dreyer > > > > wrote: > > > > > > > > > > Hi folks, > > > > > > > > > > The RHEL 9 composes do not have libev-devel and libuv-devel, so we > > > > > cannot build python-gevent on EPEL 9 easily. > > > > > > > > https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm > > > > > > > > You could request libev-devel in the composes. I remain confused why > > > > it has to be in the compose though, because libev and it's devel > > > > package are accessible in the CentOS Stream 9 buildroots today. > > > > > > > > > > We can't use them in EPEL if they're not in CRB. > > > > Yes, that's what everyone keeps telling me. I don't understand why. > > > > Well, because outside of RHEL, everyone wants remote and local builds > to have access to the same resources and not crush the servers. Since > buildroot stuff isn't going out on the mirror network (otherwise, why > would it be separate from CRB?), it's obvious we shouldn't rely on it > for packages that people should expect to be able to build and rebuild > for RHEL. So you have access to what you want, you have a way to pull it down and get it locally, but you can't depend on it because... you're worried a multi-billion dollar company can't pay it's server and CDN bills? As to why it's separate from CRB, that's because CRB is a reflection of what is provided as part of the product. It's that simple. > And again, by Red Hat's own sword (policy), RHEL doesn't want to ship > everything needed to build stuff, so if EPEL is intended to provide > the requisite community guarantees (reproducibly buildable), we have > to work with what RHEL gives us. I think that is also EPEL falling on EPEL's own sword a bit. I think it fails to recognize that building and distributing software can be separate things. I can see the need for a developer community to be able to build, update, and rebuild software it distributes. Access to the buildroots facilitates this. We could even point mock configs at it, or propose a buildroot repo for it if people are really worried about "servers". However, in the context of something like python-gevent, an EPEL *end user* isn't going to want libuv-devel or libev-devel to be installed on their system at runtime. They have no need for it to be available in a compose. They only need python-gevent and the requisite runtime libraries, which are already provided. I think separating the personas and thinking about the requirements for each might be worth doing. I understand this is a different approach and something that looks different from the past. It's been 2+ years since the OS EPEL8 is based on has shipped and it is taking a different approach than previous releases. Every indication we have shows the next major version will continue this. I'm worried that sticking with past policies precludes EPEL from making progress on a project that we all want to see succeed. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-gevent and pytest-cov in el9
On Fri, Sep 24, 2021 at 4:02 PM Neal Gompa wrote: > > On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer wrote: > > > > On Fri, Sep 24, 2021 at 3:46 PM Ken Dreyer wrote: > > > > > > Hi folks, > > > > > > The RHEL 9 composes do not have libev-devel and libuv-devel, so we > > > cannot build python-gevent on EPEL 9 easily. > > > > https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm > > > > You could request libev-devel in the composes. I remain confused why > > it has to be in the compose though, because libev and it's devel > > package are accessible in the CentOS Stream 9 buildroots today. > > > > We can't use them in EPEL if they're not in CRB. Yes, that's what everyone keeps telling me. I don't understand why. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: python-gevent and pytest-cov in el9
On Fri, Sep 24, 2021 at 3:46 PM Ken Dreyer wrote: > > Hi folks, > > The RHEL 9 composes do not have libev-devel and libuv-devel, so we > cannot build python-gevent on EPEL 9 easily. https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm You could request libev-devel in the composes. I remain confused why it has to be in the compose though, because libev and it's devel package are accessible in the CentOS Stream 9 buildroots today. josh > (It's possible to package the missing -devel packages separately, and > I've been doing this by automatically following the NVR changes in > Stream 9's Koji for several weeks with scripts at > https://github.com/ktdreyer/ceph-el9. My conclusion is that it is so > painful that it's not sustainable to do this for years.) > > This means that python-pytest-cov and python-pytest-xdist won't be > available on epel9, since those require gevent. > > Several Python packages require python-pytest-cov because upstream > lists it in requirements.txt or tests-requirements.txt. I think we > should just patch these out in Fedora. Even apart from RHEL's > restrictions, it's not a good use of resources to run pytest-cov when > no one reviews coverage reports in the Koji logs, and we'll speed up > builds when mock doesn't have to install this spurious BuildRequires. > > Here are a list of packages where I've removed pytest-cov: > > https://src.fedoraproject.org/rpms/python-watchdog/pull-request/4 > https://src.fedoraproject.org/rpms/python-cheroot/pull-request/15 > https://src.fedoraproject.org/rpms/python-portend/pull-request/5 > https://src.fedoraproject.org/rpms/python-typing-extensions/pull-request/3 > > - Ken > ___ > 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 > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: ansible-core-2.11.x in CentOS stream 9
On Thu, Sep 16, 2021 at 10:10 AM Leon Fauster wrote: > > On 16.09.21 14:22, Josh Boyer wrote: > > On Wed, Sep 15, 2021 at 3:48 PM Kevin Fenzi wrote: > >> > >> Just a heads up that ansible-core (the engine part of ansible) is now in > >> CentOS stream 9: > >> > >> https://gitlab.com/redhat/centos-stream/rpms/ansible-core > >> > >> Note that this is the engine, you will likely want to install > >> collections for modules and roles, etc. > > > > For those that might not have followed how Ansible has been > > refactored, take a look at > > https://www.ansible.com/blog/ansible-3.0.0-qa > > > > ansible-core is the lowest level of the ansible stack and does not > > include many of the modules and plugins that those using ansible > > engine (ansible-2.9) might be used to. As Kevin said, you will almost > > certainly need additional modules/plugins not provided by > > ansible-core. > > > Out of curiosity > > Does CS9 provide additional (sub)packages to extend the functionality? Not generally. ansible-core has been added to CS9 in support of System Roles only. This is analogous to how ansible is made available in RHEL 8. System Roles will include the modules/plugins it needs to manage the various areas of the OS, but they are not general purpose ansible packages. > Right now EPEL8 provide the the full stack based on ansible 2.9. > > Will EPEL9 provide such packages to provide additional modules/plugins? > > And more a ansible question: Does ansible3 provide a dependencies > manager as consequence now? I'll leave these for Kevin or someone else to answer in terms of EPEL 9 plans. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: ansible-core-2.11.x in CentOS stream 9
On Wed, Sep 15, 2021 at 3:48 PM Kevin Fenzi wrote: > > Just a heads up that ansible-core (the engine part of ansible) is now in > CentOS stream 9: > > https://gitlab.com/redhat/centos-stream/rpms/ansible-core > > Note that this is the engine, you will likely want to install > collections for modules and roles, etc. For those that might not have followed how Ansible has been refactored, take a look at https://www.ansible.com/blog/ansible-3.0.0-qa ansible-core is the lowest level of the ansible stack and does not include many of the modules and plugins that those using ansible engine (ansible-2.9) might be used to. As Kevin said, you will almost certainly need additional modules/plugins not provided by ansible-core. josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: modular bugzilla components
On Tue, Aug 24, 2021 at 9:22 AM Troy Dawson wrote: > > > > On Mon, Aug 23, 2021 at 6:41 PM Orion Poplawski wrote: >> >> The "zabbix" package exists in EPEL8 in two forms: >> >> zabbix40 - non-module 4.0 package. >> zabbix - module with 5.0 stream. >> >> Because the "zabbix" dist-git does not have a epel8 branch, there is no >> "zabbix" component in bugzilla for EPEL8. Should I create an epel8 >> branch but then retire it just to create a bugzilla component? Or >> something else? > > > My opinion, yes. > This does two things. > 1 - creates an EPEL zabbix bugzilla component > 2 - creates a dead.package file in the dist-git branch, that if people read, > will point them to the right place. > > But that is my opinion. If others know of a good way to get a bugzilla > component in, there might be better ways. That seems rather complicated. Perhaps Ben could just add the component to the EPEL product in bugzilla directly. Ben, can you do this via the Program Management interfaces? josh ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[EPEL-devel] Re: Requesting missing devel packages: How to request one be put in RHEL 8 CRB
On Thu, Jun 24, 2021 at 4:32 PM Troy Dawson wrote: > > During our last round of proposals for solutions to missing devel packages, > it was noted that EPEL and CentOS has very different documentation for > requesting a package be put into RHEL 8.[1][2] > > I am betting that CentOS's documentation is correct. It was written after > ours. > > When I was talking to the Red Hat people who know, it was noted that Red Hat > has much better communication with the Fedora and CentOS communities than the > EPEL community.[3] They wanted to start fixing that communication gap, and > figured this would be a good way to start. So I'm asking Josh Boyer to > answer this question on behalf of Red Hat. Thanks, Troy! > > How would Red Hat like us, EPEL maintainers and developers, to request > missing devel packages? (devel packages that are built at the same time as a > released library in RHEL8, but not released in RHEL8. Such as lmdb-devel) The process as documented on the CentOS wiki page is the best route. Filing a bug against the package in the Red Hat Enterprise Linux product family with the CentOS Stream version set will ensure that both the team maintaining the package in RHEL and some from the CentOS Stream team are looped in. Getting the request in front of the owning RHEL team is key, as they will need to evaluate the request and consider the implications of providing the devel package. I would like to make sure and clarify that this is the best approach for devel packages from SRPMs that are already part of RHEL. Completely new package requests for things that are not in RHEL at all are RFEs that should likely come through a case filed in the Customer Portal for those that have a valid subscription. > If we follow Red Hat's procedure, what are the odds that the package will > make it into RHEL 8 CRB? This one is harder to answer in a general sense. I don't want to be misleading, so I won't give odds because it will vary depending on the package. I'll certainly say the odds are better if the requests are made than if they aren't :) We have grown the CRB content set by over 100 packages since the initial RHEL 8.0 release, and continue to add packages even today. I'd like to also describe some of the considerations at play as we work on this. Essentially, the team that owns the package will evaluate the request to ensure it's consistent with the manner in which the package is intended to be used as part of RHEL. Often enabling other software to build against a RHEL package, particularly for things like EPEL enablement, is a perfectly valid use case. Once a valid use case has been established the team will ensure they can meet any obligations required by adding it as part of the RHEL product and sign off. After the team has agreed, the package will first appear in CentOS Stream PowerTools (or occasionally AppStream), and then in a future RHEL minor release. At times, we have included a library or package as an internal implementation detail and do not encourage wider use of that package for other software. This is a relatively rare case. I can only think of one stand-out package that comes to mind thus far. If it does happen the team may decide not to provide the devel package. Filing the request is often the best way to begin that dialog. This helps us understand how a package is being used and take that into consideration for future RHEL releases, and also allows discussion and suggestions for alternative packages that may be more suitable in the long term. I'm sure there are many that would simply like all subpackages of all SRPMs to be shipped, however that is not the approach RHEL is taking from a product perspective. Blanket requests for everything are not likely to go far. It's simply not actionable at the same level as targeted requests. As an aside, I am particularly encouraged to see EPEL-Next come to fruition and combined with CentOS Stream and the broader set of packages available in that project buildroot I think there is a lot of potential to grow the overall ecosystem. I believe EPEL has discussed this recently with some hesitation, but I would encourage you to consider if and how EPEL-Next and CentOS Stream might be leveraged to help EPEL proper as well. From what I've seen, this community is amazing and I think there are opportunities there. Thanks again Troy, for giving me the opportunity to interact with the EPEL community. This is quite overdue. josh > > Thanks > Troy Dawson > > [1] - > https://fedoraproject.org/wiki/EPEL/FAQ#RHEL_8.2B_has_binaries_in_the_release.2C_but_is_missing_some_corresponding_-devel_package._How_do_I_build_a_package_that_needs_that_missing_-devel_package.3F > [2] - https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages > [3] - Yes, I write my emails here from my redhat email address, but I do not > represent Red Hat in my EPEL capacities. _
