[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

2020-02-25 Thread Stephen Gallagher
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

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

2020-02-25 Thread Troy Dawson
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

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

2020-02-25 Thread Stephen Gallagher
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

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

2020-02-25 Thread Matthew Miller
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

[EPEL-devel] Re: Proposed official change to EPEL guidelines: modules and RHEL

2020-02-25 Thread Matthew Miller
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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co

2020-02-25 Thread smooge
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

[EPEL-devel] Re: Haskell on EPEL 8

2020-02-25 Thread Mark Stopka
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

[EPEL-devel] Re: Haskell on EPEL 8

2020-02-25 Thread Jos Vos
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,

[EPEL-devel] Re: Haskell on EPEL 8

2020-02-25 Thread Stephen John Smoogen
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.

[EPEL-devel] Haskell on EPEL 8

2020-02-25 Thread Jos Vos
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

[EPEL-devel] Re: Looking for new maintainer: nagios, nagios-plugins, nrpe

2020-02-25 Thread Stephen John Smoogen
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