[EPEL-devel] Re: Requesting branches for epel9

2021-12-14 Thread Matthew Miller
On Tue, Dec 14, 2021 at 06:31:04AM -0500, Stephen John Smoogen wrote:
> > Where is that checklist? I found
> I don't know myself.

Fair -- a lot of this stuff is individual experience and wisdom that we
haven't recorded, but need to.


> > But it seems like "request an EPEL branch" should generally be either "Okay!
> > Doing that automatically now" or "Oh, this is in EL, sorry"*. What are the
> > other cases?
> 
> As far as I know this isn't about requesting EPEL branches, as much as
> requesting any branches by hand. If I add something to Fedora rawhide
> and then ask for a F34 branch, the same issues can happen. Remember
> our build infrastructure is a pile of band-aids on top of duct tape on
> top of bungee cords. Lots of tools are written for a toolchain which
> existed years ago and have been hacked to make it work with whatever
> new initiative that comes into play. 'Unexpected' side effects and
> corner cases happen all the time and the fixing of them tends to add
> new ones.

Sure. But also, asking people to spend a lot of their time running
grunt-work tasks means that they have less time to fix when things break,
let alone re-engineer away some of that tech debt. It seems like we should
be able to automate the simple cases (adding F34 and F35 branches should be
even easier, since we don't have the "is it in EL?" question even).

-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[EPEL-devel] Re: Requesting branches for epel9

2021-12-13 Thread Matthew Miller
On Mon, Dec 13, 2021 at 09:40:19AM -0500, Stephen John Smoogen wrote:
> It is a fairly manual process where a person volunteers to sit in
> front of the firehose every day and deal with these requests. The
> person who has to process them has a checklist of policy items they
> have to confirm/check to make sure the branch is possible.

Where is that checklist? I found
https://docs.pagure.org/releng/sop_process_dist_git_requests.html, but it
refers to a tool which is deprecated in favor of another one, at
https://pagure.io/fedscm-admin/, but none of those places have a clear
articulation of the policy items.

I get human sanity check of new package requests is good, although really
ideally I would hope that wouldn't fall to the rel-eng/scm firehose
volunteers.

But it seems like "request an EPEL branch" should generally be either "Okay!
Doing that automatically now" or "Oh, this is in EL, sorry"*. What are the
other cases?


* I'm very sad that this isn't "So, would you like to do it anyway, and then
  make a module?", but c'est la vie
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed

2021-11-29 Thread Matthew Miller
On Mon, Nov 29, 2021 at 07:00:30AM -0500, Neal Gompa wrote:
> If Fedora and EPEL were to have older versions, we'd have to have a
> dedicated CDN endpoint for them, because mirrors would seriously have
> trouble taking it.

How often would such packages be used? If we had a non-default repo
available but not enabled by default, it could be optional to mirror and
probably still be okay.

-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed

2021-11-25 Thread Matthew Miller
On Thu, Nov 25, 2021 at 05:20:00PM +0100, Leon Fauster wrote:
> >I mean, seriously, RH should make this easy for Fedora packagers.
> 
> +1
> and COPR and mock packagers in general.

Yes, but _I_ only have one lever. :)


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[EPEL-devel] Re: Mock/Copr default epel-8-* configuration to be changed

2021-11-25 Thread Matthew Miller
On Mon, Nov 22, 2021 at 03:10:58PM +0100, Miro Hrončok wrote:
> >- builds will require a valid Red Hat subscription (the no-cost variant is
> >   OK as well, though [2])
> 
> I cannot help myself but I consider this very unpleasant for EPEL packagers.
> 
> Getting and configuring the subscription was always so unfriendly
> for me that I've been using EPEL mocks even for my RHEL work. This
> basically means using EPEL mocks will once again be as complicated
> as using RHEL.

I'm not opposed to working with our friends over at Alma on this, but I
think we _also_ should fix this. Would it help if we made it easy to add a
RHEL developer entitlement (the 16 no-cost RHEL license thing) to a Fedora
Account (perhaps with a check-box agreement in the account system, like the
FPCA), and made it trivial in mock use that?

I mean, seriously, RH should make this easy for Fedora packagers.



-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[EPEL-devel] Re: DNF replacement in EL 9?

2021-11-17 Thread Matthew Miller
On Wed, Nov 17, 2021 at 01:43:59PM -0500, Josh Boyer wrote:
> Further RHEL 9 documentation will center around the 'dnf' moniker,
> eventually transitioning away from yum.

Thus completing my long, slow loss of this argument. :)

Oh well! dnf it is!

-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[EPEL-devel] Re: What about future EPEL for Centos ?

2021-06-07 Thread Matthew Miller
On Mon, Jun 07, 2021 at 01:51:36PM +, john tatt wrote:
> I mean: will Epel follow Centos Stream and in this case not surely be 
> compatible with RHEL 8 ?, or

Troy answered the overall questions separately, but... in practice, I expect
this to be a very small issue. How often has it been that RHEL minor updates
have required EPEL packages to be rebuilt, or EPEL packages built on the
latest to not install on older point-releases of RHEL? I'm sure it happens
occasionally, but it's not the typical case.


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[EPEL-devel] Re: Becoming maintainer for pdsh for EPEL - unresponsive maintainer

2021-06-03 Thread Matthew Miller
On Wed, Jun 02, 2021 at 01:42:23PM -0700, Troy Dawson wrote:
> EPEL Packages have a modified version of the non-responsive package
> maintainer.
> https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Stalled_EPEL_Requests
> 
> This is for stalled requests, which is a bit different than non-responsive
> package maintainers. Fedora package maintainers don't have to do anything
> with EPEL if they don't want to, thus we needed it to be a bit different.

