Re: EPEL CentOS curator group proposal

[Ken Dreyer]

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 within CentOS is needed.

 It is defined. It's also perceived as cumbersome, laborious and painful,
 and so many would-be contributors don't even attempt to contribute. This
 is simply a proposal allowing those who are willing to act in place of
 the original packagers to help contribute.

 If the packages are going to meet Fedora's guidelines, the current
 process is not as bad as it might be perceived. If someone is qualified
 and motivated it is very easy to become package maintainer and if you
 have several people who want to contribute they can easily review each
 others packages to show that they are qualified and I am very confident
 that it won't be hard to find a sponsor then.

The other thing that comes to my mind is some sort of EPEL
ambassadors (for lack of a better term) - Fedora packagers who are
interested in sponsoring new contributors who are very EPEL-focused.
I'd be willing to help with that.

I get that it can feel cumbersome, laborious and painful sometimes,
particularly in comparison to throwing something on GitHub. The big
question for Fedora's future is how do we become less bureaucratic
while still maintaining quality - and do it in a timeframe that still
keeps us relevant to the world.

Anyways, in the meantime there are are people here who are willing to
do some hand-holding through our current processes.

- Ken
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[EPEL-devel] EPEL-ANNOUNCE Fwd: intent to retire cacti

[Ken Dreyer]

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...@lists.fedoraproject.org

Hi folks,

Cacti is a PHP monitoring program that has been showing its age for a while now.

There are numerous CVEs relating to XSS and SQL injection that
upstream has patched in SVN but are not available in any tagged
release, and this has been the case for several months.

More recently, another round of vulnerabilities have come out that
upstream has not even officially patched in their SVN repository:

- CVE-2014-2327 (CSRF),
- CVE-2014-5025 (stored XSS),
- CVE-2014-5026 (more stored XSS),
- CVE-2014-5261 (shell metacharacters),
- CVE-2014-5262 (SQL injection)

I think Debian is carrying its own custom patches for some these.

Since Fedora's already carrying a large-ish patch to remove Cacti's
non-free Javascript bits, the fact that upstream is showing further
signs of dying makes me doubt the feasibility of keeping this package
in the distro. I'm planning to retire the package altogether.

Because of the continued security problems in the project, I would
already advise against anyone running vanilla Cacti from upstream. I'm
now at the point where I'd advise anyone from running it altogether,
even the distro packages. Zenoss, XYMon, Nagios, and Icinga are all
viable replacements.

Jon Ciesla is the official point of contact for Cacti in pkgdb, and he
and I are in agreement that we should retire this package.

Cacti is still present in EPEL 5, 6, and 7, and I really dislike
destabilizing EPEL if I can help it. I don't know if I can make time
to patch the above CVEs, so we may need to retire it in EPEL too. If
you're using Cacti, now is the time to move onto something else.

- Ken
___
epel-announce mailing list
epel-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-announce
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] epel install nginx error

[Ken Dreyer]

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 yum install nginx

You can read the debug.log file and figure out which EPEL mirror was used.

You can then manually exclude this mirror in
/etc/yum/pluginconf.d/fastestmirror.conf. Open up that file and set
the exclude variable to the URL you wish to avoid.

  exclude = mymirror.example.com

Please let us know which mirror is far behind as well, so we can
investigate. If it's a big problem, we could possibly pull them from
Fedora's MirrorManager.

- Ken
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Tinyproxy and EPEL 7

[Ken Dreyer]

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
 6.
 Also I have noted that the 'tinyproxy' package is still present in the
 last version of Fedora, so I was wondering why is not present in the
 repository of Centos 7.



 This is a Frequently Asked Question...

You're quite right, I see this a lot on IRC.

I've added Why isn't a package in EPEL-7 when it is in EPEL-6?  to
the EPEL FAQ page
(https://fedoraproject.org/w/index.php?title=EPEL%2FFAQdiff=398561oldid=398091)

- Ken
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] broken PPC64 libxml2-devel?

[Ken Dreyer]

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
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] broken PPC64 libxml2-devel?

[Ken Dreyer]

