pinions about this.
Using a NEVR is valid but I do not see it that much, and with the
mentioned patch obviously necessary.
Not sure how to include it in epel-next, though, I don't see any
`epel*-next` branch in NetworkManager-openvpn dist-git. I will need to
read the docs, I guess.
Well, with
9 (via EPEL9-NEXT) if you want ...
--
Leon
--
___
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/projec
The content of this message was lost. It was probably cross-posted to
multiple lists and previously handled on another list.
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le
Of course it isn't correct to be released in EPEL 9 if the dependency
cannot be met by what is currently available in RHEL 9
(NetworkManager-1.46.0-8.el9_4). CentOS Stream 9 has a new enough
version (NetworkManager-1.48.0-1.el9), but it's unlikely for that
build to show up in RHEL 9 until 9.5 is released
epel-testing (epel9) provides a new NetworkManager-openvpn package
that requires NetworkManager >= 1:1.46.2, and that one is currently
not provided by RHEL9. Is this intentional ...?
--
Leon
--
___
epel-devel mailing list -- epel-de
Am 31.05.24 um 15:30 schrieb Troy Dawson:
On Fri, May 31, 2024 at 2:48 AM Peter Soppe <mailto:pe...@soppe.net>> wrote:
Hello EPEL Team,
I am trying to find out how to contact the maintainer of the Oracle
Linux EPEL repository.
The only website I found about EPEL an
Thank you for the followup.
On Thu, Apr 11, 2024 at 7:51 PM David Trudgian via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:
> The singularity-ce incompatible upgrade has now been pushed to stable.
>
> This is the final announcement prescribed by the EPEL Incompatible
&g
The singularity-ce incompatible upgrade has now been pushed to stable.
This is the final announcement prescribed by the EPEL Incompatible Upgrades
Policy:
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
Cheers,
DT
On 9 Feb 2024, at 10:45, David Trudgian wrote
Wow, that was fast! Thanks Jonathan!
Regards,
Evan
From: Jonathan Wright
Sent: Wednesday, April 3, 2024 10:55:40 PM
To: EPEL Development List
Cc: Ward, Evan M CIV USN NRL (8112) Washington DC (USA)
Subject: Re: [EPEL-devel] activemq-cpp in epel8
Managed
viewer will pick it
> up, and if it will build against modern versions of Fedora/RHEL.
>
> On Wed, Apr 3, 2024 at 9:57 AM Ward, Evan M CIV USN NRL (8112) Washington
> DC (USA) via epel-devel wrote:
>
>> Hi,
>>
>> Are there any packagers who would like to package act
and EPEL8 is a 2-6 weeks depending on how quickly a reviewer will pick it
up, and if it will build against modern versions of Fedora/RHEL.
On Wed, Apr 3, 2024 at 9:57 AM Ward, Evan M CIV USN NRL (8112) Washington
DC (USA) via epel-devel wrote:
> Hi,
>
> Are there any packagers who would like t
Hi,
Are there any packagers who would like to package activemq-cpp in
epel8? It's already in epel7.
https://bugzilla.redhat.com/show_bug.cgi?id=2244652
Regards,
Evan Ward
smime.p7s
Description: S/MIME cryptographic signature
--
___
epel-devel
will allow, in the near future.
1. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-226fa082a4
2.
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_other_packages
--
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonat
After approval in the last EPEL meeting [1], I have submitted an incompatible
upgrade of singularity-ce to testing for EPEL 7, 8 & 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-cbd86d2020
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f299fbc570
h
Actually, someone else did that for you:
https://github.com/fedora-infra/bodhi/issues/4737
Not much mind reading! ;-)
Mattia
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le
o.6()(64bit)" and dnf
chooses gpgme1.22 from epel instead gpgme from appstream.
# LANG=C dnf whatprovides "libgpgmepp.so.6()(64bit)"
Last metadata expiration check: 4:43:48 ago on Tue Feb 6 12:21:37 2024.
gpgme1.22pp-1.22.0-1.el9.x86_64 : C++ bindings/wrapper for GPGME
Repo:
usr/lib64/libgpgme.so.11
-> libgpgme.so.11.31.0
-rwxr-xr-x. 1 root root 350864 13. Mai 2022 /usr/lib64/libgpgme.so.11.24.1
# rpm -qf /usr/lib64/libgpgme.so.11
gpgme-1.15.1-6.el9.x86_64
--
Leon
--
___
epel-devel mailing list -- epel
Hello,
I'd like to announce that Bodhi 8.0.2 has been deployed today and brings a
feature which was requested specifically for EPEL: from now on (if everything
works as expected) all builds submitted as buildroot overrides for EPEL9 will
also be tagged as buildroot overrides for EPEL9N
Dear all,
Following advice from Neal elsewhere on this list [1], I’m requesting that the
singularity-ce EPEL packages may be updated to 4.1.0 following the incompatible
upgrade procedure. The justification for the upgrade is that 3.x singularity-ce
is no longer maintained upstream. Note
y packaged at v4.0.3 in Fedora Rawhide, and
>> v.3.11.5 elsewhere (Fedora releases and EPEL).
>>
>> We want to make a v4 available to EPEL users, as many would be interested in
>> it, but I wouldn’t consider it a compatible update because there are some
>> CLI c
(Fedora releases and EPEL).
We want to make a v4 available to EPEL users, as many would be interested in
it, but I wouldn’t consider it a compatible update because there are some CLI
changes, and small behaviour changes.
My understanding is that in order to provide a 4.x in EPEL, without any
cific libexec dir.
Thanks again,
Dave Trudgian
--
___
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/
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 are too old
to work with SingularityCE, and users installing our upstream binary
Hi Dominik, thanks for your reply.
Am 09.01.24 um 10:16 schrieb Dominik 'Rathann' Mierzejewski:
Hello, Leon.
On Monday, 08 January 2024 at 17:18, Leon Fauster via epel-devel wrote:
Hi all,
it seems that VLC is in EPEL9 now. Looks like some license changes
allows packaging some multimedia
Hi all,
it seems that VLC is in EPEL9 now. Looks like some license changes
allows packaging some multimedia stuff now. I noticed also the
new epel-cisco-openh264 repo.
Unfortunately, I'm not involved in the upstream/Fedora discussions.
So, I miss some kind of documentation. A look into Fedoras
.
On 15/12/2023 14:46, Troy Dawson wrote:
The way to stop it from being pushed is to give it negative karma in
it's bodhi testing.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4e7c9d636e
You know what's strange, the updates-testing report that get's
automatically generated, doesn't put
for its parameters in /etc/defaults/wsdd, but
creates them in /etc/sysconfig/wsdd leading to an immediate failure on
start.--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le
ignored and now there has
bee a breaking release. How can we get it fixed and what could I have
done differently to get it fixed prior to release?
Regards,
Nick
--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send
Am 11.12.23 um 20:29 schrieb Neal Gompa:
On Mon, Dec 11, 2023 at 2:19 PM Leon Fauster via epel-devel
wrote:
While updating to EL8.9 I noticed that cloud-utils-growpart is in EPEL
and RHEL8?
cloud-utils-growpart noarch 0.33-0.el8 rhel-8-for-x86_64-appstream-rpms
cloud-utils-growpart noarch
While updating to EL8.9 I noticed that cloud-utils-growpart is in EPEL
and RHEL8?
cloud-utils-growpart noarch 0.33-0.el8 rhel-8-for-x86_64-appstream-rpms
cloud-utils-growpart noarch 0.33-3.el8 epel
Subpackage conflict?
--
Leon
--
___
epel-devel
This wsdd update contains a potential breaking change and systemd
service file errors. I have filed a bug report at
https://bugzilla.redhat.com/show_bug.cgi?id=2253415.
On 07/12/2023 02:43, upda...@fedoraproject.org wrote:
The following Fedora EPEL 7 Security updates need testing:
Age URL
-package and thus has SAML support,
and also in EPEL, where SAML support is indeed missing [2].
I have prepared a perl-lasso-epel spec file to add missing perl bindings
support to EL releases and as this is the first time I go this route,
although the EPEL guidelines states this is a review request
Am 20.11.23 um 21:42 schrieb Leon Fauster:
Am 20.11.23 um 01:38 schrieb Neal Gompa:
On Sun, Nov 19, 2023 at 5:25 PM Leon Fauster via epel-devel
wrote:
Am 19.11.23 um 14:30 schrieb Neal Gompa:
On Sat, Nov 18, 2023 at 4:20 PM Leon Fauster via epel-devel
wrote:
Just noticed that the current
Am 20.11.23 um 01:38 schrieb Neal Gompa:
On Sun, Nov 19, 2023 at 5:25 PM Leon Fauster via epel-devel
wrote:
Am 19.11.23 um 14:30 schrieb Neal Gompa:
On Sat, Nov 18, 2023 at 4:20 PM Leon Fauster via epel-devel
wrote:
Just noticed that the current chromium in epel-testing can
Am 19.11.23 um 14:30 schrieb Neal Gompa:
On Sat, Nov 18, 2023 at 4:20 PM Leon Fauster via epel-devel
wrote:
Just noticed that the current chromium in epel-testing can not be
installed on E9 with rpmfusion repo enabled. All versions before did not
have this problem. It seems the build pulls
Just noticed that the current chromium in epel-testing can not be
installed on E9 with rpmfusion repo enabled. All versions before did not
have this problem. It seems the build pulls a new dep (libavformat-free)
that conflicts with ffmpeg-libs of rpmfusion. This results in an
incompatibility
.
--
___
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
I want it just haven't had a chance to circle back. I saw this email and
glanced back at it but I've been traveling this week.
I'll finish the EPEL request per docs this week and get this rolling.
On Fri, Nov 17, 2023, 09:04 Troy Dawson wrote:
> It looks like Jonathan Wright was the per
Hello,
as per the EPEL package request documentation, I am kindly asking if there are
any packagers who would like to package and maintain qbittorrent on EPEL. The
request has been stalled since February 2023.
https://bugzilla.redhat.com/show_bug.cgi?id=2172281
https://src.fedoraproject.org
t; Thanks-
>
> --
> Lance Albertson
> Director
> Oregon State University | Open Source Lab
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
:51:10AM -0500, Dave Dykstra wrote:
> To Troy and the rest of the EPEL Steering Committee:
>
> Thank you very much for granting the request.
>
> The apptainer maintainers promise to do our best to avoid incompatible
> updates in the future. However if we discover ano
golang-1.19.6 is now available in epel-testing for EPEL7, an update of a
minor version from 1.18.9. I expect it to be promoted in about a week
unless karma changes that.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ba899b9717
My policy for updating golang in EPEL7 is to follow
I posted the below a couple of weeks ago but I don't think it ever came
through. 1.9.6 is now in EPEL7's stable epel repository. Another new
update 1.9.9 is now in EPEL7's epel-testing, since RHEL8 did another
update due to a high severity vulnerability.
https://bodhi.fedoraproject.org/updates
if there was a compatible way to deal with this security
vulnerability, we would have done it.
Dave
On Thu, May 11, 2023 at 10:34:40PM -0500, Carl George wrote:
> Tens of thousands of upstream projects are packaged into Fedora and
> EPEL. If they can find ways to deliver security fixes
e KDE Plasma Desktop. This didn't go well.
> I will be removing the updates from epel-next-testing and starting again
> with just the packages that need a rebuild due to the qt5 update.
>
> I'm sorry for the inconvenience, and appreciate the patience you have
> shown.
>
> Troy
&
Am 15.05.23 um 20:50 schrieb Jonathan Wright:
EPEL tracks RHEL, not clones.
EPEL10 is likely to resolve this, however. Ref
https://discussion.fedoraproject.org/t/epel-10-proposal
<https://discussion.fedoraproject.org/t/epel-10-proposal>
On Mon, May 15, 2023 at 1:31 PM Leon Fauster vi
EPEL tracks RHEL, not clones.
EPEL10 is likely to resolve this, however. Ref
https://discussion.fedoraproject.org/t/epel-10-proposal
On Mon, May 15, 2023 at 1:31 PM Leon Fauster via epel-devel <
epel-devel@lists.fedoraproject.org> wrote:
> Am 10.05.23 um 05:24 schrieb Maxwell G:
>
Am 10.05.23 um 05:24 schrieb Maxwell G:
Hello EPEL users and developers,
RHEL 9.2 was released today,
so I have updated ansible in EPEL 9 from 6.3.0 to 7.2.0 to match RHEL
9.2's ansible-core bump from 2.13.3 to 2.14.2.
Each ansible major version is tied to a specific major version of
ansible
This change has now been approved by the EPEL Steering Committee and
requested to be pushed to stable. I expect it to be in stable sometime
tomorrow.
Dave
On Wed, Apr 26, 2023 at 01:07:32PM -0500, Dave Dykstra wrote:
> The apptainer-suid package version 1.1.8 now in epel-testing
To Troy and the reset of the EPEL Steering Committee:
Thank you very much for granting the request.
The apptainer maintainers promise to do our best to avoid incompatible
updates in the future. However if we discover another high severity
vulnerability in the setuid-root portion that cannot
chines on RHEL 7,8 and 9 to use the same
> version and secure options.
> Users that only have machines on RHEL 8 and 9, would then have the option
> to move to the more secure option when the time is good for them.
>
> Troy
>
> On Fri, May 5, 2023 at 3:30 PM Dave Dykstra via
ess already gives privilege
> escalation in much easier ways. I said that that's probably why they only
> counted it as denial of service since that was the only thing new.
>
> Dave
>
> On Thu, May 04, 2023 at 02:14:08PM +0100, David Trudgian wrote:
> > Dave,
> >
g new.
Dave
On Thu, May 04, 2023 at 02:14:08PM +0100, David Trudgian wrote:
> Dave,
>
> On Wed, May 3, 2023, at 10:31 PM, Dave Dykstra via epel-devel wrote:
> > On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote:
> > > On Thu, Apr 27, 2023 at 10:20
On Wed, May 03, 2023 at 02:48:05PM -0500, Carl George wrote:
> On Thu, Apr 27, 2023 at 9:42 AM Dave Dykstra via epel-devel
> wrote:
> >
> > We believe that it is important to apply this change to all EPEL releases,
> > for these reasons:
> > 1. The general vulne
On Wed, May 03, 2023 at 02:59:42PM -0500, Carl George wrote:
> On Thu, Apr 27, 2023 at 10:20 AM Dave Dykstra via epel-devel
> wrote:
> >
> > On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote:
...
> > > The Red Hat CVSS score for CVE-2022-1184 has the same brea
I learned about CVE-2023-0386, but it was before
publication. I don't know how to get that corrected, but I will try.
> Also, I don't know what the justification is on the GHSA for bumping
> confidentiality / integrity impact, nor changing complexity from low
> -> high versus CVE-2022-11
On Thu, Apr 27, 2023 at 02:11:46AM -0500, Carl George wrote:
> On Wed, Apr 26, 2023 at 11:20 AM Dave Dykstra via epel-devel
...
> > The summary of the CVE is that the way that apptainer & singularity
> > allow mounts of ext3 filesystems in setuid mode raises the severi
On Thu, Apr 27, 2023 at 09:09:57AM +0100, Nick Howitt via epel-devel wrote:
> On 2023-04-27 08:42, Carl George wrote:
...
> > should be modified to set the "allow setuid-mount extfs" option to yes
> > for compatibility, even if that isn't the upstream default.
>
We believe that it is important to apply this change to all EPEL releases,
for these reasons:
1. The general vulnerability described in this CVE applies equally to all
currently supported Linux distributions. The Singularity/Apptainer
community has long been aware that making setuid-root
project's CVE-2023-30549 available here:
https://sylabs.io/2023/04/response-to-cve-2023-30549/
which is likely broader than is relevant for EPEL packaging, but
takes a basic position that CVE-2023-30549 is a duplicate of
CVE-2022-1184 and is a medium severity DoS kernel vuln, and not a high
The apptainer-suid package version 1.1.8 now in epel-testing has an
incompatible change because of a security vulnerability. The change is
that a new option "allow setuid-mount extfs" was added which defaults to
no, preventing ordinary users from mounting ext3 filesystems in
setuid
Dave (Dykstra),
The process is pretty well laid out at
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
I think leaving the package in epel-testing for now is OK but you
definitely need to hold it from release repos until the policy
DT is correct, this change is subject to the EPEL incompatible change
policy. apptainer-suid-1.1.8 by default disables mounting of ext3
filesystems, because of CVE-2023-30549
https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f4cg
Most users don't use this feature
On Fri, 2023-03-17 at 07:09 -0700, Troy Dawson wrote:
> On Fri, Mar 17, 2023 at 6:48 AM Patrick Riehecky
> wrote:
> > On Fri, 2023-03-17 at 06:22 -0700, Troy Dawson wrote:
> > > On Thu, Mar 16, 2023 at 6:31 PM Patrick Riehecky via epel-devel
> > > wrote:
> > &
On Fri, 2023-03-17 at 06:22 -0700, Troy Dawson wrote:
> On Thu, Mar 16, 2023 at 6:31 PM Patrick Riehecky via epel-devel
> wrote:
> > On Thu, 2023-03-16 at 16:05 -0700, Troy Dawson wrote:
> > >
> > >
> > > On Thu, Mar 16, 2023 at 3:43 PM Kevin Fenzi
&g
their NVR's being higher than EPEL's.
If that is so, the EPEL packages don't take precedence over RHEL's.
They may not when you first check. The risk in leaving the branch
active is that a maintainer may bump the version and/or release and
start overriding the RHEL package at any given time. We
gt; > of day) if
> > > you think I need changes.
> > >
> > > Subject:
> > > Notice: will be automatically retired from epel
> > > when RHEL
> > > . is released
> > >
> > > Comment:
> > > Thank you for your work mai
, or semi-automated, so there is a
consistent time when all of them are removed.
That's a good idea.
When do you actually remove the packages from the EPEL repository?
It has been agreed that it will be after both Alma and Rocky have their
latest release out.
Ok, that's good, and should at least avoid
am rebuilds?
>
>
Free or not, the licensing aspect is annoying and that's why many people
still choose rebuilds.
> Just a thought.
>
> Ian
> --
> Ian Laurie
> FAS: nixuser | IRC: nixuser
> TZ: Australia/Sydney
> ________
0
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 bundles on top of the ansible-core
p
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 bundles on top of the
ith newer ansible-core versions.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/They
_______
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.
ould like to avoid the need to maintain tox 3 in EPEL9 for many
> years after
> upstream abandoned it (they have no intention to do maintenance
> releases for
> tox 3.x).
>
> We are currently upgrading to tox 4 in Fedora Rawhide. When the dust
> settles
> I'd like to have th
On Tue Dec 13, 2022 at 16:47 +0100, Leon Fauster via epel-devel wrote:
Hi Leon,
> I noticed that on a RHEL8 workstation the deprecated and removed package
> from EL8.0 - libssh2, does not get substituted by the package from epel:
>
> libssh2-1.8.0-8.module+el8.0.0+4084+cceb9f44.1
I noticed that on a RHEL8 workstation the deprecated and removed package
from EL8.0 - libssh2, does not get substituted by the package from epel:
libssh2-1.8.0-8.module+el8.0.0+4084+cceb9f44.1.x86_64
vs
libssh2-1.9.0-5.el8.x86_64
only possible with
yum update libssh2 --disablerepo=rhel-8
Hi,
I intended to update novnc in EPEL7 to version 1.3.0 from 0.5.1. I am
posting this here per EPEL policy and I've also posted an issue at
https://pagure.io/epel/issue/212 for discussion and the meeting agenda.
I recently took the novnc package which was orphaned and I'm trying to get
On Mon Dec 5, 2022 at 21:52 +0100, Jitka Plesnikova wrote:
> Could be the following file added to the package epel-rpm-macros (or
> anything like this) for EPEL 9?
It could, but it might be better to include this in a subpackage of
epel-rpm-macros or as a separate perl-generators-epel com
golang-1.18.4 is now available in epel-testing for EPEL7, an update of a
minor version from 1.17.12. I expect it to be promoted in about a week
unless karma changes that.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-96dbad9cd3
My policy for updating golang is to follow
Hi John,
On Sun Nov 27, 2022 at 08:51 +, john tatt via epel-devel wrote:
> Hi everyoneI'll like to have Compiz / Emerald available on RHEL/Rocky aso
>
> is there a chance for this to happen ?
> Thank you
Please follow the standard EPEL Package Request[1] procedure and let us
Hi everyoneI'll like to have Compiz / Emerald available on RHEL/Rocky aso
is there a chance for this to happen ?
Thank you
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le
On Wed Nov 23, 2022 at 00:52 CST, Carl George wrote:
> I would also ask that feedback be provided there instead of as email
> replies here on the list.
I don't think there's been a formal discussion about moving EPEL
discussions over to the forums. We already have communication split
b
EPEL Maintainers,
It appears the update to pypolicyd-spf-2.9.3 from pypolicyd-spf-2.0.x
crashes Postfix unexpectedly. Perhaps a missing dependency? Seems to be
ahead from what I assume the upstream is, pip. Is this an error?
Installing authres via pip was able to fix things without installing
On 01/11/2022 18:36, Stephen Smoogen wrote:
On Tue, 1 Nov 2022 at 13:44, Nick Howitt via epel-devel
<mailto:epel-devel@lists.fedoraproject.org>> wrote:
On 01/11/2022 15:46, Tuomo Soini wrote:
> On Tue, 1 Nov 2022 10:50:02 +
> Nick Howitt via epel-de
On 01/11/2022 15:46, Tuomo Soini wrote:
On Tue, 1 Nov 2022 10:50:02 +
Nick Howitt via epel-devel wrote:
Yesterday, ClamAV announced CVE-2022-37434 as critical
(https://blog.clamav.net/2022/10/new-packages-for-clamav-01037-01044.html).
Redhat only seem to classify the issue as Moderate
On 01/11/2022 11:57, Stephen Smoogen wrote:
On Tue, 1 Nov 2022 at 07:48, Andrew C Aitchison
wrote:
On Tue, 1 Nov 2022, Stephen Smoogen wrote:
> On Tue, 1 Nov 2022 at 06:59, Nick Howitt via epel-devel <
> epel-devel@lists.fedoraproject.org> wrote:
>
it as Critical, zlib and zlib-devel won't
get updated so ClamAV can't be rebuilt against the updated zlib-devel.
What is the EPEL take on the issue?___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le
On 21/10/2022 23:53, Todd Zullinger wrote:
manuel wolfshant wrote:
On 10/22/22 00:22, Troy Dawson wrote:
distribution-gpg-keys-1.78-1.el7 is currently in testing.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-318362b0c0
You can get things moving my using the epel-testing repo
Am 21.10.22 um 17:11 schrieb Troy Dawson:
...
== Transition Steps
=== 1 - Verify that you are using an EPEL 8 Module
dnf list installed | grep epel-modular
If nothing shows up, great, you are done.
just wanted to add:
dnf list installed | grep epel-testing-modular
--
Leon
Thanks, Troy. I will send a message to epel-announce.
I looked through the last couple of years of epel-announce archives and
don't see similar messages. I have a hard time imagining that somewhat
incompatible changes aren't happening to other packages too, so it seems
that such announcements
Hello all,
It is been pointed out to me that I pushed out an update of a package to
EPEL that did not follow the incompatible upgrades policy:
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
That's because I wasn't aware of the policy until it was pointed out to
me
an update
--> Processing Dependency: distribution-gpg-keys >= 1.77 for package:
mock-core-configs-36.13-1.el7.noarch
--> Finished Dependency Resolution
Error: Package: mock-core-configs-36.13-1.el7.noarch (epel-unverified)
Requires: distribution-gpg-keys >= 1.77
In
: He/Him/His
signature.asc
Description: PGP signature
___
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/
nature
___
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:
ed message -
>> From: metatron...@yahoo.com
>> Date: Sun, 18 Sept 2022 at 20:01
>> Subject: xscreensaver package for epel9 (Bugzilla 2120163)
>> To: epel-devel-ow...@lists.fedoraproject.org <
>> epel-devel-ow...@lists.fedoraproject.org>
>>
&g
Am 24.05.22 um 19:53 schrieb Maxwell G via epel-devel:
On Monday, May 23, 2022 11:18:38 PM CDT Orion Poplawski wrote:
I've been coming to the thinking that naming the SRPMS
python3X-%{srcname}-epel is a better choice. This makes modifying
original Fedora specs simpler.
I think that makes
On Friday, September 9, 2022 Christopher Engelhard wrote:
> I found it useful to ship the nextcloud package as a module, particularly in
> EPEL, but if after multiple years there really are only 12 packages in the
> repo and even those may or may not work then that is a pretty clear
&
)
Pronouns: He/Him/His
signature.asc
Description: PGP signature
___
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
On Monday, September 5, 2022 Mark E. Fuller wrote:
> Can someone point me to a good resource on how (if permitted) I can make
> appropriate compat(?) packages to allow for two major versions of the
> same package to be available?
> Is this allowed for EPEL?
You can package compat pack
On Mon, 2022-09-05 at 11:33 +0200, Dominik 'Rathann' Mierzejewski
wrote:
> It would be really nice if the wording of the bug could contain some
> kind of a "thank you" note to the EPEL maintainers of the package in
> question. Not everyone will understand this process as "
On Sat, 2022-09-03 at 13:39 -0500, Richard Shaw wrote:
> Have you tried building the package yourself yet? When asking for
> someone to support an EPEL branch it's not always straightforward. I
> tried building the rawhide branch for EPEL 9 and ran into the
> following:
>
> N
1 - 100 of 360 matches
Mail list logo