Thanks for the correction, Troy. I'll remember this for the next time!

-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[EPEL-devel] Re: Becoming maintainer for pdsh for EPEL - unresponsive maintainer

2021-06-01 Thread Matthew Miller
On Tue, Jun 01, 2021 at 08:29:17AM -0400, Trey Dockendorf wrote:
> I have opened a bugzilla to get an EPEL8 branch for pdsh [1], and I've also
> reached out to the current maintainers directly and have not heard anything
> back.  I am not sure what the next steps are in getting an EPEL8 build of
> pdsh.  I would be happy to become the maintainer of the EPEL builds for
> pdsh.


If reaching out to them directly isn't getting results, there is the
non-responsive maintainer process:
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/#steps


-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


[EPEL-devel] Re: EPEL whats version of RHEL will follow

2021-02-03 Thread Matthew Miller
On Wed, Feb 03, 2021 at 11:14:38AM +, john tatt wrote:
> So if I understand well, an EPEL package could be have to be desinstalled 
> just because an update in Stream make it not compatible any more ?

All changes landing in Stream are already approved to land in a RHEL minor
release. So this is no different from what happens with the status quo when
an update happens in a RHEL minor release which requires an EPEL package
change. 


-- 
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: EPEL9 - thoughts and timings

2021-01-28 Thread Matthew Miller
On Thu, Jan 28, 2021 at 03:05:16PM -0800, Troy Dawson wrote:
> epel8-next is getting closer and closer to being in place.
> To me it seems logical to create a epel9-next, pointing at the CentOS
> 9 Stream (when it comes).  It would need the same setting up as
> epel8-next, all the steps would be the same other than the name and
> where it points for it's repo.

Makes sense to me!


-- 
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: Epel 8 (and 9) build against what?

2020-12-15 Thread Matthew Miller
On Tue, Dec 15, 2020 at 02:36:40PM -0700, Jeff Sheltren wrote:
> Is nobody concerned with the implications (or irony?) of building an open
> source project on top of a proprietary platform?

I assume you mean RHEL. RHEL is not a proprietary platform — it's silly to
call it that. Look at Rocky Linux and CloudLinux. And, you know, the Oracle
one. And Amazon Linux. And all of the source code is 100% available.

But also, ironic or not, EPEL is already built on RHEL.


-- 
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: Epel 8 (and 9) build against what?

2020-12-15 Thread Matthew Miller
On Tue, Dec 15, 2020 at 05:43:28PM +0100, Pavel Raiskup wrote:
> Notable problem if we switched from CentOS to RHEL in Mock configuration
> is that several build dependencies will be missing.  RHEL 8 doesn't e.g.
> ship e.g. the *-devel packages (this problem, if I understand it correctly,
> is slowly worked-around by CentOS-only packages).

As I understand it, these are available as part of "CodeReady Linux Builder"
with the developer subscription.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/package_manifest/codereadylinuxbuilder-repository



-- 
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: Epel 8 (and 9) build against what?

2020-12-15 Thread Matthew Miller
On Tue, Dec 15, 2020 at 08:30:21AM -0500, Stephen John Smoogen wrote:
> Honestly I don't know how to deal with regular EPEL-8 development after
> this. EPEL is going to add an epel-next which they would ask for additional
> targets in mock for. However that does not fix building against the regular
> EPEL-8 target. I expect it will depend on what programs come up for
> development in the coming year and if the new -devel RHEL UBI images can be
> used for mock.

Or just the no-cost RHEL developer subscription? It seems like this is a
good use case for that, if it could be made easy enough that it isn't
painful for EPEL packagers.


-- 
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: Fast-moving packages in EPEL

2020-10-11 Thread Matthew Miller
On Sun, Oct 11, 2020 at 02:05:20PM +0200, Christopher Engelhard wrote:
> I'm sort of hesitant to dive into learning how modularity works, though
> ... although, maybe a good opportunity to learn.

The spin-up is a little rougher than we'd hoped, but once you've got it set
up it shouldn't be too much extra work. This does seem like a good use case
for it!

-- 
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: proposal: EPEL 8 Next

2020-09-09 Thread Matthew Miller
On Wed, Sep 09, 2020 at 10:25:50AM -0400, Stephen John Smoogen wrote:
> 1. There is always a complaint that Red Hat related projects jump onto a
> single name to the point of overuse. Atomic, -Shift, -Stack, and a couple
> others have been ones in just recent memory. Participants in the various
> communities feel usually railroaded to use a brand even if they don't think
> it wise.

Yes, that's a problem. In this case, though, it really *is* directly
related.

> 2.EPEL has a hard enough time getting Fedora contributions with various
> community members seeing it as a useless diversion. Putting Stream in the
> title will just add to the 'why isn't EPEL just in CentOS already so I
> don't have to look at those ugly named branches in MY package'.

So, the distinction is: EPEL is in Fedora because it's direct community
ownership and maintenance. CentOS Stream is explicitly Red Hat controlled
with a "patches appreciated!" approach. It's valuable to have both, but I
also like the clarity of the separation.

This all leads me to think that actually what we want is not "EPEL Stream"
but "EPEL for Stream". (epel-for-stream? epel-4-stream? epel4s? no not that
last one for sure.)


-- 
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: proposal: EPEL 8 Next

2020-09-09 Thread Matthew Miller
On Wed, Sep 09, 2020 at 06:30:08AM -0700, Troy Dawson wrote:
> Very good question, one I asked in the meeting.
> If I got the argument right, then the amount of red-tape / legal work
> it would take to call it epel-stream would be much higher than we want
> to pay.
> Many of us didn't like the name "Stream" to begin with since it is
> sooo overloaded.