I attempted two new builds, and each failed on ppc64 with the same
libxml2-devel error :(

http://koji.fedoraproject.org/koji/taskinfo?taskID=9395052 is the latest one.

What can I try next?

- Ken

On Wed, Apr 1, 2015 at 10:02 AM, Kevin Fenzi ke...@scrye.com wrote:
 On Wed, 01 Apr 2015 16:38:45 +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
  util.py:388: Requires: libxml2.so.2 DEBUG
  util.py:388:   You could try using --skip-broken to work around the
  problem DEBUG util.py:388:   You could try running: rpm -Va
  --nofiles --nodigest
 
  Is this a problem in EPEL, or in RHEL?

 libxml2 is an RHEL package, not an EPEL one. EPEL has libxml++ but
 not libxml2.

 Likely this was/is due to a problem we are having with kojira (which is
 the part of koji that notices new packages for a buildroot and fires
 off newrepo tasks to update it).

 There should have been a newrepo for el6 this morning a bit ago tho, so
 please do retry your build.

 kevin

 ___
 epel-devel mailing list
 epel-devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/epel-devel

___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[EPEL-devel] orphaning perl-MongoDB

[Ken Dreyer]

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
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] I need a copy of mod_security-2.5.12-2.el6.x86_64

[Ken Dreyer]

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 ModSecurity before 2.7.6 allows remote
attackers to bypass rules by using chunked transfer coding with a
capitalized Chunked value in the Transfer-Encoding HTTP header.

CVE-2013-2765
The ModSecurity module before 2.7.4 for the Apache HTTP Server allows
remote attackers to cause a denial of service (NULL pointer
dereference, process crash, and disk consumption) via a POST request
with a large body and a crafted Content-Type header.

CVE-2013-1915
ModSecurity before 2.7.3 allows remote attackers to read arbitrary
files, send HTTP requests to intranet servers, or cause a denial of
service (CPU and memory consumption) via an XML external entity
declaration in conjunction with an entity reference, aka an XML
External Entity (XXE) vulnerability.

CVE-2012-4528
The mod_security2 module before 2.7.0 for the Apache HTTP Server
allows remote attackers to bypass rules, and deliver arbitrary POST
data to a PHP application, via a multipart request in which an invalid
part precedes the crafted data.

CVE-2012-2751
ModSecurity before 2.6.6, when used with PHP, does not properly handle
single quotes not at the beginning of a request parameter value in the
Content-Disposition field of a request with a multipart/form-data
Content-Type header, which allows remote attackers to bypass filtering
rules and perform other attacks such as cross-site scripting (XSS)
attacks. NOTE: this vulnerability exists because of an incomplete fix
for CVE-2009-5031.

- Ken

On Fri, Nov 6, 2015 at 9:02 AM, Athmane Madjoudj
 wrote:
> Hi,
>
> On Fri, Nov 6, 2015 at 1:25 PM, Harriman, Chad (SAA)
>  wrote:
>>
>> I have the repo for EPEL synced on my satellite server and the upgrade to
>> 2.7 broke.  I need to downgrade but I do not have the
>> mod_security-2.5.12-2.el6.x86_64 package.
>> How do I obtain a copy to downgrade?
>
>
> I guess, you could rebuild EL5 package (it's 2.6.8 + security pacthes),
> rules for 2.5 should run fine with 2.6.x.
>
> AFAIK, we don't keep the old version of the package in the repo.
>
>
> Best regards.
>
> -- Athmane
>
> ___
> epel-devel mailing list
> epel-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/epel-devel
>
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[EPEL-devel] Re: Improving EPEL updates process

[Ken Dreyer]

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 update to stable if
it's received no feedback for 90 days?

Often I'll let my update sit in epel-testing for a long time because I
want to give users a large window of opportunity to test the update.
It's not that it's abandoned, it's just that it's not an urgent
update, so why rush it? If the update hits the karma threshold earlier
than I expected, so much the better.

- Ken
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Improving EPEL updates process

[Ken Dreyer]

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 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 update to stable if
>> it's received no feedback for 90 days?
>
> No, because on two of the 3 I referenced there was bad karma and no
> response from the "maintainer" to the feedback.

Oh, if there's negative karma I think it should be unpushed. I was
envisioning a scenario where there's zero karma.

>> Often I'll let my update sit in epel-testing for a long time because I
>> want to give users a large window of opportunity to test the update.
>> It's not that it's abandoned, it's just that it's not an urgent
>> update, so why rush it? If the update hits the karma threshold earlier
>> than I expected, so much the better.
>
> I think 90 days is enough to let people test it, ultimately the
> maintainer should have done the testing and know the vast majority of
> it is good, it should be more to get non standard use cases, corner
> cases etc.

Ideally that's the case, but I maintain several packages that I no
longer have the capacity to test on old RHEL versions :(

- Ken
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: EPEL Proposal #1: Rechartering

[Ken Dreyer]

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) I'd like to see
> "most" incompatible upgrades happen at that time - with some kind of release
> notes where I can read about the changes before.
>
> Ideally I have some time (e.g. a month or so) to schedule the upgrade and deal
> with any fall-out.

I'm curious, do you test updates that are going through epel-testing?

- Ken
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Exception request: major version bump for Nginx

[Ken Dreyer]

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
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: update Ceph to 12.1.1 in epel7 ?

[Ken Dreyer]

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 Ceph to EPEL? Anyone in the packagers
FAS group could do it without checking around, right?

- Ken
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Dummy python2 packages submitted

[Ken Dreyer]

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.
>
> Please test and give karma.  Thanks,
>
>  - J<
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: python2-jenkins-job-builder package version

[Ken Dreyer]

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 but you would still need to ask.

I've always thought it's the other way around, that EPEL moves faster
than RHEL, but you're making me think there's gotta be a story behind
this comment! :D

- Ken
___
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/VDGTCBYPUTV6NII4Z4SZCKCEL4U4LUOQ/

[EPEL-devel] Re: python2-jenkins-job-builder package version

[Ken Dreyer]

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 guess I don't
> understand what you're trying to say.
>
> I said that EPEL maintainers aren't generally as reluctant as Red Hat
> would be to update something.  So they are more likely to update than
> Red Hat would.  Which implies that EPEL moves faster than RHEL.

My bad Jason, I got mixed up when I read your earlier comment there. I
see now we're in agreement.

- Ken
___
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/WCA2VFSFA3OFBET5Y7STG6PH3QEPCXW6/

[EPEL-devel] EPEL and RHEL High Availability / Resilient Storage

[Ken Dreyer]

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" add-ons
of RHEL, not the usual RHEL Base/Optional/Extras.

This means that CentOS 7 really includes the RHEL 7 HA and RS products.

This also means that some EPEL 7 packages cannot install without these
repos enabled on RHEL, see eg.
https://bugzilla.redhat.com/show_bug.cgi?id=1674764

Should EPEL's documentation include these two repos?
https://fedoraproject.org/wiki/EPEL
___
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: EPEL and RHEL High Availability / Resilient Storage

[Ken Dreyer]

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:
> >
> > 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" add-ons
> > of RHEL, not the usual RHEL Base/Optional/Extras.
> >
> > This means that CentOS 7 really includes the RHEL 7 HA and RS products.
> >
> > This also means that some EPEL 7 packages cannot install without these
> > repos enabled on RHEL, see eg.
> > https://bugzilla.redhat.com/show_bug.cgi?id=1674764
> >
> > Should EPEL's documentation include these two repos?
> > https://fedoraproject.org/wiki/EPEL
>
> Well, we have:
>
> https://fedoraproject.org/wiki/EPEL/FAQ#Does_EPEL_replace_packages_provided_within_Red_Hat_Enterprise_Linux_or_layered_products.3F
>
> I am not sure this belongs on the front page... but it might be nice to
> be more visible yeah.

Cool, thanks for the confirmation! My teammates and I have hit this a
couple times unfortunately.

I've edited the front EPEL wiki page to instruct RHEL users to enable
the HA repo in addition to Optional and Extras.

- Ken
___
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] "python3" vs "python%{python3_pkgversion}"

[Ken Dreyer]

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 introducing a Python 3 subpackage in a new build today, should
I name this sub-package "python3-foo" or
"python%{python3_pkgversion}-foo" ?

- Ken
___
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: "python3" vs "python%{python3_pkgversion}"

[Ken Dreyer]

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 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 introducing a Python 3 subpackage in a new build today, should
> > I name this sub-package "python3-foo" or
> > "python%{python3_pkgversion}-foo" ?
> >
>
> The subpackage should be "python%{python3_pkgversion}-foo" and you
> should also make sure you have "%{?python_provide:%python_provide
> python%{python3_pkgversion}-foo}" in the subpackage declaration too.

This is confusing to me, and it diverges from what Fedora does. Can we
just reduce this down to "python3-" now that RHEL 7 has python3, and
we'll probably never put another Python version into EPEL 7?

- Ken
___
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

[Ken Dreyer]

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
>   compatibility needs. These MUST NOT be the default stream -- in every
>   case, explicit user action must be required to opt in to these versions.

