[EPEL-devel] Re: New release of Mock (fixes and subscription-manager support)

2019-09-10 Thread Avram Lubkin
On Tue, Aug 27, 2019 at 10:20 AM Miroslav Suchý wrote: > 2) Mock now supports subscription-manager, which allows you to build > packages for RHEL with cost-free developer license. > No need to wait for CentOS 8. > Does this work when using Fedora as the base system? subscription-manager is

[EPEL-devel] Re: Requirements for SRPM names

2016-09-13 Thread Avram Lubkin
On Tue, Sep 13, 2016 at 2:28 PM, Stephen John Smoogen wrote: > > The reasoning for needing a python3-foobaz is that we don't replace > the python2 version of foobaz with a package which does not work at > all with the python2 installed and possibly breaks an existing app. >

[EPEL-devel] Requirements for SRPM names

2016-09-13 Thread Avram Lubkin
I'm looking for some clarification on the naming requirements for SRPMs. In the EPEL 7 in Python 3 Plan Draft [1], it specifies that SRPM names can't conflict with RHEL SRPM names, but in the Limited Arch Packages [2]section of EPEL: Packaging, it seems to imply the SRPM name would be the same,

[EPEL-devel] Re: python34 for EPEL6

2016-08-25 Thread Avram Lubkin
On Wed, Aug 24, 2016 at 8:44 PM, Jason L Tibbitts III wrote: > > To be completely fair, I don't actually know EPEL policy here. The rule > is that you can't conflict with RHEL packages, but SRPMs aren't really > installed the same way as other packages and whether or not they

[EPEL-devel] Re: python34 for EPEL6

2016-08-25 Thread Avram Lubkin
> > Which is an annoying bit of process, but it would be quite possible to > exempt those packages from needing package reviews. It needn't take > that long. > > Not needing reviews would help, but I wonder how hard it would be to make them children of python-PACKAGE. The main issue is the SRPM

[EPEL-devel] Re: python34 for EPEL6

2016-08-25 Thread Avram Lubkin
Definitely, but it runs into the same problem as 3.4 on EL7, the fact that there are few packages available and adding them when the package already exists in RHEL requires creating a separate parent package in Fedora pkgdb. On Wed, Aug 24, 2016 at 5:38 PM, Orion Poplawski

[EPEL-devel] Re: Additional python34 components for epel7

2016-01-19 Thread Avram Lubkin
So what should package maintainers do? I modified a package to use python3_pkgversion and it builds fine if with_python3 is set, but it doesn't seem to be set in the EPEL 7 build environment. I noticed a couple packages enable it by default. Is that what we should be doing? Or should we just build