I'm also ... eyerolly ... about the Stream name, but it's the one we've got,
and I think it makes a LOT of sense for this to be aligned. It'll be so much
easer for users to actually find and understand than anything else I can
think of. So I'm willing to tackle the red tape and legal work if
that's the blocker.

-- 
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: Reminder: EPEL Steering Committee meeting moved to Fridays

2020-03-10 Thread Matthew Miller
On Tue, Mar 10, 2020 at 09:09:11AM -0700, Troy Dawson wrote:
> Just a reminder that the EPEL Steering Committee meeting has been
> moved to Fridays at 2100 UTC.
> 
> To find out when that is for you, do
> date -d "Fri 2100 UTC"
> 
> A reminder should be sent out the day before.

Hi Troy. Can you let me know if the modular-versions proposal is on an
upcoming agenda?

-- 
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

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 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

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 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] Re: Proposed official change to EPEL guidelines: modules and RHEL

2020-02-15 Thread Matthew Miller
On Fri, Feb 14, 2020 at 03:04:17PM -0800, Kevin Fenzi wrote:
> This is what I was trying to get to in the thread recently about
> libssh2. However it's still not entirely clear to me. 
> 
> Does this mean if there's a package foo that is a rhel package, but not
> in a module, that it can be overlapped with a foo package thats in a
> epel non default module? ie, does it only mean the modular case or does
> it mean any rpm?

I don't understand the last sentence. To the first question: yes, and that
non-default module package will only get installed if the module is
explicitly enabled.



-- 
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

2020-02-15 Thread Matthew Miller
On Fri, Feb 14, 2020 at 05:14:31PM -0600, Chris Adams wrote:
> As a consumer of EPEL, I'd rather nothing in the base RHEL (or really
> CentOS in my case) ever get replaced, up or downgrade, by something in
> EPEL.

Nothing in EPEL would by default, but you could explicitly chose to. This
would be like enabling a Copr or other repo which happens to override, but
more integrated.

> Unless... does RHEL have modules that replace base packages?  I admit, I
> haven't fully got my head wrapped around all the effects of modularity.

I'm not sure if RHEL has any such modules, but it is functionally possible.


-- 
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

2020-02-15 Thread Matthew Miller
On Sat, Feb 15, 2020 at 11:27:46AM -0500, Stephen John Smoogen wrote:
> From my also little understanding of modularity, this is so you can
> reinstall base perl packages. In some ways ( I am glossing over things
> here), modular rpms always beat bare rpms because a module can put in rules
> to say 'you can install this package but it does not work with these rpms
> so they need to be removed'. So I think any modules we write which would
> over-ride non-modular packages, we would also need to write a 'get me back
> my f'ing defaults' module which stubs in a similar way the perl and some
> other modules do.

No, this is not the case. If the module isn't enabled its packages will just
be ignored. It's only if you enable the module that you get the RPMs from
that module.



-- 
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] Proposed official change to EPEL guidelines: modules and RHEL

2020-02-13 Thread Matthew Miller
I've been saying this for a while as if it's fact, but of course it's not
actually fact until approved, so I'm puting this to the EPEL team to
hopefully do so.

The current guidelines * say:

   EPEL packages should only enhance and never disturb the Enterprise Linux
   distributions they were built for. Thus packages from EPEL should never
   replace packages from the target base distribution - including those on the
   base distribution as well as layered products; kernel-modules further are
   not allowed, as they can disturb the base kernel easily.

With modularity in EPEL 8, we have the opportunity to allow more flexibility
while preserving the primary goal of not disturbing the base distribution.
Therefore, I propose adding:

  In EPEL 8 or later, it is permitted to have module streams which contain
  packages with alternate versions to those provided in RHEL. These packages
  may be newer, built with different options, or even older to serve
  compatibility needs. These MUST NOT be the default stream -- in every
  case, explicit user action must be required to opt in to these versions.


(Note that the base package _does not_ have to be part of a module for this
to work.)

What do you think?


* 
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Packaging_Guidelines_and_Policies_for_EPEL
-- 
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: epel8-playground and centos-stream?