Is there any chance that a module in EPEL 8 will be named identically
to a module in RHEL 8? If that happens, what is the process to choose
between RHEL's module and EPEL's module?

This is not entirely hypothetical :) We face this situation if we
consider putting Ceph into a module in RHEL 8 and a module in EPEL 8.

- Ken
___
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: Modules again

[Ken Dreyer]

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 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  wrote:
> > > >
> > > > > On Tue, 19 May 2020 at 06:05, Paul Howarth 
> > > > > wrote:
> > > >
> > > > Yes, I'm using vanilla configs straight from mock-core-configs for
> > > > this, and that has epel-8-x86_64.cfg, which pulls in centos-8.tpl,
> > > > which has the PowerTools repo defined and not disabled.
> > > >
> > > > (I generally use my own configs and don't touch the original
> > > > ones, so I know that if I try the original ones from upstream
> > > > then they should work as intended)
> > > >
> > > > Note that the error message doesn't say it can't find Judy-devel,
> > > > it says that it (and Judy) is/are excluded. I don't know why that
> > > > is.
> > > >
> > > >
> > > Ohhh sorry. I missed the obvious. I am going to guess from past
> > > problems, the system is trying to pull in mariadb which filters it
> > > out and mariadb-devel which has it in. So when it sees the filters
> > > it says 'nope can't do this sorry'. I wish there was a 'no I know
> > > it might break my system do it anyway!' flag but I don't see one
> > > looking through /usr/share/doc/mock/site-defaults.cfg . This was
> > > one of the reasons for grobisplitter being used.
> >
> > You should be able to set:
> >
> > module_hotfixes = True
> >
> > in your dnf/yum/mock config.
> >
> > From the dnf man page:
> >
> > "Set this to True to disable module RPM filtering and make all RPMs
> > from the repository available. The default is False.  This allows
> > user to create a repository with cherry-picked hotfixes that are
> > included in a package set on a modular system."
>
> Ah, setting that option for the PowerTools repo allows the build to
> work. Now if only there was a way to do that from the command line so I
> didn't have to touch the mock config.
>
> Thanks!
>
> Paul.
> ___
> 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 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

[Ken Dreyer]

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 epel8-next dist-git branch)
> > - opt-in for users (part of epel-release but disabled by default)
> > - used *with* epel8, not *instead of*
> >
> I agree with all of that. I only don't like the name. Why EPEL 8 Next? If
> it
> is to be use with Stream, why don't we call it EPEL 8 Stream? I think the
> meaning of the repository would be easier to understand.
>

I was thinking the same thing. EPEL stream is so much easier for users to
understand.

- Ken

>
___
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: Where should branch requests be filed?

[Ken Dreyer]

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 about pre-loading too much reminded me of
https://github.com/python-bugzilla/python-bugzilla/issues/49 . I think
some of those things might be historical accidents from earlier
Bugzilla APIs that did not give all the information we needed.

- Ken
___
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] python-gevent and pytest-cov in el9

[Ken Dreyer]

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 with scripts at
https://github.com/ktdreyer/ceph-el9. My conclusion is that it is so
painful that it's not sustainable to do this for years.)

This means that python-pytest-cov and python-pytest-xdist won't be
available on epel9, since those require gevent.

Several Python packages require python-pytest-cov because upstream
lists it in requirements.txt or tests-requirements.txt. I think we
should just patch these out in Fedora. Even apart from RHEL's
restrictions, it's not a good use of resources to run pytest-cov when
no one reviews coverage reports in the Koji logs, and we'll speed up
builds when mock doesn't have to install this spurious BuildRequires.

Here are a list of packages where I've removed pytest-cov:

https://src.fedoraproject.org/rpms/python-watchdog/pull-request/4
https://src.fedoraproject.org/rpms/python-cheroot/pull-request/15
https://src.fedoraproject.org/rpms/python-portend/pull-request/5
https://src.fedoraproject.org/rpms/python-typing-extensions/pull-request/3

- Ken
___
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: python-gevent and pytest-cov in el9

[Ken Dreyer]

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 other hand, this points at the bigger issue that dealing with
the entire problem of missing packages requires a level of scripting
and bookkeeping that is very difficult to keep up when building
layered projects.

> You could request libev-devel in the composes.

The reason I did not do that in this case is that pytest-cov is an
optional dependency, and we can just remove it from the Python
packages instead. I'd rather reduce the dependencies on gevent to make
everything faster.

