Re: EPEL Django deprecated

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/06/2013 10:21 AM, Matthias Runge wrote: Hey, just a heads up the package Django has been deprecated or EPEL5 and EPEL6. On EPEL6, you can use Django14 as well, if you don't require Django in version 1.3. Please note, the latter does not

Re: EPEL mock configs for epel7

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/2014 10:40 AM, Miro Hrončok wrote: Dne 16.1.2014 16:38, Ken Dreyer napsal(a): Would anyone mind sharing their mock configurations for EPEL 7? I've got this http://ur1.ca/gfot7 That's pretty close to

Re: EPEL Deprecated Django 1.5 in

On Thu, 2014-10-02 at 12:57 +0300, Dionysis Grigoropoulos wrote: On Wed, Oct 01, 2014 at 10:33:07PM +0200, Matthias Runge wrote: On Wed, Oct 01, 2014 at 01:28:04PM +0300, Dionysis Grigoropoulos wrote: Hello, as far as I can see, EPEL 7 currently provides packages `python-django`

[EPEL-devel] Re: nodejs update

On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote: > Hi! > > As some of you may know, nodejs package that is present in > EPEL is pretty outdated. The current v0.10 that we have will > go EOL in October and npm (package manager) is already not > maintained. > > Currently, upstreams' plan is to

[EPEL-devel] Re: nodejs update

On 08/22/2016 11:23 AM, Stephen Gallagher wrote: > On 08/11/2016 07:43 AM, Stephen Gallagher wrote: >> On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote: >>> Hi! >>> >>> As some of you may know, nodejs package that is present in >>> EPEL is pretty outdate

[EPEL-devel] Re: nodejs update

On 09/08/2016 01:27 PM, Stephen Gallagher wrote: > On 08/22/2016 11:23 AM, Stephen Gallagher wrote: >> >> OK, as we stated before, we really need to get Node.js 6.x into the >> updates-testing repository soon. We mentioned that we wanted it to sit there >> for >&g

[EPEL-devel] Strategy for Node.js upgrade in EPEL 7

Apologies for the re-send, but I typoed the epel-devel email address on the first try. On 09/13/2016 09:27 AM, Stephen Gallagher wrote: > Yesterday, I built the latest upstream version of Node.js for EPEL 7 (this > version will be supported until 2019-04-01) > > I have added it to t

[EPEL-devel] EPEL 7 Node.js Uplift

I updated the Bodhi update in EPEL to the latest 6.7.0 security release last night. I just want to remind people that there remain only three days until EOL of 0.10.x, so I think we really need to make the cut-over today or tomorrow by providing karma to push the update to stable. It takes at

[EPEL-devel] Re: nodejs broken

On Wed, Aug 23, 2017 at 7:17 AM Richard Grainger wrote: > OK, thanks, > > On Wed, Aug 23, 2017 at 12:13 PM, Anssi Johansson wrote: > >> Anssi Johansson kirjoitti 23.8.2017 klo 13.31: >> >>> Richard Grainger kirjoitti 23.8.2017 klo 11.55: >>> yum install

[EPEL-devel] Re: nodejs broken

On Wed, Aug 23, 2017 at 12:02 PM Peter Robinson wrote: > > The problem is that CentOS 7.4 still doesn't exist yet, so if Node.js > > requires OpenSSL 1.0.2 functionality, it's still broken for CentOS users. > > Yep, but then also is a bunch of other stuff due to the fact

[EPEL-devel] Re: nodejs broken

On Wed, Aug 23, 2017 at 10:02 AM Peter Robinson wrote: > > It turns out there's an additional issue; it appears that Node.js 6.11.2 > > with the bundled http-parser doesn't work properly with OpenSSL 1.0.1 on > > EPEL 7. This would also be fixed by requiring RHEL/CentOS 7.4

