[EPEL-devel] Re: Requesting branches for epel9
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
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
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
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
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?
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 ?
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
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
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
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
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?
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?
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?
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
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
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
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
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
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] Re: Proposed official change to EPEL guidelines: modules and RHEL
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
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
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
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?
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.
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?
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?
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?
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
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
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
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
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
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
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
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)
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
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
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
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)
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
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
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
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
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
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))
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
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
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
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
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]
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]
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
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?]
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?]
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?
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?
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
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
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