When I looked at gevent in EPEL 8 a month or so ago, it did not look
like many packages depended on it.

> I remain confused why
> it has to be in the compose though, because libev and it's devel
> package are accessible in the CentOS Stream 9 buildroots today.

We could point at
https://kojihub.stream.centos.org/kojifiles/repos/c9s-build/latest/ ,
but that location will not have GPG-signed builds, and the repo is not
currently in 
https://github.com/rpm-software-management/mock/blob/main/mock-core-configs/etc/mock/templates/centos-stream-9.tpl

- Ken
___
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: python-gevent and pytest-cov in el9

[Ken Dreyer]

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't the gevent dependency 
> does
> not exsist:

You're right, gevent is not a runtime requirement. pytest-xdist
requires execnet, but execnet only BuildRequires gevent for the unit
tests. So we could build execnet on el9 if we disabled %check and the
"execmodel=gevent" feature. Maybe that's fine, since
https://github.com/pytest-dev/execnet is almost unmaintained upstream,
and users have opened unaddressed GitHub tickets in execnet and xdist
regarding gevent hangs.

This is another reason why I want to reduce Fedora's dependence on
pytest-xdist and pytest-cov, if execnet is growing more unstable.

- Ken
___
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] recent failures with "fedpkg mockbuild" for epel8

[Ken Dreyer]

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
https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64/RHEL-8-001/non_modular/audit-libs-3.0-0.17.20191104git1c2f876.el8.x86_64.rpm
(IP: 38.145.60.16)

I'm using mock-2.16-1.fc34 and fedpkg-1.41-2.fc34

What should I do to mock-build EPEL 8 packages locally with fedpkg?

- Ken
___
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: python311-dnf for el8 and el9

[Ken Dreyer]

Thanks for the replies. I studied the implementation in
python3.11-rpm, and I used that same technique to package
python3.11-dnf for EPEL 8 and 9.

https://copr.fedorainfracloud.org/coprs/ktdreyer/python3.11/

There's a tight dependency on libdnf in RHEL 8.8 and 9.2. I'll have to
see how difficult this is to keep in sync with those RHEL packages.

Also, thanks Troy for recently packaging python3.11-gpg for EPEL 9.
I'd originally ported the python3-gpg 1.15.1 version from RHEL 9, but
yours is newer (1.22.0), so I deleted my version.

- Ken

On Sun, Oct 8, 2023 at 11:01 AM Miro Hrončok  wrote:
>
> 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.
> >
> > I haven't looked into this yet. Has anyone else looked at it?
> >
> > I think I'll need something like
> > https://src.fedoraproject.org/rpms/python3-rpm/c/966f38637a7f51376e57b7aeb19a872986a39b8a
> > , but for a "python3-dnf" package?
> >
> > (By the way, thanks Python team for python3.11 in RHEL 8 and 9. That
> > is helpful for moving workloads across RHEL versions and helping the
> > Python ecosystem move forward. And thank you Miro for python311-rpm!)
>
> Hello.
>
> Packaging python3.11-dnf for EPEL 8 and 9 should be trivial,
> but it's not a single package.
>
> $ repoquery -q --repo=c9s-baseos --requires python3-dnf --latest=1 | grep 
> python
> /usr/bin/python3.9
> python(abi) = 3.9
> python3-gpg
> python3-hawkey >= 0.66.0
> python3-libcomps >= 0.1.8
> python3-libdnf
> python3-libdnf >= 0.66.0
> python3-rpm >= 4.14.0
>
> We would need to package (at least) 4 packages:
>
> python3.11-gpg (gpgme)
> python3.11-hawkey and python3.11-libdnf (libdnf)
> python3.11-libcomps (libcomps)
> python3.11-dnf (dnf)
>
> There's also a possible usage of the gi.Modulemd module from libmodulemd , but
> I've only been able to grep that in tests :/
>
> Reproducing the approach from python3-rpm should work, but I haven't tried it.
> I am not able to commit myself to maintaining the dnf stack in EPEL for couple
> years.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] python311-dnf for el8 and el9

[Ken Dreyer]

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
https://src.fedoraproject.org/rpms/python3-rpm/c/966f38637a7f51376e57b7aeb19a872986a39b8a
, but for a "python3-dnf" package?

(By the way, thanks Python team for python3.11 in RHEL 8 and 9. That
is helpful for moving workloads across RHEL versions and helping the
Python ecosystem move forward. And thank you Miro for python311-rpm!)
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue