11:36 a.m.
On 13.8.2018 11:49, Larry Hastings wrote on python-dev(a)python.org:
We of the core dev community commit to supporting Python releases
for
five years. Releases get eighteen months of active bug fixes, followed
by three and a half years of security fixes. Python 3.4 turns 5 next
March--at which point we'll stop supporting it, and I'll retire as 3.4
release manager.
My plan is to make one final release on or around its fifth birthday
containing the last round of security fixes. That's about seven
months from now.
See also PEP 429 -- Python 3.4 Release Schedule [0].
We have python34 and python36 in EPEL7. python34 being the "main" one
and python36 the "other" one. The original plan [1] was that once the
ecosystem is adapted well enough, we can switch what "main" and
"other"
is and eventually drop python34, creating room for maybe another python3
release to be the "other" next (python38 maybe?). Originally this was
supposed to happen for each release [2], but this was later abandoned
due to lack of manpower.
Do we want to ever switch "main" with "other"? The problem here is:
$ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.4' |
pkgname | sort | uniq | wc -l
243
$ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.6' |
pkgname | sort | uniq | wc -l
15
The original idea is that all packages would have the python3_other
macros in them [2] and all we need is rebuild everything in proper
order, maybe with some bootstrapping. However that never happened and
most of the packages I've seen lack the python3_other bits (no
statistics, just my impression).
Is this something we want? If so, are the packagers willing to adapt
their packages (as much as I'd like to do this, I lack the resources to
hack on 228 packages)?
The Python Maint team in Red Hat is here to help. However the drive
would need to come from the EPEL community, as now we are only guessing
what are the needs here.
[0] https://www.python.org/dev/peps/pep-0429/
[1]
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...
[2] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:27 p.m.
On Tue, 21 Aug 2018 at 13:24, Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 13.8.2018 11:49, Larry Hastings wrote on python-dev(a)python.org:
> We of the core dev community commit to supporting Python releases for
> five years. Releases get eighteen months of active bug fixes, followed
> by three and a half years of security fixes. Python 3.4 turns 5 next
> March--at which point we'll stop supporting it, and I'll retire as 3.4
> release manager.
>
> My plan is to make one final release on or around its fifth birthday
> containing the last round of security fixes. That's about seven
> months from now.
See also PEP 429 -- Python 3.4 Release Schedule [0].
We have python34 and python36 in EPEL7. python34 being the "main" one
and python36 the "other" one. The original plan [1] was that once the
ecosystem is adapted well enough, we can switch what "main" and
"other"
is and eventually drop python34, creating room for maybe another python3
release to be the "other" next (python38 maybe?). Originally this was
supposed to happen for each release [2], but this was later abandoned
due to lack of manpower.
Do we want to ever switch "main" with "other"? The problem here is:
$ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.4' |
pkgname | sort | uniq | wc -l
243
$ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.6' |
pkgname | sort | uniq | wc -l
15
The original idea is that all packages would have the python3_other
macros in them [2] and all we need is rebuild everything in proper
order, maybe with some bootstrapping. However that never happened and
most of the packages I've seen lack the python3_other bits (no
statistics, just my impression).
Is this something we want? If so, are the packagers willing to adapt
their packages (as much as I'd like to do this, I lack the resources to
hack on 228 packages)?
The Python Maint team in Red Hat is here to help. However the drive
would need to come from the EPEL community, as now we are only guessing
what are the needs here.
Understood. What are the groups initial recommendations for us to
follow? I agree we need to have this done this fall/winter. [AKA I
would like to say python34 will be removed by whatever EL7.x release
comes out next.]
--
Stephen J Smoogen.
12:56 p.m.
On 21.8.2018 19:27, Stephen John Smoogen wrote:
On Tue, 21 Aug 2018 at 13:24, Miro Hrončok
<mhroncok(a)redhat.com> wrote:
>
> On 13.8.2018 11:49, Larry Hastings wrote on python-dev(a)python.org:
> > We of the core dev community commit to supporting Python releases for
> > five years. Releases get eighteen months of active bug fixes, followed
> > by three and a half years of security fixes. Python 3.4 turns 5 next
> > March--at which point we'll stop supporting it, and I'll retire as
3.4
> > release manager.
> >
> > My plan is to make one final release on or around its fifth birthday
> > containing the last round of security fixes. That's about seven
> > months from now.
>
> See also PEP 429 -- Python 3.4 Release Schedule [0].
>
> We have python34 and python36 in EPEL7. python34 being the "main" one
> and python36 the "other" one. The original plan [1] was that once the
> ecosystem is adapted well enough, we can switch what "main" and
"other"
> is and eventually drop python34, creating room for maybe another python3
> release to be the "other" next (python38 maybe?). Originally this was
> supposed to happen for each release [2], but this was later abandoned
> due to lack of manpower.
>
> Do we want to ever switch "main" with "other"? The problem here
is:
>
> $ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.4' |
> pkgname | sort | uniq | wc -l
> 243
>
> $ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.6' |
> pkgname | sort | uniq | wc -l
> 15
>
> The original idea is that all packages would have the python3_other
> macros in them [2] and all we need is rebuild everything in proper
> order, maybe with some bootstrapping. However that never happened and
> most of the packages I've seen lack the python3_other bits (no
> statistics, just my impression).
>
> Is this something we want? If so, are the packagers willing to adapt
> their packages (as much as I'd like to do this, I lack the resources to
> hack on 228 packages)?
>
> The Python Maint team in Red Hat is here to help. However the drive
> would need to come from the EPEL community, as now we are only guessing
> what are the needs here.
Understood. What are the groups initial recommendations for us to
follow? I agree we need to have this done this fall/winter. [AKA I
would like to say python34 will be removed by whatever EL7.x release
comes out next.]
I'd start untangling the deps and getting the following in:
* six (looking at that one now)
* pytest
* Cython
* PyYAML
* pip
* attrs
* requests
* mock
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1:06 p.m.
On 21.8.2018 19:56, Miro Hrončok wrote:
On 21.8.2018 19:27, Stephen John Smoogen wrote:
> On Tue, 21 Aug 2018 at 13:24, Miro Hrončok <mhroncok(a)redhat.com> wrote:
>>
>> On 13.8.2018 11:49, Larry Hastings wrote on python-dev(a)python.org:
>> > We of the core dev community commit to supporting Python releases
>> for
>> > five years. Releases get eighteen months of active bug fixes,
>> followed
>> > by three and a half years of security fixes. Python 3.4 turns 5
>> next
>> > March--at which point we'll stop supporting it, and I'll retire
>> as 3.4
>> > release manager.
>> >
>> > My plan is to make one final release on or around its fifth birthday
>> > containing the last round of security fixes. That's about seven
>> > months from now.
>>
>> See also PEP 429 -- Python 3.4 Release Schedule [0].
>>
>> We have python34 and python36 in EPEL7. python34 being the "main" one
>> and python36 the "other" one. The original plan [1] was that once the
>> ecosystem is adapted well enough, we can switch what "main" and
"other"
>> is and eventually drop python34, creating room for maybe another python3
>> release to be the "other" next (python38 maybe?). Originally this was
>> supposed to happen for each release [2], but this was later abandoned
>> due to lack of manpower.
>>
>> Do we want to ever switch "main" with "other"? The problem
here is:
>>
>> $ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.4' |
>> pkgname | sort | uniq | wc -l
>> 243
>>
>> $ dnf repoquery --repo=epel7 --whatrequires 'python(abi) = 3.6' |
>> pkgname | sort | uniq | wc -l
>> 15
>>
>> The original idea is that all packages would have the python3_other
>> macros in them [2] and all we need is rebuild everything in proper
>> order, maybe with some bootstrapping. However that never happened and
>> most of the packages I've seen lack the python3_other bits (no
>> statistics, just my impression).
>>
>> Is this something we want? If so, are the packagers willing to adapt
>> their packages (as much as I'd like to do this, I lack the resources to
>> hack on 228 packages)?
>>
>> The Python Maint team in Red Hat is here to help. However the drive
>> would need to come from the EPEL community, as now we are only guessing
>> what are the needs here.
>
> Understood. What are the groups initial recommendations for us to
> follow? I agree we need to have this done this fall/winter. [AKA I
> would like to say python34 will be removed by whatever EL7.x release
> comes out next.]
I'd start untangling the deps and getting the following in:
* six (looking at that one now)
https://src.fedoraproject.org/rpms/python3-six/pull-request/1
* pytest
* Cython
* PyYAML
* pip
* attrs
* requests
* mock
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4:16 p.m.
On 08/21/2018 11:06 AM, Miro Hrončok wrote:
>
> I'd start untangling the deps and getting the following in:
>
> * six (looking at that one now)
https://src.fedoraproject.org/rpms/python3-six/pull-request/1
> * pytest
> * Cython
> * PyYAML
> * pip
> * attrs
> * requests
> * mock
Yeah, I'd love to see us move this forward and get everything on 3.6...
Unfortunately I don't have a lot of time, but I can review/merge PR's
and do builds and such.
Perhaps we could setup a wiki page or someplace to coordinate?
kevin
5:31 p.m.
On Fri, Aug 24, 2018 at 3:04 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
On 08/21/2018 11:06 AM, Miro Hrončok wrote:
>>
>> I'd start untangling the deps and getting the following in:
>>
>> * six (looking at that one now)
>
> https://src.fedoraproject.org/rpms/python3-six/pull-request/1
Merged.
<https://src.fedoraproject.org/rpms/python3-six/pull-request/1>
>
>> * pytest
>> * Cython
>> * PyYAML
>> * pip
>> * attrs
>> * requests
>> * mock
Yeah, I'd love to see us move this forward and get everything on 3.6...
Unfortunately I don't have a lot of time, but I can review/merge PR's
and do builds and such.
Perhaps we could setup a wiki page or someplace to coordinate?
kevin
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
12:29 p.m.
New subject: Singularity and python3 - was Re: EPEL: Python 3.4 will be EOL in March 2019
On Tue, 21 Aug 2018, Miro Hrončok wrote:
On 13.8.2018 11:49, Larry Hastings wrote on python-dev(a)python.org:
> We of the core dev community commit to supporting Python releases for
> five years. Releases get eighteen months of active bug fixes, followed
> by three and a half years of security fixes. Python 3.4 turns 5 next
> March--at which point we'll stop supporting it, and I'll retire as 3.4
> release manager.
>
> My plan is to make one final release on or around its fifth birthday
> containing the last round of security fixes. That's about seven
> months from now.
See also PEP 429 -- Python 3.4 Release Schedule [0].
We have python34 and python36 in EPEL7. python34 being the "main" one and
python36 the "other" one. The original plan [1] was that once the ecosystem
is adapted well enough, we can switch what "main" and "other" is and
eventually drop python34, creating room for maybe another python3 release to
be the "other" next (python38 maybe?). Originally this was supposed to happen
for each release [2], but this was later abandoned due to lack of manpower.
How does this affect EPEL6 ?
We have just released singularity-runtime-2.6.0-1.1.el6.x86_64.rpm
which adds a dependency on /usr/bin/python3
Will EPEL6 users have to pull in an epel python3.6 as well as
epel python3.4 (and possibly in addition to SCL python33) ?
--
Andrew C. Aitchison Cambridge, UK
andrew(a)aitchison.me.uk
12:49 p.m.
New subject: Singularity and python3 - was Re: EPEL: Python 3.4 will be EOL in March 2019
On 25.8.2018 19:29, Andrew C Aitchison wrote:
On Tue, 21 Aug 2018, Miro Hrončok wrote:
> On 13.8.2018 11:49, Larry Hastings wrote on python-dev(a)python.org:
>> We of the core dev community commit to supporting Python releases for
>> five years. Releases get eighteen months of active bug fixes, followed
>> by three and a half years of security fixes. Python 3.4 turns 5 next
>> March--at which point we'll stop supporting it, and I'll retire as 3.4
>> release manager.
>>
>> My plan is to make one final release on or around its fifth birthday
>> containing the last round of security fixes. That's about seven
>> months from now.
>
> See also PEP 429 -- Python 3.4 Release Schedule [0].
>
> We have python34 and python36 in EPEL7. python34 being the "main" one
> and python36 the "other" one. The original plan [1] was that once the
> ecosystem is adapted well enough, we can switch what "main" and
> "other" is and eventually drop python34, creating room for maybe
> another python3 release to be the "other" next (python38 maybe?).
> Originally this was supposed to happen for each release [2], but this
> was later abandoned due to lack of manpower.
How does this affect EPEL6 ?
It doesn't. No python36 in EPEL 6. I guess it will just have an EOLed
Python 3.4 packaged until it's also EOLed.
We have just released singularity-runtime-2.6.0-1.1.el6.x86_64.rpm
which adds a dependency on /usr/bin/python3
Will EPEL6 users have to pull in an epel python3.6 as well as
epel python3.4 (and possibly in addition to SCL python33) ?
/usr/bin/python3 is provided by python34, so it will just use that.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2071
days inactive
2075
days old
epel-devel@lists.fedoraproject.org
7 comments
5 participants
participants (5)
-
Andrew C Aitchison -
Kevin Fenzi -
Miro Hrončok -
Stephen John Smoogen -
Tim Orling