Available in updates-testing, please karma it:
https://bodhi.fedoraproject.org/updates/python35-3.5.6-1.fc28 https://bodhi.fedoraproject.org/updates/python35-3.5.6-1.fc27
https://bodhi.fedoraproject.org/updates/python34-3.4.9-1.fc28 https://bodhi.fedoraproject.org/updates/python34-3.4.9-1.fc27
-------- Forwarded Message -------- Subject: [Python-Dev] [RELEASED] Python 3.4.9 and Python 3.5.6 are now available Date: Thu, 2 Aug 2018 07:00:11 -0700 From: Larry Hastings larry@hastings.org To: python-announce@python.org, Python-Dev python-dev@python.org, python-list@python.org, python-committers python-committers@python.org
On behalf of the Python development community, I'm happy to announce the availability of Python 3.4.9 and Python 3.5.6.
Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only.
You can find Python 3.4.9 here:
https://www.python.org/downloads/release/python-349/
And you can find Python 3.5.6 here:
https://www.python.org/downloads/release/python-356/
We now return you to your pitched debate already in progress,
//arry/
How difficult would it be to provide modern Python (e.g. 35 or 36) in EPEL?
I'm always saddened when I can't use some of the new, really great features on my EL7 hosts.
On 2018-08-07 10:26, Miro Hrončok wrote:
Available in updates-testing, please karma it:
https://bodhi.fedoraproject.org/updates/python35-3.5.6-1.fc28 https://bodhi.fedoraproject.org/updates/python35-3.5.6-1.fc27
https://bodhi.fedoraproject.org/updates/python34-3.4.9-1.fc28 https://bodhi.fedoraproject.org/updates/python34-3.4.9-1.fc27
-------- Forwarded Message -------- Subject: [Python-Dev] [RELEASED] Python 3.4.9 and Python 3.5.6 are now available Date: Thu, 2 Aug 2018 07:00:11 -0700 From: Larry Hastings larry@hastings.org To: python-announce@python.org, Python-Dev python-dev@python.org, python-list@python.org, python-committers python-committers@python.org
On behalf of the Python development community, I'm happy to announce the availability of Python 3.4.9 and Python 3.5.6.
Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only.
You can find Python 3.4.9 here:
https://www.python.org/downloads/release/python-349/
And you can find Python 3.5.6 here:
https://www.python.org/downloads/release/python-356/
We now return you to your pitched debate already in progress,
//arry/ _______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-leave@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/python-devel@lists.fedoraproje...
"JF" == John Florian jflorian@doubledog.org writes:
JF> How difficult would it be to provide modern Python (e.g. 35 or 36) JF> in EPEL?
Obviously not that difficult, since it is already there. The main problem is that the way it was done requires that Fedora specfiles grow additional complication in order to be built in EPEL, so it isn't just a matter of rebuilding a bunch of existing packages.
- J<
On 2018-08-08 10:47, Jason Tibbitts wrote:
"JF" == John Florian jflorian@doubledog.org writes:
JF> How difficult would it be to provide modern Python (e.g. 35 or 36) JF> in EPEL?
Obviously not that difficult, since it is already there.
By that I assume you mean 34, right? Or am I overlooking something?
The main problem is that the way it was done requires that Fedora specfiles grow additional complication in order to be built in EPEL, so it isn't just a matter of rebuilding a bunch of existing packages.
IIRC, the Software Collection stuff has newer ones that I could use, but all the install/setup stuff is cumbersome as compared to declaring a few simple deps in my spec files. If you or anyone has references how to pull SC deps in neatly, I'd love to see that.
I suppose I'm just in the same boat everyone else is where the life of Fedora releases are too short to be ideal for production environments and EL releases are just too old. Of course, if the Fedora releases lived longer, they also would be(come) too old. It just seems EPEL never quite lives up to what it ideally could be, the latest offerings from Fedora atop EL.
On 8 August 2018 at 11:43, John Florian jflorian@doubledog.org wrote:
On 2018-08-08 10:47, Jason Tibbitts wrote:
> > "JF" == John Florian jflorian@doubledog.org writes:
JF> How difficult would it be to provide modern Python (e.g. 35 or 36) JF> in EPEL?
Obviously not that difficult, since it is already there.
By that I assume you mean 34, right? Or am I overlooking something?
The main problem is that the way it was done requires that Fedora specfiles grow additional complication in order to be built in EPEL, so it isn't just a matter of rebuilding a bunch of existing packages.
IIRC, the Software Collection stuff has newer ones that I could use, but all the install/setup stuff is cumbersome as compared to declaring a few simple deps in my spec files. If you or anyone has references how to pull SC deps in neatly, I'd love to see that.
I suppose I'm just in the same boat everyone else is where the life of Fedora releases are too short to be ideal for production environments and EL releases are just too old. Of course, if the Fedora releases lived longer, they also would be(come) too old. It just seems EPEL never quite lives up to what it ideally could be, the latest offerings from Fedora atop EL.
But that isn't what EPEL was ever meant to be. EPEL was meant to be a place where long term supported packages (and not some others) that Fedora Infrastructure and similar projects needed but Red Hat Enterprise Linux did not have. There have been people who want the latest offerings but they rarely are the people doing any of the packaging and maintenance work in EPEL.
And it is a long tail of what the 'latest offerings from Fedora' means as a good many packages people want to stick to are usually newer than what RHEL forked off of but older than what is in Fedora. (Various people want X from Fedora 24 for their system but not what is in Fedora 28.) This wasn't what EPEL was meant to solve and was never set up to deal with. It would require a lot of changes to solve this with a very different compose system than what exists in Fedora currently. [That would require resources no one ever seems to have.]
On 8.8.2018 17:43, John Florian wrote:
On 2018-08-08 10:47, Jason Tibbitts wrote:
> "JF" == John Florian jflorian@doubledog.org writes:
JF> How difficult would it be to provide modern Python (e.g. 35 or 36) JF> in EPEL?
Obviously not that difficult, since it is already there.
By that I assume you mean 34, right? Or am I overlooking something?
You are overlooking the pythno36 package.
On 2018-08-09 08:23, Miro Hrončok wrote:
On 8.8.2018 17:43, John Florian wrote:
On 2018-08-08 10:47, Jason Tibbitts wrote:
>> "JF" == John Florian jflorian@doubledog.org writes:
JF> How difficult would it be to provide modern Python (e.g. 35 or 36) JF> in EPEL?
Obviously not that difficult, since it is already there.
By that I assume you mean 34, right? Or am I overlooking something?
You are overlooking the pythno36 package.
I sure am. Thanks for pointing that out. Now I'm off to check what's wrong with my brain.
On 7.8.2018 16:26, Miro Hrončok wrote:
Available in updates-testing, please karma it:
https://bodhi.fedoraproject.org/updates/python35-3.5.6-1.fc28 https://bodhi.fedoraproject.org/updates/python35-3.5.6-1.fc27
https://bodhi.fedoraproject.org/updates/python34-3.4.9-1.fc28 https://bodhi.fedoraproject.org/updates/python34-3.4.9-1.fc27
Updated to:
https://bodhi.fedoraproject.org/updates/python34-3.4.9-2.fc28 https://bodhi.fedoraproject.org/updates/python34-3.4.9-2.fc27
python-devel@lists.fedoraproject.org
-
Jason Tibbitts -
John Florian -
Miro Hrončok -
Stephen John Smoogen