On Mon, 30 Jan 2023 21:13:11 -0700
Orion Poplawski wrote:
> So, I'm wondering if we should have some kind of (at least
> semi-)coordinated plan for updating ansible collections in EPEL?
>
> My initial thought is we would sort of piggy back on to what the
> "ansible" community collection
On Wed, 20 Apr 2022 14:48:47 -0700
Troy Dawson wrote:
> gnucash-2.6.21-1.el72018-04-15 (1466)
Should be safe to unpush this one because gnucash-2.6.21-4.el7 should
be in epel7 stable for 2 years:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-aa8e8965dc
Paul.
On Fri, 14 Jan 2022 07:02:23 -0500
Josh Boyer wrote:
> 2) Moving content to CRB in RHEL is not a silver bullet solution in
> many scenarios. If it's strictly for build dependencies, CRB works
> well. If an EPEL package has a runtime requires on CRB content, that
> is less desirable. RHEL
On Fri, 4 Sep 2020 07:18:31 -0700
Troy Dawson wrote:
> Step 4 - Untag all the things that are "older" in playground
> -- currently that is a releng process. There is no way for a
> maintainer to retire their package from playground.
> -- This needs to happen some time (3 months?) after step 2 is
On Tue, 19 May 2020 19:00:25 +0100
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 Smoogen
> > wrote:
> > > On Tue, 19 May 2020 at 11:05, Paul Howarth
> > > wrot
On Wed, 20 May 2020 08:10:42 +0200
Petr Pisar wrote:
> On Tue, May 19, 2020 at 04:05:02PM +0100, Paul Howarth wrote:
> > On Tue, 19 May 2020 09:07:30 -0400
> > Stephen John Smoogen wrote:
> >
> > > On Tue, 19 May 2020 at 06:05, 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 Smoogen wrote:
> > On Tue, 19 May 2020 at 11:05, Paul Howarth
> > wrote:
> > > On Tue, 19 May 2020 09:07:30 -0400
> > > Stephen John Smoogen wrot
On Tue, 19 May 2020 09:07:30 -0400
Stephen John Smoogen wrote:
> On Tue, 19 May 2020 at 06:05, Paul Howarth wrote:
>
> > On Mon, 18 May 2020 22:29:54 -0600
> > Orion Poplawski wrote:
> >
> > > On 5/17/20 6:34 AM, Paul Howarth wrote:
> > > &
On Mon, 18 May 2020 22:29:54 -0600
Orion Poplawski wrote:
> On 5/17/20 6:34 AM, Paul Howarth wrote:
> > I'm trying to do a local build of gtkwave for EPEL-8.
> >
> > A koji scratch build somehow works:
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837
I'm trying to do a local build of gtkwave for EPEL-8.
A koji scratch build somehow works:
http://koji.fedoraproject.org/koji/taskinfo?taskID=44609837
But a local build does not:
$ mock -r epel-8-x86_64 gtkwave-3.3.104-2.fc31.src.rpm
...
Error:
Problem: conflicting requests
- package
On Thu, 14 May 2020 12:31:40 -0700
Michel Alexandre Salim wrote:
> We're working on validating CentOS 8 for some desktop use cases at
> work, and noticed that after working fine on a machine that's
> installed several months ago, it's now failing on a freshly-installed
> machine.
>
> Turns out
On Fri, 10 Apr 2020 15:17:25 -0700
Troy Dawson wrote:
> On Fri, Apr 3, 2020 at 3:21 PM Troy Dawson wrote:
> >
> > EPEL Issue #101 [1] has pointed out that our current policy for
> > stalled EPEL requests is fairly in-efficient and can cause some long
> > delays.
> >
> > What do people think the
On Thu, 21 Nov 2019 21:56:46 -0700
Orion Poplawski wrote:
> DEBUG util.py:596: No available modular metadata for modular package
> 'python2-rpm-macros-3-38.module+el8.1.0+3111+de3f2d8e.noarch', it
> cannot be installed on the system
> DEBUG util.py:596: Error: No available modular metadata
On Thu, 14 Nov 2019 15:08:32 +0100
Steve Traylen wrote:
> Hi,
>
>
> Last couple of days the epel8 branch requests have been processed
> okay. Thanks
>
> However when you then try and build something it results in
>
> BuildError: package X not in list for tag epel8-playground-pending
>
>
>
On Thu, 14 Nov 2019 15:08:32 +0100
Steve Traylen wrote:
> Last couple of days the epel8 branch requests have been processed
> okay. Thanks
>
> However when you then try and build something it results in
>
> BuildError: package X not in list for tag epel8-playground-pending
>
>
> Example:
>
>
On Tue, 10 Sep 2019 20:59:33 -0600
Orion Poplawski wrote:
> The epel8 branches were not properly created for hypre and
> superlu_dist. They were apparently made in the PDC, but they don't
> exist in pagure. What to do now? Thanks.
This is not the first time this has happened. Fortunately, you
The EL-8 non-default repo Code Ready Builder is primarily targeted at
developers, but it looks to me like it's going to be a required repo
for a lot of EPEL-8 users, particularly those using interpreted
languages.
As an example, today I built perl-Expect for EPEL-8
Hi,
On Wed, 14 Aug 2019 10:50:24 -0400
Stephen John Smoogen wrote:
> ## Known Issues:
> 1. EPEL-8.0 does not come with modules. Packages built for perl,
> python and other modules are only built against “default” modules. For
> example installing a perl library from EPEL will work with the
>
On Wed, 28 Nov 2018 07:01:04 -0600
Richard Shaw wrote:
> On Wed, Nov 28, 2018 at 5:29 AM Paul Howarth
> wrote:
>
> > On Wed, 28 Nov 2018 10:53:58 +0530
> >
> > I seem to remember that for EL-7 we generally just branched the f19
> > packages for epel7,
On 2017-09-29 03:45, Digimer wrote:
Hi all,
Continuing down by build dependency hole, I ran into another circular
dependency. I checked in perl-namespace-autoclean.spec for the
bootstrap
option, but it didn't seem to exist. I added it, and it allowed me to
build -> install
On 2017-09-28 08:42, Digimer wrote:
Hi all,
This is my first post, apologies if I am off-topic;
I'm trying to build perl-Moose, which depends on perl-Data-Visitor,
but perl-Data-Visitor depends on perl-Moose;
[digimer@el7-builder-test1 SPECS]$ rpmbuild -ba perl-Moose.spec
error:
On 2017-08-23 18:27, Stephen Gallagher wrote:
I think the only sane approach here is going to be to just drop all of
the 7.3-specific stuff and just tell people that they're unfortunately
out of luck on CentOS until 7.4 is out for that platform.
Not entirely out of luck. CentOS 7 users could
On 2017-08-11 19:00, Stephen John Smoogen wrote:
I have opened 2 tickets in RELENG to have these packages
removed/blocked for EPEL.
Packages which are newer in EPEL than RHEL-7.4
https://pagure.io/releng/issue/6948
Packages which are older in EPEL than RHEL-7.4 but exist in aarch64,
x86_64,
The package perl-MetaCPAN-API, which has been deprecated upstream for
some time now, was recently updated by upstream to support the new v1
API provided by MetaCPAN. The original v0 API, the only one supported by
the existing EPEL perl-MetaCPAN-API package, no longer works with
metacpan.org,
On 14/09/16 03:51, Dennis Gilmore wrote:
So, with the limited arch packages this means that _ALL_ things
building in koji will use the epel package. The reason for the
prepended 0 is so that users don't install the epel package and instead
get the newer rhel version. The limited arch guideline
On 22/01/16 03:11, Jason L Tibbitts III wrote:
I'm now working on some magic macros for EPEL5. Currently (on my
machine, at least) you can use %license and don't need BuildRoot:. I'm
curious about some other boilerplate constructs, though.
%defattr in %files:
I've been told that even EPEL5
On 21/01/16 00:49, Jason L Tibbitts III wrote:
...
Failures in %check: 12
ccache-2.4-21.el5.src.rpm (adev)
heimdal-1.6.0-0.9.20140621gita5adc06.el5.src.rpm (ktdreyer)
libresample-0.1.3-7.el5.src.rpm (jcollie)
perl-Calendar-Simple-1.17-2.el5.src.rpm (laxathom)
On 15/05/15 10:10, Simone Caronni wrote:
This seems the real issue (clicking under show result):
BuildError: mismatch when analyzing
bacula-logwatch-7.0.5-7.fc21.noarch.rpm, rpmdiff output was:
error: cannot open Packages index using db5 - Permission denied (13)
error: cannot open Packages
On 13/04/15 09:20, A.H.M Tasbir Farid wrote:
Dear All
I have configured EPEL local repository in my network. Other clients get
packages from central repo. I need a package named monit with version
5.2 to connect m/monit server. EPEL repo have the older version 5.1. I
can manually download the
On 31/03/15 12:17, Anssi Johansson wrote:
As of now, the following packages are in EPEL, but the same package also
exists in CentOS.
--- CentOS5 vs EPEL5
blktrace
c-ares
c-ares-devel
cmake
ctdb
ctdb-devel
dstat
ebtables
fribidi
fribidi-devel
iotop
ldb-tools
libassuan-devel
libldb
libldb-devel
On Tue, 17 Mar 2015 11:34:10 -0600
Stephen John Smoogen smo...@gmail.com wrote:
This was on the packaging list but effects EPEL. Any suggestions?
-- Forwarded message --
From: Thomas Moschny thomas.mosc...@gmail.com
Date: 17 March 2015 at 10:59
Subject: [Fedora-packaging]
On 15/03/15 16:25, David White wrote:
The proftpd package in the EPEL CentOS 7 repo doesn't seem to include
mod_sft.
|[root@blah /]#!
proftpd
-
l
Compiled-in modules:
mod_core.c
mod_xfer.c
mod_rlimit.c
mod_auth_unix.c
mod_auth_file.c
mod_auth.c
mod_ls.c
mod_log.c
On 17/11/14 15:44, Axel S wrote:
Hi all,
It seems like perl-Net-CIDR is not availabe in the Centos 7 EPEL?
Because of this I am not able to install munin-node, whick depends on
perl-Net-CIDR. (also tried with --skip-broken).
I don't know of perl-Net-CIDR has been available before, but I have
On 19/08/14 07:06, Till Maas wrote:
Hi,
there are a lot of orphaned packages in EPEL 5, that should IMHO either
be properly maintained or retired, here is a rough overview:
...
I took perl-DateTime-Format-Mail
Paul.
___
epel-devel mailing list
On 11/03/14 14:59, Dave Johansen wrote:
On Sun, Feb 23, 2014 at 10:22 AM, Kevin Fenzi ke...@scrye.com
mailto:ke...@scrye.com wrote:
On Sun, 23 Feb 2014 18:10:10 +0100
Dominik 'Rathann' Mierzejewski domi...@greysector.net
mailto:domi...@greysector.net wrote:
Hello everyone,
35 matches
Mail list logo
