On Thu, Sep 25, 2014 at 11:27 AM, Till Maas opensou...@till.name wrote:
On Thu, Sep 25, 2014 at 11:47:43AM -0500, Jim Perrin wrote:
This would be my take also, getting pkgs into EPEL is a pretty well
defined process as is a becoming a packager. I don't see an extra
step/group
is needed
There may be users of Cacti from EPEL on this the epel-announce list,
so I'm forwarding this here.
-- Forwarded message --
From: Ken Dreyer ktdre...@ktdreyer.com
Date: Thu, Oct 23, 2014 at 11:08 AM
Subject: intent to retire cacti
To: Development discussions related to Fedora de
On Fri, Nov 7, 2014 at 7:04 AM, Elías Chistyakov ilchistya...@gmail.com wrote:
How can I update date mirror?
The first step is to find out which mirror that you server is using so
that we know which EPEL mirror is out of date. Try enabling debug
options in yum:
URLGRABBER_DEBUG=1,debug.log
On Fri, Dec 12, 2014 at 10:34 AM, Stephen John Smoogen smo...@gmail.com wrote:
On 12 December 2014 at 04:42, Cesare Bellini cesar...@gmail.com wrote:
I am using CentOS 7 and I have noted that the project tinyproxy is not
present in the EPEL 7 repository. It was part of the repository until EPEL
On Wed, Apr 1, 2015 at 5:47 PM, Kevin Fenzi ke...@scrye.com wrote:
ok. I think I have it fixed.
Can you retry your builds ?
Thanks, it worked!
http://koji.fedoraproject.org/koji/taskinfo?taskID=9399709
I'm curious what the problem / resolution was :)
- Ken
+0100
Paul Howarth p...@city-fan.org wrote:
On 01/04/15 16:26, Ken Dreyer wrote:
On my PPC64 build of Ceph today [1], I'm seeing this really odd
error regarding libxml2-devel:
from root.log:
...
DEBUG util.py:388: Error: Package:
libxml2-devel-2.9.1-5.el7_1.2.ppc (build) DEBUG
Hi all,
I'm orphaning perl-MongoDB in EPEL 6 and 7 since I have not used it for a while.
The Fedora maintainer recently orphaned it in Fedora, so it's probably
going to get retired soon unless someone else would like to maintain
it.
- Ken
___
Yeah, the Koji build has been deleted as well:
http://koji.fedoraproject.org/koji/buildinfo?buildID=242226
It would be a good idea to update your rules for 2.7. That
mod_security-2.5.12-2.el6 build is over four years old and subject to
several CVEs...
CVE-2013-5705
apache2/modsecurity.c in
On Sat, Dec 12, 2015 at 7:34 PM, Peter Robinson wrote:
> 2) Automatic unpushing of updates that haven't gone stable after X
> time (I propose 3 months/90 days here). That should be ample time to
> know if it's good/bad.
Could we make it go the other way, and submit the
On Sun, Dec 13, 2015 at 11:28 PM, Peter Robinson <pbrobin...@gmail.com> wrote:
> On Mon, Dec 14, 2015 at 3:16 AM, Ken Dreyer <ktdre...@ktdreyer.com> wrote:
>> On Sat, Dec 12, 2015 at 7:34 PM, Peter Robinson <pbrobin...@gmail.com> wrote:
>>> 2) Automatic un
On Fri, Feb 26, 2016 at 2:38 PM, Felix Schwarz
wrote:
> Also as a sysadmin I dislike that stuff in EPEL can change at any time
> (whenever the maintainer can not support the old version anymore). If EPEL had
> some kind of "release" (e.g. tied to RHEL point releases)
On Fri, Jan 29, 2016 at 6:51 AM, Jamie Nguyen wrote:
> Sound reasonable?
As an EPEL nginx user, thanks for looking into this, and you have my
+1 for updating to a new secure version.
- Ken
___
epel-devel mailing list
On Tue, Aug 1, 2017 at 11:05 AM, Stephen John Smoogen wrote:
>
> Does the above sound reasonable ?
>
Sounds great.
It leads me to ask a question I've been wondering about for a while
w.r.t retiring Ceph from EPEL 7: How can we keep other random
contributors from re-introducing
Thanks Jason, this is a good idea.
- Ken
On Fri, Jan 26, 2018 at 11:51 AM, Jason L Tibbitts III
wrote:
> All of the initial run of packages have been submitted now. See
> https://fedoraproject.org/wiki/User:Tibbs/EPELPythonStubPackages for the
> complete list of builds.
>
>
On Wed, Jul 18, 2018 at 9:36 AM, Jason L Tibbitts III wrote:
>> "RI" == Roman Iuvshyn writes:
>
> Maintainers are generally going to be very reluctant to update a package
> in EPEL without some pressing need. Not generally as reluctant as Red Hat
> would
> be for a package in RHEL7 proper
On Wed, Jul 18, 2018 at 2:29 PM, Jason L Tibbitts III wrote:
>>>>>> "KD" == Ken Dreyer writes:
>
> KD> I've always thought it's the other way around, that EPEL moves
> KD> faster than RHEL,
>
> Well, what I said didn't contradict that, so... I gue
Hi EPEL folks,
There are some packages in CentOS 7 that did not ship in the main RHEL
7 Server product.
Examples:
python-jwt http://access.redhat.com/errata/RHEA-2018:1032
python-adal https://access.redhat.com/errata/RHEA-2018:1042
This went into the "High Availability" and "Resilient Storage"
On Mon, Feb 11, 2019 at 11:38 AM Kevin Fenzi wrote:
>
> On 2/11/19 9:27 AM, Ken Dreyer wrote:
> > Hi EPEL folks,
> >
> > There are some packages in CentOS 7 that did not ship in the main RHEL
> > 7 Server product.
> >
> > Examples:
> >
> > pyt
Hi folks,
In EPEL 7 we have some packages with "python34" and "python36"
prefixes in their names. I guess this is a consequence of using the
%{python3_pkgversion} macro over time.
Now that RHEL 7 has Python 3.6, and we want to deprecate Python 3.4 in
EPEL 7, I'm wondering about this.
If I'm
On Mon, Dec 2, 2019 at 11:47 AM Neal Gompa wrote:
>
> On Mon, Dec 2, 2019 at 1:34 PM Ken Dreyer wrote:
> >
> > Hi folks,
> >
> > In EPEL 7 we have some packages with "python34" and "python36"
> > prefixes in their names. I guess this is a
On Thu, Feb 13, 2020 at 5:54 AM Matthew Miller wrote:
>
> 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
>
It is amazing to me how often this setting makes things work.
It seems like we're hard-coding this to "1" more widely.
On Tue, May 19, 2020, 12:01 PM Paul Howarth wrote:
> On Tue, 19 May 2020 09:21:46 -0700
> Kevin Fenzi wrote:
>
> > On Tue, May 19, 2020 at 11:48:04AM -0400, Stephen John
On Wed, Sep 9, 2020, 6:50 AM Petr Pisar wrote:
> On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
> > To solve this problem, I am proposing that we create a new repository
> called
> > EPEL 8 Next.
> >
> > - built against CentOS 8 Stream
> > - opt-in for packagers (must request
On Thu, Jul 8, 2021 at 11:08 AM Michel Alexandre Salim
wrote:
> I might eventually extend python-bugzilla a bit to make it easier to
> do this. A lot of the operations seem to assume it's a small Bugzilla
> instance an would try to pre-load all the components for a given
> product.
Your comment
Hi folks,
The RHEL 9 composes do not have libev-devel and libuv-devel, so we
cannot build python-gevent on EPEL 9 easily.
(It's possible to package the missing -devel packages separately, and
I've been doing this by automatically following the NVR changes in
Stream 9's Koji for several weeks
On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer wrote:
>
> https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm
On the one hand, thank you for pointing out that this build is now
available. That's good to know.
On the
On Sun, Sep 26, 2021 at 2:25 PM Miro Hrončok wrote:
>
> On 24. 09. 21 21:45, Ken Dreyer wrote:
> > This means that python-pytest-cov and python-pytest-xdist won't be
> > available on epel9, since those require gevent.
>
> Ignoring the rest of your email for now, but I don
Hi folks,
When I run "fedpkg mockbuild" for my epel8 dist-git branches, it fails
with the following error:
Error: Error downloading packages: Status code: 403 for
:
>
> On 05. 10. 23 21:52, Ken Dreyer wrote:
> > Hi folks,
> >
> > I have some Python apps that "import dnf". I wanted to run these on
> > the parallel Python versions in RHEL 8 and 9, but there's no
> > python311-dnf library available.
> >
> &
Hi folks,
I have some Python apps that "import dnf". I wanted to run these on
the parallel Python versions in RHEL 8 and 9, but there's no
python311-dnf library available.
I haven't looked into this yet. Has anyone else looked at it?
I think I'll need something like
30 matches
Mail list logo