2019-10-05 Thread Matthew Miller
On Sat, Oct 05, 2019 at 11:58:31AM -0700, Kevin Fenzi wrote:
> So, question: when say RHEL8.1beta comes out. Is the Centos 8 stream
> updating that? (ie, has all beta changes and continues from there?).
> I think we need to be very careful with beta's. If we can get security
> updates via centos 8 stream then great, but if not, that makes a known
> pool of insecure software. :( 

As I understand it, CentOS Stream will get security updates (because no one
wants a big pool of insecure software, and it's not good for users), but
that the significant, expensive work that the Red Hat security team and Red
Hat developers do to develop fixes should be available to paying customers
first. That seems reasonable to me. Also, of course, many such fixes have
embargo dates and _can't_ be made public early. The mechanisms for doing
this aren't actually built yet.

-- 
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: FreeRDP version updates.

2019-10-05 Thread Matthew Miller
On Sat, Oct 05, 2019 at 11:22:59AM +0100, Darren Wise wrote:
> I also noticed that multiple versions are not maintained, could I please
> be pointed to somewhere I could get a complete mirror of the EPEL
> repository and I'd be happy to maintain myself online? -Maybe I could
> start an repository online funded by myself which maintains multiple
> versions?

So, we're not quite ready for this yet in EPEL, but allowing multiple
versions of packages to be maintained within the same, official repository
is what the Modularity feature in Fedora and now RHEL 8 is for. Would you be
interested in maintaining the versions you need as part of that?

In the meantime, let me direct you to Copr, our system for building and
offering package repositories with a very low barrier to entry. Check it out
at https://copr.fedorainfracloud.org/. This would be a great place to start,
and then once we have modular EPEL up and running you could migrate packages
to that.

-- 
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: epel8-playground and centos-stream?

2019-10-04 Thread Matthew Miller
On Fri, Oct 04, 2019 at 11:00:35AM -0400, Stephen Gallagher wrote:
> I'd suggest a middle-ground: we normally build against the latest RHEL
> 8 minor release. Once the RHEL 8.x+1 *beta* is released, we change
> epel8-playground to build against CentOS stream until the GA release.
> We can also potentially run a mass-rebuild at this time to help
> identify issues early.

I don't think 8.x+1 betas are going to always be a thing if CentOS Stream is
successful. Also, I'm not sure this helps at all except splitting what's
broken in time between RHEL and CentOS Stream.


-- 
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: epel8-playground and centos-stream?

2019-10-03 Thread Matthew Miller
On Thu, Oct 03, 2019 at 07:37:09AM -0700, Troy Dawson wrote:
> In my opnion, bad idea.  We should be using koschei [1] for that.
> Two reasons it's a bad idea.
> 1 - Since Stream is be definition, changing, you will not easily know
> what an EPEL package is built against.

Well, it's changing, but the net sum of changes over a six month period is
exactly equal to the net sum of changes from one RHEL minor release to the
next.

-- 
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: epel8-playground and centos-stream?

2019-10-03 Thread Matthew Miller
On Tue, Sep 24, 2019 at 02:54:26PM -0700, Kevin Fenzi wrote:
> After the announcement today of centos-stream, I wonder if it would make
> sense to move epel8-playground to build against that instead of the
> latest rhel8 release?

This is something we're talking about at the CentOS Stream kickoff meeting.
As EPEL exists today against RHEL and CentOS Linux rebuild, there's a lag
time problem when there are surprising RHEL updates -- usually fixed in a
few days but sometimes weeks. With CentOS Stream, hopefully there will be no
surprises, but the gap between CentOS Stream and RHEL will be always there.

I think if we changed EPEL Playground to build against CentOS Stream, we'd
just move the bifurcation problem rather than solving it. I kind of think we
need _both_ epel8 and epel8-playground built against both RHEL and CentOS
Stream. But I'd love to hear better ideas.


-- 
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 EPEL policy change: Minor release based composes

2019-02-15 Thread Matthew Miller
On Fri, Feb 15, 2019 at 09:45:01AM -, Jeroen van Meeuwen wrote:
> I would add as a benefit that past experiences have taught us that at
> times, packages in EPEL may be included in new minor RHEL releases, and
> would therefore need to be dropped from EPEL.

In the future, we won't necessarily need to do that, if we want to include a
different version of the package as an alternate module stream. (Sometimes
the RHEL versions have reduced functionality, or maybe we want to offer
newer versions.)



-- 
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://getfedora.org/code-of-conduct.html
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 EPEL policy change: Minor release based composes

2019-02-14 Thread Matthew Miller
On Thu, Feb 14, 2019 at 10:17:53AM -0600, Richard Shaw wrote:
> Ok. I ran into an issue on EPEL 7 where I needed to update a package so it
> could work with a package that was part of a Review Request. Then I found
> out someone was using my library as part of validated software they were
> developing. Lesson learned the hard way. Assuming this goes through I will
> be able to update on point releases and they can chose whether to update
> their whole system or not, in which case they would have to revalidate
> anyway.

This might be a case for offering the library as a module -- at least when
we get the details around that worked out.


-- 
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://getfedora.org/code-of-conduct.html
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: Fedora project login

2019-01-02 Thread Matthew Miller
On Wed, Jan 02, 2019 at 12:44:05AM -0800, Michael A. Peters wrote:
> Extremely BAD experience trying to log in at
> https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9a4a06731c
> First I couldn't remember my username but I could remember my
> password and the VERY BROKEN DESIGN does not allow me to request it
> send me a reminder of my username.

Yeah, we know. As I understand it, aa replacement for FAS (the account
system) is a high-priority infrastructure project for this year.

Sorry for the frustrating experience, and thank you for your feedback on it.

-- 
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://getfedora.org/code-of-conduct.html
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: Blue Sky Discussion: EPEL-next or EPIC

2018-05-19 Thread Matthew Miller
On Thu, May 17, 2018 at 07:53:18PM -0400, Stephen John Smoogen wrote:
> First, I am not disagreeing with what you are saying. I wrote the
> proposal as things that are inside EPEL's circle of influence with
> most of the other items going to take a LOT of release engineering
> work to accomplish. I am also writing it for a risk averse consumer
> base who want assurances that they can get old stuff even if it is
> past its sell by date and that it won't eat their children if they
> fat-finger a command. If Fedora wants to build it across all
> platforms, I don't have a problem with it.. I just didn't see it as
> inside of what we influenced.

That's all fair too. I just don't want to undershoot, either. :)

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/M3IPJKJ2FUK7DBQZE4FB47UKJO7MSCFF/


[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

2018-05-17 Thread Matthew Miller
On Thu, May 17, 2018 at 04:36:17PM -0400, Stephen John Smoogen wrote:
> I have been worried about a negative feedback loop here on packagers.
> This is a new technology and packagers aren't usually people who care
> about EPEL. Having them to deal with multiple OS's they don't use
> makes it more likely they don't want to put stuff in modules in the
> first place. I would prefer to be looser on the uptake of modules to
> get people comfortable with them in Fedora first. I also don't expect
> a large demand for modules in EPIC.

Modules solve two problems for EPIC:

First, since each module has a lifecycle definition, they make it easy
to maintain packages for EPIC without the 10-year commitment (or,
indeed, any more commitment then the packager makes in Fedora). And
that works both ways: as a consumer, I can know up front what lifecycle
I can (at least nominally) expect from a given module stream.

Second, I *do* think there are a lot of cases where different EPIC
users will want different versions. The Django module we have in Fedora
now would be immediately useful.

I do also worry about the possible negative feedback loop. I suggest we
start _building_ for EL by default but not tagging into the repo. Make
_that_ opt-in.


> >>   Extra Packages Inter Community.
> > Extra Packages for Impassioned Community?
> > Extra Packages Included by Community?
> > Extra Packages Introduced by Community?
> > Extra Packages Including Community?
> > Extra Packages for Interprise Community? (Or "EPEC"?)
> Extra Packages for Introverted Communities

Extroverted Packages for Introverted Communities!

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/ZF72FFOWREWSOHPA7MPJL74ZQNZZQMZX/


[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

2018-05-17 Thread Matthew Miller
On Tue, May 15, 2018 at 03:06:43PM -0400, Stephen John Smoogen wrote:
>   Modules
[...]
> EPIC-next
> 
>The tooling for modules can match how Fedora approaches it. This
>means that rules for module inclusion will be similar to package
>inclusion.  EPIC-next modules must not replace/conflict with CentOS
>modules. They may use their own namespace to offer newer versions
>than what is offered and those modules may be removed in the next
>minor release if CentOS offers them then.

I think we should do this part differently. Each Fedora module has its
own lifespan, separate from that of the base OS. It automatically gets
built across all currently-supported base OSes. That way, I can
maintain, say, "calc-2.x" in just one stream (where stream = git
branch), and it automatically gets built everywhere. Rather than having
EPIC modules be entirely separate, I'd like to just include them in
this: by default, build all modules against both the Fedora _and_ EL
bases.

This has a further implication: these modules _may_ replace or conflict
with CentOS (and possibly RHEL) modules. But you'd have to opt-in to
those streams explicitly to do so. With non-modular Yum/DNF, having some
packages update base software would be horrific because enabling the
repo and running `yum update` would do who-knows-what. But with
modules, that's not a problem.


>EPIC
>   Extra Packages Inter Community.

Extra Packages for Impassioned Community?
Extra Packages Included by Community?
Extra Packages Introduced by Community?
Extra Packages Including Community?
Extra Packages for Interprise Community? (Or "EPEC"?)



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/PHQUXTILYCJYVZTEZMNMLDTQDIZDUH6V/


[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

2018-05-16 Thread Matthew Miller
On Tue, May 15, 2018 at 09:31:07PM -0400, Neal Gompa wrote:
> I currently provide an EPEL-safe version of DNF in my COPR[1] that I'm
> considering putting into EPEL, but it doesn't have the modularity stuff
> because it's too much of a mess right now.
> [1]: https://copr.fedorainfracloud.org/coprs/ngompa/dnf2-el7/

Have you seen this?
https://blog.centos.org/2018/04/yum4-dnf-for-centos-7-updates/

-- 
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


[EPEL-devel] Re: OFFLIST Re: rh-epel] END OF LIFE FOR EPEL-5 (2017-03-31)

2017-03-10 Thread Matthew Miller
On Thu, Mar 09, 2017 at 03:11:21PM -0600, Jason L Tibbitts III wrote:
> It will be interesting to see if this appreciably increases traffic to
> my mirrors.

Yes, it will — I'd love to see any analysis of that you do.

-- 
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


[EPEL-devel] Re: rethinking the epel testing

2017-01-18 Thread Matthew Miller
On Wed, Jan 18, 2017 at 11:48:14AM -0500, Stephen John Smoogen wrote:
> 1) Getting an account is seen by many people as the same as taking an
> oath of allegiance. They get angry when they only joined a group to
> report some problem and then see that their joining is used in some
> other promo that the groups user base has grown by N amount because
> there are more registered users.  They are 'CentOS' users not Fedora
> users.

I have two things to say to this. First, this is a misperception. EPEL
is part of Fedora; EPEL users are Fedora users.

Second, I don't think that this is generally a problem with CentOS
users, who tend to be pragmatic rather than loyalists. 


> 2) This belief that signing up is an oath of allegiance goes both
> ways. Some Fedora packagers and users expect that any problem reported
> for a package should be only 'fixed' if it shows up in the latest
> Fedora release. They see that a person has a Fedora account and they
> say "Why aren't you using Fedora instead of that claptrap OS."

Do you have an example of that, or is it just a worry that it *might*
happen? I know of many cases where Fedora packagers don't want to take
on the commitment of maintaining an EPEL package, but for those who
have, if this is their response, they should probably rethink that.


> 3) Finally Fedora and CentOS are worlds apart in what they want. EL-6
> is the largest usebase and is still growing. That means people are
> wanting things that will work on Fedora 12. Many have no idea or want
> to deal with containers, modules, and are just trying to get their
> head around systemd which they will probably be rolling out in the
> next 4 years (though some are hoping it will get replaced by Linus
> with a git like better tool). Fedora people are starting to show signs
> of being tired of containers and are trying to figure out the next big
> thing to work on.

Sure, at least to some degree. But I don't think that's hugely relevant
to this particular thing.


> Now while it would be nice to get them to talk together more.. most of
> the time the only useful conversations seem to happen over beer and
> dinner.. while email lists turn into tribal fights of slights and
> sarcasm.

That's probably more a matter of having gotten the right people to the
beer and dinner situation and not having done so in email.

-- 
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


[EPEL-devel] Re: rethinking the epel testing

2017-01-18 Thread Matthew Miller
On Wed, Jan 18, 2017 at 10:39:14AM +0100, Nikos Mavrogiannopoulos wrote:
> To understand what this cryptic message means one has to click the link
>  in QA:Updates_Testing. If one tries these generic instructions in
> EPEL, he will notice that they don't work. One needs to replace dnf
> with yum. As both packager's names are meaningless for the average
> person that may or may not be obvious.

It's a wiki, so that can be fixed I've added a brief "EPEL" section
to that page. Feel free to improve it.

> While some of these users will read the links to generic instructions
> that was posted, and do things right, most will not (in my experience
> none reached that point). An improvement would be not to link to
> generic instructions but post specific instructions for the component
> fixed. How to install and how to leave feedback. At this moment my
> impression is that we are posting links to bugzilla and we expect the
> users to educate themselves.

That's probably true. What else can we do to improve that? 

