[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL
On Tue, Feb 25, 2020 at 5:05 PM Troy Dawson wrote: ... > While I agree that we should be very careful with this, I do not > believe it should be completely off the table. > I believe it should be permissible with the EPEL Steering Council's > blessing, but not otherwise. > Case in point is libssh2. > It was provided in the original RHEL 8.0 virt module, but not since > then. It's causing all sorts of grief, especially when people are > using both RHEL8 (where you see it) and CentOS8 (where do you don't). > There is a bugzilla ticket in with the team, but it looks like it's > going to take a while before a fix get's implemented. > My proposal is to create a libssh2 module, with a higher NEVR than in > that original RHEL8 module. > OK, I hadn't considered that aspect and I agree with you. Under *carefully controlled and approved circumstances*, we can permit updating a package from a different module. ___ 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: Proposed official change to EPEL guidelines: modules and RHEL
On Tue, Feb 25, 2020 at 1:16 PM Stephen Gallagher wrote: > > On Tue, Feb 25, 2020 at 3:57 PM Matthew Miller > wrote: > > > > On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote: > > > Consider: > > > > > > 1. foo rpm that is in the RHEL baseos. It's not in any module. > > > Can epel make a foo (non default) module that overrides it? > > > > > This is safe from a technical perspective and should be fully endorsed by > EPEL. > I agree > > > 2. foo rpm that is in a RHEL default module. > > > Can epel make a foo (non default) module that overrides it? > > > > > > 3. foo rpm that is in a RHEL non default module. > > > Can epel make a foo (non default) module that overrides it? > > > 2 and 3 are safe from a technical perspective with one major caveat: > they can only be replaced by an alternate stream of *the same module*. > This is because otherwise both RPMs will be visible to the package > manager and the behavior is complicated. I'm actually not sure which > way it will break; either both sets of RPMs will be visible to the > transaction and you'll end up with the highest NEVRA, regardless of > which one you intended to get; or both modules will suppress each > other and neither of their RPMs will be available. I think it's the > first case, but either way it should be avoided. > I recently talked with the software support group (I think that's their new name) asking about this, and it is the first. If two modules are both enabled, even if one is default and the other not, and the same package is in both, dnf will pick the highest NEVRA. While I agree that we should be very careful with this, I do not believe it should be completely off the table. I believe it should be permissible with the EPEL Steering Council's blessing, but not otherwise. Case in point is libssh2. It was provided in the original RHEL 8.0 virt module, but not since then. It's causing all sorts of grief, especially when people are using both RHEL8 (where you see it) and CentOS8 (where do you don't). There is a bugzilla ticket in with the team, but it looks like it's going to take a while before a fix get's implemented. My proposal is to create a libssh2 module, with a higher NEVR than in that original RHEL8 module. > This is also why we (Merlin and I) determined that the `epel-` prefix > was a non-starter; this case makes that too risky. > > If we want to find a way to highlight where a stream is coming from to > disambiguate EPEL streams from RHEL streams, I think we need to do > some UX work on `dnf module list` to display the source repo for each > available stream in a meaningful way. > > > Lastly, I think Petr Pisar is pretty much spot-on with his explanation > of the EPEL -> RHEL transition; we need to make sure that the > V(ersion) field in the module stream's NSVCA is higher for the new > RHEL version than it is in EPEL, similar to what we do with > non-modular packages today. In that case, DNF will just select the > RHEL version of the stream as an update to the EPEL version of the > stream and things should work out fine. The "gotcha" is those cases > where the EPEL maintainer doesn't know that a RHEL update is coming > and inadvertently updates to a higher version than RHEL ends up > delivering. As this case is basically identical to the non-modular RPM > case, the same mitigation strategies should work (either drop the > conflicting module contents from the repo or else release a higher > version in RHEL as an errata). > ___ > 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 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: Proposed official change to EPEL guidelines: modules and RHEL
On Tue, Feb 25, 2020 at 3:57 PM Matthew Miller wrote: > > On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote: > > Consider: > > > > 1. foo rpm that is in the RHEL baseos. It's not in any module. > > Can epel make a foo (non default) module that overrides it? > > This is safe from a technical perspective and should be fully endorsed by EPEL. > > 2. foo rpm that is in a RHEL default module. > > Can epel make a foo (non default) module that overrides it? > > > > 3. foo rpm that is in a RHEL non default module. > > Can epel make a foo (non default) module that overrides it? 2 and 3 are safe from a technical perspective with one major caveat: they can only be replaced by an alternate stream of *the same module*. This is because otherwise both RPMs will be visible to the package manager and the behavior is complicated. I'm actually not sure which way it will break; either both sets of RPMs will be visible to the transaction and you'll end up with the highest NEVRA, regardless of which one you intended to get; or both modules will suppress each other and neither of their RPMs will be available. I think it's the first case, but either way it should be avoided. This is also why we (Merlin and I) determined that the `epel-` prefix was a non-starter; this case makes that too risky. If we want to find a way to highlight where a stream is coming from to disambiguate EPEL streams from RHEL streams, I think we need to do some UX work on `dnf module list` to display the source repo for each available stream in a meaningful way. Lastly, I think Petr Pisar is pretty much spot-on with his explanation of the EPEL -> RHEL transition; we need to make sure that the V(ersion) field in the module stream's NSVCA is higher for the new RHEL version than it is in EPEL, similar to what we do with non-modular packages today. In that case, DNF will just select the RHEL version of the stream as an update to the EPEL version of the stream and things should work out fine. The "gotcha" is those cases where the EPEL maintainer doesn't know that a RHEL update is coming and inadvertently updates to a higher version than RHEL ends up delivering. As this case is basically identical to the non-modular RPM case, the same mitigation strategies should work (either drop the conflicting module contents from the repo or else release a higher version in RHEL as an errata). ___ 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: Proposed official change to EPEL guidelines: modules and RHEL
On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote: > Consider: > > 1. foo rpm that is in the RHEL baseos. It's not in any module. > Can epel make a foo (non default) module that overrides it? > > 2. foo rpm that is in a RHEL default module. > Can epel make a foo (non default) module that overrides it? > > 3. foo rpm that is in a RHEL non default module. > Can epel make a foo (non default) module that overrides it? > > I think we all agree 3 is fine. > I think 2 could cause problems, but perhaps it would work. > I would think 1 would be fine also. These should all be fine. In the case of 2, it's just now another alternate non-default stream. It would only override if explicitly asked for. -- Matthew Miller Fedora Project Leader ___ 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: Proposed official change to EPEL guidelines: modules and RHEL
On Tue, Feb 18, 2020 at 05:09:04PM +0100, Petr Pisar wrote: > So the bottom line is: Prefixed streams should provide a bullet proof > mitigation. Until DNF gains the ability to obsolete a stream, there will be > slight risk of creeping out-dated EPEL content into the installation. A prefix also makes it immediately obvious that a stream is EPEL and not product or supported. -- Matthew Miller Fedora Project Leader ___ 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] [Fedocal] Reminder meeting : EPEL Steering Co
Dear all, You are kindly invited to the meeting: EPEL Steering Co on 2020-02-26 from 18:00:00 to 19:00:00 GMT At freenode@fedora-meeting The meeting will be about: This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #meetingname EPEL #topic Intros #topic Old Business #topic EPEL-6 #topic EPEL-7 #topic EPEL-8 #topic Openfloor #endmeeting Source: https://apps.fedoraproject.org/calendar/meeting/9672/ ___ 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: Haskell on EPEL 8
I've subscribed to the bug report, but I've also spoke with Jens Petersen on IRC and he said it will be available rather soon =) -- Best regards / S pozdravem, BSc. Mark Stopka, BBA mobile: +420 704 373 561 On Tue, Feb 25, 2020 at 3:26 PM Jos Vos wrote: > On Tue, Feb 25, 2020 at 08:56:52AM -0500, Stephen John Smoogen wrote: > > > [...] If you need a set of packages, go to https://bugzilla.redhat.com > > and check to see if there are outstanding bug tickets requesting a > > maintainer to support it in EPEL-8. If there are add your info to that > > ticket, if there are not please open a ticket. > > There wasn't one AFAICS, so I opened one: > https://bugzilla.redhat.com/show_bug.cgi?id=1807043 > > -- > --Jos Vos > --X/OS Experts in Open Systems BV | Office: +31 20 6938364 > --Amsterdam, The Netherlands| Mobile: +31 6 26216181 > ___ > 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 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: Haskell on EPEL 8
On Tue, Feb 25, 2020 at 08:56:52AM -0500, Stephen John Smoogen wrote: > [...] If you need a set of packages, go to https://bugzilla.redhat.com > and check to see if there are outstanding bug tickets requesting a > maintainer to support it in EPEL-8. If there are add your info to that > ticket, if there are not please open a ticket. There wasn't one AFAICS, so I opened one: https://bugzilla.redhat.com/show_bug.cgi?id=1807043 -- --Jos Vos --X/OS Experts in Open Systems BV | Office: +31 20 6938364 --Amsterdam, The Netherlands| Mobile: +31 6 26216181 ___ 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: Haskell on EPEL 8
On Tue, 25 Feb 2020 at 08:53, Jos Vos wrote: > Hi, > > Is there a specific reason why the Haskell platform is not available > anymore in EPEL 8 (it was in EPEL 7)? Any ongoing work known to > eventually support it again? > > We do not automatically branch everything from one release to another. We have found that trying doing so pisses off a lot of the volunteer maintainers who are doing EPEL in their spare time and don't want added work they didn't sign up for. Packages are put into a release when a volunteer maintainer knows that the package is wanted, and they have time to do so. If you need a set of packages, go to https://bugzilla.redhat.com and check to see if there are outstanding bug tickets requesting a maintainer to support it in EPEL-8. If there are add your info to that ticket, if there are not please open a ticket. > Thanks, > > -- > --Jos Vos > --X/OS Experts in Open Systems BV | Office: +31 20 6938364 > --Amsterdam, The Netherlands| Mobile: +31 6 26216181 > ___ > 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] Haskell on EPEL 8
Hi, Is there a specific reason why the Haskell platform is not available anymore in EPEL 8 (it was in EPEL 7)? Any ongoing work known to eventually support it again? Thanks, -- --Jos Vos --X/OS Experts in Open Systems BV | Office: +31 20 6938364 --Amsterdam, The Netherlands| Mobile: +31 6 26216181 ___ 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: Looking for new maintainer: nagios, nagios-plugins, nrpe
On Mon, 24 Feb 2020 at 18:31, Eduardo Kienetz wrote: > > It would be my first time maintaining an EPEL package, but if nobody else > already experienced is willing, I could probably do it with minimal > supervision/hints to get started :) > What has been the typical work? If they have git repos I can probably get a > good understanding from the commits. > Hi Eduardo. I was going to add you to the group, but you are not a packager so I could not. You can look at the package and its outstanding bugs in bugzilla and look through the spec file to see if it is something you can take on later when you become a packager. -- 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