[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy

On Thu, May 30, 2019 at 3:18 PM Kevin Fenzi wrote: > > > As discussed in the EPEL SIG meeting yesterday, I've written up my > > thoughts on how to handle epel8 branches. > > TLDR: I like it. ;) > > > # Considerations > > * The process must be simple for a Fedora packager to adapt to > > * It must

[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy

On Thu, May 30, 2019 at 4:02 PM Troy Dawson wrote: > > On Thu, May 30, 2019 at 12:18 PM Kevin Fenzi wrote: > > Also might there be people who want to always keep something in rawhide > > and never push it to the stable stream? Or do we want to encourage only > > things destined for the next

[EPEL-devel] Re: Proposal: EPEL 8 Branch Strategy

On Thu, May 30, 2019 at 4:25 PM James Cassell wrote: > > > > > > Historical composes are intended to be frozen and unchanging, but this > > > approach leaves open the possibility of tagging other builds into > > > epel8-8.Y and regenerating the compose if the need arises. It will > > > need to

[EPEL-devel] Proposal: EPEL 8 Branch Strategy

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 As discussed in the EPEL SIG meeting yesterday, I've written up my thoughts on how to handle epel8 branches. # Considerations * The process must be simple for a Fedora packager to adapt to * It must be possible to stage big (possibly

[EPEL-devel] Node.js 6.x in EPEL 7 is effectively EOL today

I am currently building the latest available Node.js 6.17.1 package for EPEL 7. As it reached EOL upstream, the package in EPEL is likely to become stale at this point. In the past, we opted at this time to upgrade to the latest LTS upstream release, however the 6.x line still has a fairly large

[EPEL-devel] Re: Rules for shadowing RHEL packages with EPEL modules

On Fri, Aug 23, 2019 at 6:52 AM Petr Pisar wrote: > If I read the EPEL 8 annoucement correctly, it's still not possible to > build > modules in EPEL. Nevertheless I'd like to know how the rules about "not > replacing RHEL content" will apply to modules. Here are my question: > > Case: RHEL

[EPEL-devel] Re: Rules for shadowing RHEL packages with EPEL modules

On Fri, Aug 23, 2019 at 9:43 AM Petr Pisar wrote: > On Fri, Aug 23, 2019 at 08:26:32AM -0400, Stephen John Smoogen wrote: > > On Fri, 23 Aug 2019 at 06:52, Petr Pisar wrote: > > > Case: RHEL delivers a non-modular P package. There is no S stream of > > > a M module. Can I add a new M module

[EPEL-devel] Modularity Policy Discussion for EPEL 8.1

As you know, we delayed support of Modularity in EPEL (called Application Streams in RHEL) until 8.1 while we worked out some remaining issues. Some of those issues were technical, but we have a few others that will come down to policy. In particular, EPEL has to deal with something Fedora does

[EPEL-devel] Modules and EPEL8-Playground

As we plan EPEL 8.1 with support for Modularity/Application Streams, we will undoubtedly encounter numerous tricky questions that warrant public input. The first of these is this: where do modules fit into EPEL 8 Playground? I see three possibilities for how this can be done: 1) We create two

[EPEL-devel] Re: Modularity Policy Discussion for EPEL 8.1

On Fri, Aug 23, 2019 at 5:49 PM Kevin Fenzi wrote: > > On 8/23/19 10:56 AM, Stephen Gallagher wrote: ... > > For default profiles, we have some options as well: > > > > Option 1: We disallow setting default profiles for EPEL streams. Pros: > > no risk of confl

[EPEL-devel] Re: Modularity Policy Discussion for EPEL 8.1

On Mon, Aug 26, 2019 at 4:33 AM Petr Pisar wrote: > > On Fri, Aug 23, 2019 at 01:56:09PM -0400, Stephen Gallagher wrote: > > So, I see the following options for how to handle default streams in RHEL 8 > > > > Option 1: We disallow assigning default stre

[EPEL-devel] Re: Modularity Policy Discussion for EPEL 8.1

On Fri, Aug 23, 2019 at 1:56 PM Stephen Gallagher wrote: > > As you know, we delayed support of Modularity in EPEL (called > Application Streams in RHEL) until 8.1 while we worked out some > remaining issues. Some of those issues were technical, but we have a > few others that

[EPEL-devel] Re: epel8-playground and centos-stream?

On Tue, Sep 24, 2019 at 6:13 PM Neal Gompa wrote: > > On Tue, Sep 24, 2019 at 5:54 PM 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? > > > > It

[EPEL-devel] Re: epel8-playground and centos-stream?

On Thu, Oct 3, 2019 at 10:05 AM Matthew Miller wrote: > > 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? > >

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

On Tue, Feb 25, 2020 at 5:05 PM Troy Dawson wrote: ... > While I agree that we should be very careful with this, I do not > believe it should be completely off the table. > I believe it should be permissible with the EPEL Steering Council's > blessing, but not otherwise. > Case in point is

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

On Tue, Feb 25, 2020 at 3:57 PM Matthew Miller wrote: > > On Tue, Feb 18, 2020 at 04:06:32PM -0800, Kevin Fenzi wrote: > > Consider: > > > > 1. foo rpm that is in the RHEL baseos. It's not in any module. > > Can epel make a foo (non default) module that overrides it? > > This is safe from a

[EPEL-devel] Re: EPEL8 conflict policy

On Wed, Apr 8, 2020 at 11:26 PM James Cassell wrote: > > > On Wed, Apr 8, 2020, at 9:20 PM, Orion Poplawski wrote: > > There does not appear to be an explicit conflict policy for EPEL8: > > > >

[EPEL-devel] Re: What is the proper way to handle python3 python36 in RHEL7

On Tue, Mar 31, 2020 at 12:51 PM Erinn Looney-Triggs wrote: > > I am trying to build a package for RHEL 7 and RHEL 8 that depends on an EPEL > (for RHEL 7) package python36-dbus the requires section goes like so: > Requires: %{python3} > Requires: %{python3}-dbus > > This puts in a requirement

[EPEL-devel] Re: Pre-release EPEL

On Thu, Sep 16, 2021 at 10:11 AM Neal Gompa wrote: > > On Thu, Sep 16, 2021 at 9:38 AM Thomas Stephen Lee wrote: > > > > Hi, > > > > Thanks to people on the CentOS mailing list. > > We managed to get CentOS Stream 9 pre-release with updates working on a VM. > > Is there also a pre-release

[EPEL-devel] Re: Big Node.js jump coming to EPEL 7

On Mon, Jan 17, 2022 at 7:21 PM Stephen Gallagher wrote: > > Last week, I retired the `nodejs` package from EPEL 7 because it was > (I believed) stuck on Node.js 6.x due to insufficient dependency > support. Apparently, this broke a few things like uglify-js[1], so I > spen

[EPEL-devel] Big Node.js jump coming to EPEL 7

Last week, I retired the `nodejs` package from EPEL 7 because it was (I believed) stuck on Node.js 6.x due to insufficient dependency support. Apparently, this broke a few things like uglify-js[1], so I spent today looking into whether I could get Node.js 16.x to work (the latest LTS release) and

[EPEL-devel] Re: Bundling newer 3rd party binaries than are packaged separately

On Tue, Jan 23, 2024 at 11:58 AM David Trudgian via epel-devel wrote: > > Hi all, > > I currently package singularity-ce for Fedora and EPEL. > > Upstream, we bundle current versions of squashfuse and conmon with our source > and own binary packages… because many distros package versions that

[EPEL-devel] Re: Packaging a newer singularity-ce as singularity-ce4

On Fri, Jan 26, 2024 at 8:08 AM David Trudgian via epel-devel wrote: > > Hi all, > > I’ve had some discussion with Jonathan Wright elsewhere about the topic of > this message, but wanted to verify my understanding is correct before I > embark on it, and thought I’d do so on list. > >