-- 
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


[EPEL-devel] Re: rethinking the epel testing

2017-01-17 Thread Matthew Miller
On Tue, Jan 17, 2017 at 04:11:31PM +0100, Nikos Mavrogiannopoulos wrote:
> 1. The majority of people who use EPEL are not Fedora users. They are
> more likely to report a bug they encounter, in CentOS forums (or RHEL)
> rather than understand fedora process and the need for karma.

Can we help steer those people into understanding Bodhi? It's not like
a deep knowledge of all things Fedora is required.


> I do not have any good suggestion, other than reducing the long period
> of testing to the Fedora defaults (7 days). A better approach would be
> to tie more to centos processes, and allow centos registered users to
> give karma and test, but I have no idea how feasible it is, and whether
> centos users will actually get involved in EPEL.

I think we should be able to do federated authentication with CentOS
and accept CentOS accounts as valid for meaningful karma. But I'd
really rather encourage just getting Fedora accounts and helping draw
people who are in the Fedora community though EPEL into more close
connections.

-- 
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


[EPEL-devel] Re: Desktop application major update (darktable)

2016-10-25 Thread Matthew Miller
On Tue, Oct 25, 2016 at 11:07:28AM -0600, Kevin Fenzi wrote:
> Well, we need more information (or at least I do): 
> * Is 1.x still supported by upstream?

I don't think so -- the last commit to the "darktable-1.6.x" branch is
just over a year ago, Oct 21, 2015.

> * Are there any known 1.x security issues?

I don't think there are any known outstanding ones — CVE-2015-3885 was
fixed in 1.6.7.

> * Is the upgrade from 1.x to 2.x transparent for the user? ie, would
>   they have to do any manual steps to move config? or is that all done
>   by the application?

It should be transparent, but it _is_ one way — if you make any edits
in the new program, you can't go back.

> * Is the "user experence" different between 1.x and 2.x?

Eh. Judgement call. I'd say it's fundamentally the same, but there are
many differences in both functionality and look & feel. 


Honestly, I think this is an example of an application which is not a
great fit for EPEL. It'd be better if we would make a Flatpak which
RHEL/CentOS users could transparently use.


-- 
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


[EPEL-devel] Re: 32 bit revisited

2016-10-20 Thread Matthew Miller
On Thu, Oct 20, 2016 at 01:45:01PM -0700, Karsten Wade wrote:
> > Do you mean for 32-bit in specific, or in general? In that case, why
> > import instead of just using the packages directly?
> I think it's the same situation that Fedora has -- if it's not built on
> CentOS infra, then it can't be called "CentOS."

Rebuilding things for the sake of not trusting each other seems like
extra work we are making for ourselves (in both directions). Maybe we
could figure out what the drivers are behind having that barrier and
work on overcoming them.

-- 
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


[EPEL-devel] Re: 32 bit revisited

2016-10-20 Thread Matthew Miller
On Thu, Oct 20, 2016 at 12:55:02PM -0700, Karsten Wade wrote:
> Part of my thinking is the situation where CentOS SIGs need EPEL
> packages and (aiui currently) have to import to git.centos.org and build
> the packages on cbs.centos.org.

Do you mean for 32-bit in specific, or in general? In that case, why
import instead of just using the packages directly?


-- 
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


Re: [EPEL-devel] Centos 7, 32 bits edition

2015-10-15 Thread Matthew Miller
On Wed, Sep 30, 2015 at 08:50:51AM -0500, Ian Pilcher wrote:
> >I fully expect a release of this version within a week ...
> FYI, it looks like CentOS 7 for 32-bit x86 is finally imminent.

And in fact is out now:
http://seven.centos.org/2015/10/centos-linux-7-32-bit-x86-i386-architecture-released/

-- 
Matthew Miller

Fedora Project Leader
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] [Proposal] Converge EPEL and CBS

2015-09-23 Thread Matthew Miller
On Tue, Sep 22, 2015 at 08:45:32PM -0700, Karsten Wade wrote:
> AIUI, the concern is that what is labeled/supported by the CentOS
> Project as 'CentOS' needs to go through the CentOS Project QA system.
> We simply cannot blindly accept builds from outside of the CentOS
> builders just on say-so. (Compare to RPMfusion et al -- putting that
> repo in as a default for Fedora users is more than a legal issue, it's
> a QA/test/build/sign/release issue.)

I can understand that with "out of the family" sources, but with Red
Hat now sponsoring CentOS as well as Fedora can we build a better
bridge of trust, here?

-- 
Matthew Miller

Fedora Project Leader
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: [EPEL-devel] [CentOS-devel] Meeting face to face CentOS Project and EPEL

2015-01-13 Thread Matthew Miller
On Fri, Jan 02, 2015 at 01:27:16AM +, Karanbir Singh wrote:
> Everyone able to make it please let me know your names so I can track
> attendance and make reservations accordingly.

I'll be there. Sorry for the slow reply!

-- 
Matthew Miller

Fedora Project Leader
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL Questions about SCL during meeting (was: Anybody has something for agenda for Env-and-Stacks WG meeting today? (2014-09-09))

2014-09-11 Thread Matthew Miller
On Wed, Sep 10, 2014 at 03:51:00PM +0200, Honza Horak wrote:
> However, there are and will be cases where somebody would like to
> create a non-SCL RPM depended on a software collection, which is
> something not solved properly yet and the solution might be quite
> different from collection to collection.

This makes me kind of scared. I'm all for the first sort of software
collection, but I think limiting this helps constrain the problem set.

(Although I don't think such packages should be limited from, eg, Fedora
Playground.)

-- 
Matthew Miller

Fedora Project Leader
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL Orphaned packages with vulnerabilities

2014-08-11 Thread Matthew Miller

Please remember that EPEL falls under the Fedora Code of Conduct too.
Let's assume that everyone is operating in good faith, and if something was
done too hastily, it wasn't _malicious_ -- just someone trying to get things
done. It also seems unlikely that there is irreparable harm here. Let's be
constructive and get this worked out without making it personal. Thank you.

-- 
Matthew Miller

Fedora Project Leader
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL getting terminus-fonts added to 7

2014-07-08 Thread Matthew Miller
On Tue, Jul 08, 2014 at 11:05:59PM -0400, Jens Petersen wrote:
> terminus-fonts is required by dmenu, which in turn is needed by xmonad.
[...]
> What is the best approach here?

This requirement seems to be just in the fedora spec file -- it doesn't seem
to be part of the upstream. From the man page, this is set with the '-fn'
flag at runtime. I didn't look at xmonad, but there's nothing inherently in
dmenu which seems to need it. I removed terminus-fonts with --nodeps from a
test system, and it seems to run fine maybe that's an easier solution?


-- 
Matthew Miller

Fedora Project Leader
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL Amazon Linux and

2014-05-09 Thread Matthew Miller
On Fri, May 09, 2014 at 10:36:11AM +0800, Christopher Meng wrote:
> So I believe it's worthwhile to add some notes on EPEL page to alert the
> incompatibility.

Something along the lines of: "EPEL is built on unmodified RHEL, and will
generally work on close rebuilds like CentOS. EPEL packages may not work on
distributions like Amazon Linux, which sometimes makes significant changes."

In the future, if CentOS "varients" catch on, this could be expanded to note
that those won't necessarily work either.

-- 
Matthew Miller--   Fedora Project--
  "Tepid change for the somewhat better!"
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL Amazon Linux and

2014-05-08 Thread Matthew Miller
On Fri, May 09, 2014 at 09:45:12AM +0800, Christopher Meng wrote:
> I've seen the thread of LLVM on Amazon, recently I received a report
> that my package lnav doesn't work properly on Amazon Linux:
> lnav: undefined symbol: _ZN7pcrecpp2RE4InitEPKcPKNS_10RE_OptionsE
> From the symbol I can see there should be a problem in pcre package.
> Therefore here comes a question, what's the difference between
> RHEL(CentOS) and Amazon?

Quite a lot; they make no attempt at compatibility. I think I'd respond with
that. EPEL packages might work on Amazon Linux, and they might not.

-- 
Matthew Miller--   Fedora Project--
  "Tepid change for the somewhat better!"
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL EPIC! [was Re: and SCL]

2014-04-10 Thread Matthew Miller
Hey all. I don't know if you noticed, but Smooge has a talk proposal at
Flock about this. Go to 

<https://admin.fedoraproject.org/voting/vote_range/flock-2014>

and put "128" for "EPEL.next". (It's a slightly confusing range-voting
scheme -- you can put any value for any talk including reusing numbers, and
high means very interested and 0 means not at all.)

Obviously you should also vote for other interesting talks as well at the
same time. And I hope to see a bunch of the interested people there!




-- 
Matthew Miller--   Fedora Project--
  "Tepid change for the somewhat better!"
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


EPEL EPIC! [was Re: and SCL]

2014-03-21 Thread Matthew Miller
On Thu, Mar 20, 2014 at 06:35:38PM -0700, Karsten Wade wrote:
> > I've never heard of this EPIC repository and google doesn't seem to
> > know it either. Where can this be found?
> It doesn't exist, it's an idea that Robyn has floated semi-seriously
> as a way to provide a repo that moves faster than EPEL. Rather than
> try to jam fast-moving stuff in to EPEL, the idea was to do an Extra
> Packages for Infrastructure and Cloud (EPIC) that had a different,
> faster-moving charter. EPIC would target the *EL platform just as EPEL
> does.

I think this is a great place to try out what we can do with CentOS
collaboration, since they're officially "in the family" now. Anyone have
ideas on how best to proceed with that? New SIGs in both projects? A single
new SIG spanning both? (CentOS's new SIGs seem to be a lot more heavyweight
in terms of process than the concept we have for them in Fedora, for better
or worse.) Some new joint upstream to be the meeting point?

Robyn, you around? Want to lay out the idea in more depth?



-- 
Matthew Miller--   Fedora Project--
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL and SCL

2014-03-20 Thread Matthew Miller
On Thu, Mar 20, 2014 at 04:15:18PM -0600, Stephen John Smoogen wrote:
> I have been thinking about this and wondering if SCL's might be better
> under Robyn's "EPIC" (Extra Packages for Infrastructure and Clouds) which
> would be something that could have less rigid rules for keeping going for
> 12 years that would be more in line with SCL's 2-3 year lifetimes. I was
> going to bring it up as a FLOCK talk to get the ball running with possible
> interaction with the CentOS group (maybe joining with their SCL
> operations). Does that make sense?

It makes a ton of sense to me, at least.

-- 
Matthew Miller--   Fedora Project--
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL repo signing [was Re: Python 3 for 7?]

2014-01-20 Thread Matthew Miller
On Mon, Jan 20, 2014 at 10:49:07AM -0700, Kevin Fenzi wrote:
> It's pretty much impossible with our current signing setup to sign
> rawhide style repos. ;) 

Ah, okay. Glad to have misunderstood there. :)

> There is a koji plugin to sign all built packages, but it stores gpg
> keys on the hub, passphrases in the koji config and is pretty much
> never going to be acceptable to upstream koji to add. 

Maybe an intermediate thing would be a less-secure-than-sigil-but-still-
separate automatic signing server?


-- 
Matthew Miller--   Fedora Project--
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


EPEL repo signing [was Re: Python 3 for 7?]

2014-01-20 Thread Matthew Miller
On Fri, Jan 17, 2014 at 03:42:34PM -0700, Kevin Fenzi wrote:
> > My thoughts are these (in no particular order).
> >  * Treat this branch like Rawhide. All builds targeted at this are
> > composed to a repo. Signing is nice, but not mandatory in my opinion.
> It's pretty much impossible to sign rawhide style repos. ;) 

I don't think that's the case. It does affect what sigificance / level of
trust is attached to the signature, though. Signing which happens as part of
the build process asserts that _this package came through our build system_.
(And implicitly, that we think the build system isn't compromised.)

That's less of a strong guarantee than "a human inspected this package and
asserts that ", with ___ being whatever human verification is
done. It's my undertand that right now, the signing process actually doesn't
make a very strong assertion at all -- it is roughly "a human ran a script
to take output from the area where the build system is expected to put it,
and this is that output". Correct me if I'm wrong!

This is somewhat more secure than signing _in_ the build system because the
signing key is more protected, but could potentially introduce another
avenue of attack (between buildsystem output and signing). If the build
system is compromised in a way that isn't detected, compromised output would
likely get signed anyway, right? It's not much of a stronger assertion than
the auto-signed one.

Doing anything much greater involves human time with each package, and
that's really expensive. Since I don't think we are likely to get the
funding to do that, and since being able to make the _basic_ assertion for
all of our devel/rawhide packages would be quite valuable, I think we should
aim for doing it. (Whether it should replace or just supplement the current
signing process, I don't have a really strong opinion on, although I'm in
general in favor of more automation and less work which depends on
intervention from specially-privileged humans, because that can become a
bottleneck.)

-- 
Matthew Miller--   Fedora Project--
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL Python 3 for 7?

2014-01-17 Thread Matthew Miller
On Fri, Jan 17, 2014 at 09:48:18AM -0800, Toshio Kuratomi wrote:
> > Packages for Infrastructure and Clouds, I think). I was thinking about this
> > more recently in the context of "things we need for Fedora.next in the
> > coming year or so". The new repo might target both EL and Fedora and provide
> > alternative versions maintained on, say, a 3-year lifecycle.
> Yeah -- I think that something like this could be good.  A repo with
> a 3 year lifecycle may make sense for RHEL more than Fedora as the
> basesystem we're building on is still active at the end of that period.

I'm thinking here about SCLs (or possibly other stack/env tech) that might
target current supported Fedora but have a longer lifecyle of its own (with
best-effort compatibility for three years).

I keep coming back to this idea because it's what people ask me for. :)

-- 
Matthew Miller--   Fedora Project--
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL Python 3 for 7?

2014-01-17 Thread Matthew Miller
On Fri, Jan 17, 2014 at 08:05:23AM -0700, Dave Johansen wrote:
> > system.so we've mostly decided that things in the system shouldn't use SCLs
> > to work.  So we still need to solve the problem of newer python interpreter
> > and newer django framework for use with apps that EPEL ships.
> What about having a separate EPEL repo for SCLs and/or these newest version
> of things? Like you mentioned before, this takes more work, but if then
> those that want the stable base can have it and those that want the newest
> can have it as well.

Or possibly an additional sub-project separate from EPEL. The idea has been
kicked around a little bit -- Robyn Bergeron calls it "EPIC" (for Extra
Packages for Infrastructure and Clouds, I think). I was thinking about this
more recently in the context of "things we need for Fedora.next in the
coming year or so". The new repo might target both EL and Fedora and provide
alternative versions maintained on, say, a 3-year lifecycle.


-- 
Matthew Miller--   Fedora Project--
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL python-boto rebase

2013-07-02 Thread Matthew Miller
On Tue, Jul 02, 2013 at 03:47:25PM -0700, Garrett Holmstrom wrote:
> Hi, folks,
> Since a large number of people have requested new features in
> python-boto I'd like to update it from version 2.5.2 to the current
> version, 2.9.6.  API-wise it should be completely
> backwards-compatible, but there is one change of note:  it now
> verifies SSL certs by default.  Will that break anybody?  I can help
> with patches if necessary.
> https://admin.fedoraproject.org/updates/python-boto-2.9.6-2.el6

We've still got the 2.6.0 in Fedora 19 -- at what point did the SSL change
come in?


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel


Re: EPEL Django deprecated

2013-06-07 Thread Matthew Miller
On Fri, Jun 07, 2013 at 01:31:36PM -0600, Stephen John Smoogen wrote:
> The easiest way I could see is just get a better sampling method which
> would be to have funding for a mirror which we then put into mirror-manager
> and we know that this is a sampling versus a request info. (basically we
> would see what packages are downloaded directly and then extend that sample
> from the amount of downloads to the 500,000 systems that check in via
> mirrormanager). The problems involved are paying for systems, storage, and
> bandwidth for such items.

Maybe one of the mirrors would be able to provide logs?





-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel