On 10/23/18 10:30 AM, Neal Gompa wrote:
> On Tue, Oct 23, 2018 at 1:28 PM Jason L Tibbitts III
> wrote:
>>
>>> "OP" == Orion Poplawski writes:
>>
>> OP> - Can we make epel7-py36 branches, and somehow have
>> OP> %python3_version, et. al. be 3.6 for those builds?
>>
>> I can't think of any
> "NG" == Neal Gompa writes:
NG> Wait, we can do that? I thought we couldn't use the exception
NG> process for this?
Well, the idea is that you don't need a separate review just to import a
different version of the same package. So foo and foo1.2 (the 1.2
version) or python-abc and
On Tue, Oct 23, 2018 at 1:28 PM Jason L Tibbitts III wrote:
>
> > "OP" == Orion Poplawski writes:
>
> OP> - Can we make epel7-py36 branches, and somehow have
> OP> %python3_version, et. al. be 3.6 for those builds?
>
> I can't think of any way to do that without extra magic. And if you
>
> "OP" == Orion Poplawski writes:
OP> - Can we make epel7-py36 branches, and somehow have
OP> %python3_version, et. al. be 3.6 for those builds?
I can't think of any way to do that without extra magic. And if you
require something in the spec, you might as well just hardcode it.
OP> - Can
On 10/19/2018 01:22 PM, Stephen John Smoogen wrote:
Hi,
EPEL is a set of packages which work for CentOS and RHEL versions 6
and 7. In the version 7, we are currently using python34 and would
like to move this to python36. In doing so, we need help in both our
packaging rules and in updating a
On Fri, 19 Oct 2018 15:22:01 -0400
Stephen John Smoogen wrote:
> However, this was decided a while ago and it may not be the best
> convention to use or one that the current python sig would like us to
> use. I would like to get a naming convention cleared up and documented
> so when we do a
