Bug 1219411 - Review Request: python34 - Version 3 of the Python programming language aka Python 3000
Summary: Review Request: python34 - Version 3 of the Python programming language aka P...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Aurelien Bompard
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1091657 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-07 09:21 UTC by Matej Stuchlik
Modified: 2016-10-08 18:12 UTC (History)
14 users (show)

Fixed In Version: python34-3.4.3-2.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-08 17:10:49 UTC
Type: ---
Embargoed:
aurelien: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Matej Stuchlik 2015-05-07 09:21:27 UTC
Spec URL: https://mstuchli.fedorapeople.org/python34.spec
SRPM URL: https://mstuchli.fedorapeople.org/python34-3.4.3-1.fc21.src.rpm
Description:
Python 3 is a new version of the language that is incompatible with the 2.x
line of releases. The language is mostly the same, but many details, especially
how built-in objects like dictionaries and strings work, have changed
considerably, and a lot of deprecated features have finally been removed.

Fedora Account System Username: mstuchli

This is targeted for epel7 as part of Python3 in EPEL7 effort [0].

[0] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3

Comment 1 Matej Stuchlik 2015-05-07 09:23:27 UTC
*** Bug 1091657 has been marked as a duplicate of this bug. ***

Comment 2 Aurelien Bompard 2015-05-27 09:17:17 UTC
Since there's already a python3 package in Fedora, I'll comment on the diff between the current master and this package.
My comments are inlined in the diff below, and start with "--> "

@@ -16,3 +16,3 @@
 
-%global with_rewheel 1
+%global with_rewheel 0
 
@@ -23,2 +23,10 @@
 
+# is this the EPEL 7 main Python 3?
+%if "%python3_pkgversion" == "%pyshortver"
+%global main_python3 1
+%else
+%global main_python3 0
+%endif
+
+
 %global pylibdir %{_libdir}/python%{pybasever}

--> The with_rewheel flag should be set to 1 in the final package, as it is in the current master.
--> I don't understand this main_python3 package flag. This package will never be the main Python3 package, because it's from EPEL and RHEL will always ship the main python3 package.

@@ -140,5 +148,5 @@
 Summary: Version 3 of the Python programming language aka Python 3000
-Name: python3
-Version: %{pybasever}.2
-Release: 4%{?dist}
+Name: python%{pyshortver}
+Version: %{pybasever}.3
+Release: 1%{?dist}
 License: Python
@@ -201,4 +209,4 @@
 %if 0%{?with_rewheel}
-BuildRequires: python3-setuptools
-BuildRequires: python3-pip
+BuildRequires: python%{pyshortver}-setuptools
+BuildRequires: python%{pyshortver}-pip
 %endif
@@ -220,3 +228,3 @@
 #  __python3, python3_sitelib, python3_sitearch
-Source2: macros.python3
+Source2: macros.python%{pybasever}
 
@@ -225,3 +233,3 @@
 # with different Python runtimes as necessary:
-Source3: macros.pybytecompile
+Source3: macros.pybytecompile%{pybasever}
 
--> No problem with that

@@ -446,4 +454,4 @@
 # which values are printed as "v@entry" rather than just "v":
-# Not yet sent upstream
-Patch153: 00153-fix-test_gdb-noise.patch
+# Upstream as of 3.4.3
+# Patch153: 00153-fix-test_gdb-noise.patch
 
@@ -463,4 +471,4 @@
 # suite to ensure that it can load our -gdb.py script (rhbz#817072):
-# Not yet sent upstream
-Patch156: 00156-gdb-autoload-safepath.patch
+# Upstream as of 3.4.3
+# Patch156: 00156-gdb-autoload-safepath.patch
 
--> Upstreamed patches, nice! :-)

@@ -710,3 +718,4 @@
 # Issue: http://bugs.python.org/issue22638 Upstream discussion about SSLv3 in Python
-Patch199: 00199-alter-tests-to-reflect-sslv3-disabled.patch
+# OpenSSL in RHEL has SSLv3 enabled
+#Patch199: 00199-alter-tests-to-reflect-sslv3-disabled.patch
 
--> Also a good thing

@@ -724,2 +733,9 @@
 
+# 00202 #
+# Fixes undefined behaviour in faulthandler which caused tests to hang in on x86_64
+# http://bugs.python.org/issue23433
+Patch202: 00202-fix-undefined-behaviour-in-faulthandler.patch
+
+# test_threading fails in koji dues to it's handling of signals
+Patch203: 00203-disable-threading-test-koji.patch
 
--> Those patches look OK to me.

@@ -764,4 +780,4 @@
 %if 0%{with_rewheel}
-Requires: python3-setuptools
-Requires: python3-pip
+Requires: python%{pyshortver}-setuptools
+Requires: python%{pyshortver}-pip
 %endif
@@ -828,3 +844,3 @@
 
-You might want to install the python3-test package if you're developing
+You might want to install the python%{pyshortver}-test package if you're developing
 python 3 code that uses more than just unittest and/or test_support.py.
@@ -847,3 +863,3 @@
 %description debug
-python3-debug provides a version of the Python 3 runtime with numerous debugging
+python%{pyshortver}-debug provides a version of the Python 3 runtime with numerous debugging
 features enabled, aimed at advanced Python users, such as developers of Python
@@ -954,6 +970,6 @@
 # 00152: upstream as of Python 3.3.0b2
-%patch153 -p0
+# 00153: upstream as of Python 3.4.3
 # 00154: not for this branch
 %patch155 -p1
-%patch156 -p1
+# 00156: upstream as of 3.4.3
 %patch157 -p1
@@ -1003,3 +1019,6 @@
 # 00197: upstream as of Python 3.4.2
-%patch199 -p1
+# 00199: doesn't apply to RHEL 7
+%patch202 -p1
+%patch203 -p1
+
 
--> OK as reviewed before

@@ -1066,2 +1085,3 @@
   PathFixWithThisBinary=$5
+  MoreCFlags=$6
 
@@ -1103,4 +1123,3 @@
   # Invoke the build:
-  # TODO: it seems that 3.4.0a4 fails with %{?_smp_flags}, have to figure out why
-  make EXTRA_CFLAGS="$CFLAGS"
+  make EXTRA_CFLAGS="$CFLAGS $MoreCFlags" %{?_smp_mflags}
 

--> So, the build now works with smp_mflags? Nice.

@@ -1121,3 +1140,4 @@
 %endif
-  false
+  false \
+  -O1
 %endif # with_debug_build

--> What's the reason for adding the O1 flag?

@@ -1143,2 +1163,3 @@
   PyInstSoName=$2
+  MoreCFlags=$3
 
@@ -1151,3 +1172,8 @@
 
-make install DESTDIR=%{buildroot} INSTALL="install -p"
+%if 0%{?main_python3}
+make install \
+%else
+make altinstall \
+%endif
+  DESTDIR=%{buildroot} INSTALL="install -p" EXTRA_CFLAGS="$MoreCFlags"
 
@@ -1194,3 +1220,13 @@
 InstallPython debug \
-  %{py_INSTSONAME_debug}
+  %{py_INSTSONAME_debug} \
+  -O1
+
+%if ! 0%{?main_python3}
+# altinstall only creates pkgconfig/python-3.4.pc, not the version with ABIFAGS,
+#  so we need to move the debug .pc file to not overwrite it by optimized install
+mv \
+  %{buildroot}%{_libdir}/pkgconfig/python-%{pybasever}.pc \
+  %{buildroot}%{_libdir}/pkgconfig/python-%{LDVERSION_debug}.pc
+%endif
+
 %endif # with_debug_build

--> Looks good

@@ -1203,3 +1239,6 @@
 
-mv ${RPM_BUILD_ROOT}%{_bindir}/2to3 ${RPM_BUILD_ROOT}%{_bindir}/python3-2to3
+%if 0%{main_python3}
+#TODO: use 2to3-3 in Fedora as well instead of python3-2to3
+mv ${RPM_BUILD_ROOT}%{_bindir}/2to3 ${RPM_BUILD_ROOT}%{_bindir}/2to3-3
+%endif
 
@@ -1380,4 +1419,10 @@
   %{_bindir}/python%{LDVERSION_debug} \
+  %{buildroot}%{_bindir}/python%{pybasever}-debug
+
+%if 0%{main_python3}
+ln -s \
+  %{_bindir}/python%{pybasever}-debug \
   %{buildroot}%{_bindir}/python3-debug
 %endif
+%endif
 

--> See the comment on the main_python3 package at the top of the review.

@@ -1409,3 +1454,3 @@
    -e "s|LIBRARY_PATH|%{_libdir}/%{py_INSTSONAME_debug}|" \
-   -e 's|"python3"|"python3-debug"|' \
+   -e 's|"python3"|"python%{pybasever}-debug"|' \
    %{_sourcedir}/libpython.stp \

--> Normal.

@@ -1424,2 +1469,20 @@
 
+%if ! 0%{?main_python3}
+# make altinstall doesn't create python3.X-config, but we want it
+#  (we don't want to have just python3.Xm-config, that's a bit confusing)
+ln -s \
+  %{_bindir}/python%{LDVERSION_optimized}-config \
+  %{buildroot}%{_bindir}/python%{pybasever}-config
+# make altinstall doesn't create python-3.4m.pc, only python-3.4.pc, but we want both
+ln -s \
+  %{_libdir}/pkgconfig/python-%{pybasever}.pc \
+  %{buildroot}%{_libdir}/pkgconfig/python-%{LDVERSION_optimized}.pc
+%endif
+
+# remove libpython3.so in EPEL python to not cause collision between python3X and
+#  python3X+1 stacks... I don't see any way in which this would be useful
+#  Gentoo does this, as well... TODO: there's a sysconfig variable pointing
+#  to this, maybe we should do something about it?
+rm -f %{buildroot}%{_libdir}/libpython3.so
+
 # ======================================================

--> Looks good to me, I don't know about the sysconfig variable, can you elaborate on that?

@@ -1456,2 +1519,3 @@
     --verbose --findleaks \
+    -x test_distutils \
     %ifarch ppc64le aarch64

--> What's the reason for that?

@@ -1500,6 +1564,10 @@
 %{_bindir}/pydoc*
+%if 0%{?main_python3}
 %{_bindir}/python3
+%endif
 %{_bindir}/python%{pybasever}
 %{_bindir}/python%{pybasever}m
+%if 0%{?main_python3}
 %{_bindir}/pyvenv
+%endif
 %{_bindir}/pyvenv-%{pybasever}
@@ -1709,4 +1777,7 @@
 %{_libdir}/%{py_INSTSONAME_optimized}
-%{_libdir}/libpython3.so
+# removed in EPEL, see explanation in install section
+#%%{_libdir}/libpython3.so
 %if 0%{?with_systemtap}
+%dir %(dirname %{tapsetdir})
+%dir %{tapsetdir}
 %{tapsetdir}/%{libpython_stp_optimized}
@@ -1722,3 +1793,5 @@
 %doc Misc/README.valgrind Misc/valgrind-python.supp Misc/gdbinit
+%if 0%{?main_python3}
 %{_bindir}/python3-config
+%endif
 %{_bindir}/python%{pybasever}-config
@@ -1729,5 +1802,7 @@
 %{_libdir}/pkgconfig/python-%{pybasever}.pc
+%if 0%{?main_python3}
 %{_libdir}/pkgconfig/python3.pc
-%{_rpmconfigdir}/macros.d/macros.python3
-%{_rpmconfigdir}/macros.d/macros.pybytecompile
+%endif
+%{_rpmconfigdir}/macros.d/macros.python%{pybasever}
+%{_rpmconfigdir}/macros.d/macros.pybytecompile%{pybasever}
 
@@ -1735,3 +1810,5 @@
 %defattr(-,root,root,755)
-%{_bindir}/python3-2to3
+%if 0%{?main_python3}
+%{_bindir}/2to3-3
+%endif
 %{_bindir}/2to3-%{pybasever}
@@ -1781,3 +1858,6 @@
 %{_bindir}/python%{LDVERSION_debug}
+%if 0%{?main_python3}
 %{_bindir}/python3-debug
+%endif
+%{_bindir}/python%{pybasever}-debug
 
@@ -1848,2 +1928,4 @@
 %if 0%{?with_systemtap}
+%dir %(dirname %{tapsetdir})
+%dir %{tapsetdir}
 %{tapsetdir}/%{libpython_stp_debug}

--> See comments about the main_python3 variable, but in general it looks good to me.

END OF DIFF

I tried to review the other changes in the sources but the SRPM file seems corrupt, I get:
error: unpacking of archive failed on file /home/abompard/devel/rpms/RPMS/python34/Python-3.4.3.tar.xz;55658a3b: cpio: read
error: python34-3.4.3-1.fc21.src.rpm cannot be installed
Please upload a fixed version so I can continue the review, and answer the few questions I have asked here in the meantime.
Thanks!

Comment 3 Matej Stuchlik 2015-05-28 14:58:57 UTC
(In reply to Aurelien Bompard from comment #2)
> Since there's already a python3 package in Fedora, I'll comment on the diff
> between the current master and this package.
> My comments are inlined in the diff below, and start with "--> "
> 
> @@ -16,3 +16,3 @@
>  
> -%global with_rewheel 1
> +%global with_rewheel 0
>  
> @@ -23,2 +23,10 @@
>  
> +# is this the EPEL 7 main Python 3?
> +%if "%python3_pkgversion" == "%pyshortver"
> +%global main_python3 1
> +%else
> +%global main_python3 0
> +%endif
> +
> +
>  %global pylibdir %{_libdir}/python%{pybasever}
> 
> --> The with_rewheel flag should be set to 1 in the final package, as it is
> in the current master.

Correct, in the final package it should be and will be, first however one needs to resolve the dependency cycle between Python, pip, setuptools and wheel. There's more about this at the top of the .spec file in the comment.

> --> I don't understand this main_python3 package flag. This package will
> never be the main Python3 package, because it's from EPEL and RHEL will
> always ship the main python3 package.

The purpose of the main_python3 flag is somewhat explained in [0], in "Lifecycle of python3X stacks, rebuilding". Let me know if it's not clear. :)
I'll add a comment to the .spec explaining the purpose of the flag.

Note that Python 3 is actually *not* in RHEL 7, hence why there's a need for it in EPEL.

[0] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3

> @@ -1121,3 +1140,4 @@
>  %endif
> -  false
> +  false \
> +  -O1
>  %endif # with_debug_build
> 
> --> What's the reason for adding the O1 flag?

The point of that flag is to make debugging the debug build easier, but now that you mention it, it should be set to -O0 or -Og. Will fix!

> @@ -1424,2 +1469,20 @@
>  
> +%if ! 0%{?main_python3}
> +# make altinstall doesn't create python3.X-config, but we want it
> +#  (we don't want to have just python3.Xm-config, that's a bit confusing)
> +ln -s \
> +  %{_bindir}/python%{LDVERSION_optimized}-config \
> +  %{buildroot}%{_bindir}/python%{pybasever}-config
> +# make altinstall doesn't create python-3.4m.pc, only python-3.4.pc, but we
> want both
> +ln -s \
> +  %{_libdir}/pkgconfig/python-%{pybasever}.pc \
> +  %{buildroot}%{_libdir}/pkgconfig/python-%{LDVERSION_optimized}.pc
> +%endif
> +
> +# remove libpython3.so in EPEL python to not cause collision between
> python3X and
> +#  python3X+1 stacks... I don't see any way in which this would be useful
> +#  Gentoo does this, as well... TODO: there's a sysconfig variable pointing
> +#  to this, maybe we should do something about it?
> +rm -f %{buildroot}%{_libdir}/libpython3.so
> +
>  # ======================================================
> 
> --> Looks good to me, I don't know about the sysconfig variable, can you
> elaborate on that?

I'm frankly not sure on that, the comment is Slavek's. Will find out.
 
> @@ -1456,2 +1519,3 @@
>      --verbose --findleaks \
> +    -x test_distutils \
>      %ifarch ppc64le aarch64
> 
> --> What's the reason for that?

One of the tests in distutils test suite checks for a precise pip version, since we unbundle pip, it may happen that it is of a different version that the test expects. This was a temporary "solution", will fix. :)

> END OF DIFF
> 
> I tried to review the other changes in the sources but the SRPM file seems
> corrupt, I get:
> error: unpacking of archive failed on file
> /home/abompard/devel/rpms/RPMS/python34/Python-3.4.3.tar.xz;55658a3b: cpio:
> read
> error: python34-3.4.3-1.fc21.src.rpm cannot be installed
> Please upload a fixed version so I can continue the review, and answer the
> few questions I have asked here in the meantime.
> Thanks!

SRPM URL: https://mstuchli.fedorapeople.org/python34-3.4.3-1.fc21.src.rpm

Comment 4 Aurelien Bompard 2015-05-29 08:02:33 UTC
> Correct, in the final package it should be and will be, first however one
> needs to resolve the dependency cycle between Python, pip, setuptools and
> wheel. There's more about this at the top of the .spec file in the comment.

OK, we're on the same page.

> The purpose of the main_python3 flag is somewhat explained in [0], in
> "Lifecycle of python3X stacks, rebuilding". Let me know if it's not clear. :)
> I'll add a comment to the .spec explaining the purpose of the flag.
> 
> Note that Python 3 is actually *not* in RHEL 7, hence why there's a need for
> it in EPEL.

Oh, right, I was certain that it was there. It all makes sense then :-)

> The point of that flag is to make debugging the debug build easier, but now
> that you mention it, it should be set to -O0 or -Og. Will fix!

But why do you need something different from the Fedora python3 package?

The other changes in the SRPM are OK, the macros look correct.
I'm now waiting for your fixes to test the binary and make another (possibly final :) ) review. Thanks!

Comment 5 Matej Stuchlik 2015-05-29 08:37:32 UTC
> > The point of that flag is to make debugging the debug build easier, but now
> > that you mention it, it should be set to -O0 or -Og. Will fix!
> 
> But why do you need something different from the Fedora python3 package?

The same option is used in Rawhide, actually. :) But it should be in f22/f21 as well, let me look into that.

Comment 6 Aurelien Bompard 2015-06-01 12:49:06 UTC
Oh one more thing, since you're using the python3_pkgversion macro, it would make sense to buildrequire the python3-pkgversion-macros package. I know it's supposed to be in the buildroot, but for those rebuilding the SRPM locally it would be helpful.

Comment 7 Matej Stuchlik 2015-06-16 11:11:38 UTC
Spec URL: https://mstuchli.fedorapeople.org/python34.spec
SRPM URL: https://mstuchli.fedorapeople.org/python34-3.4.3-2.fc21.src.rpm

I've updated the spec - an explanation of individual changes follows:
 

@@ -739,6 +739,9 @@ Patch202: 00202-fix-undefined-behaviour-
 # test_threading fails in koji dues to it's handling of signals
 Patch203: 00203-disable-threading-test-koji.patch
 
+# openssl requires DH keys to be > 768bits
+Patch204: 00204-increase-dh-keys-size.patch
+
 # (New patches go here ^^^)
 #
 # When adding new patches to "python" and "python3" in Fedora 17 onwards,

--> Related to https://bugs.python.org/issue23844

@@ -916,6 +919,12 @@ for f in md5module.c sha1module.c sha256
     rm Modules/$f
 done
 
+# Since we unbundle pip, our version is different from upstream
+%if 0%{with_rewheel}
+%global pip_version 7.0.3
+sed -r -i s/'_PIP_VERSION = "[0-9.]+"'/'_PIP_VERSION = "%{pip_version}"'/ Lib/ensurepip/__init__.py
+%endif
+
 #
 # Apply patches:
 #

--> Change a constant that holds version of pip that comes with our Python.
    This will need to be changed whenever we update pip.

@@ -1020,6 +1029,7 @@ done
 # 00199: doesn't apply to RHEL 7
 %patch202 -p1
 %patch203 -p1
+%patch204 -p1

--> Applying the DH patch
 
 # Currently (2010-01-15), http://docs.python.org/library is for 2.6, and there
@@ -1139,7 +1149,7 @@ BuildPython debug \
   "--with-pydebug --with-count-allocs --with-call-profile --without-ensurepip" \
 %endif
   false \
-  -O1
+  -O0
 %endif # with_debug_build
 
 BuildPython optimized \
@@ -1219,7 +1229,7 @@ make altinstall \
 %if 0%{?with_debug_build}
 InstallPython debug \
   %{py_INSTSONAME_debug} \
-  -O1
+  -O0

--> Compile -debug build with -O0
 
 %if ! 0%{?main_python3}
 # altinstall only creates pkgconfig/python-3.4.pc, not the version with ABIFAGS,
@@ -1483,7 +1493,9 @@ ln -s \
 #  python3X+1 stacks... I don't see any way in which this would be useful
 #  Gentoo does this, as well... TODO: there's a sysconfig variable pointing
 #  to this, maybe we should do something about it?
+%if ! 0%{?main_python3}
 rm -f %{buildroot}%{_libdir}/libpython3.so
+%endif
 
 # ======================================================
 # Running the upstream test suite

--> Looking into it further, we should keep libpython3.so in the main Python

@@ -1518,6 +1530,10 @@ CheckPython() {
   LD_LIBRARY_PATH=$ConfDir $ConfDir/python -m test.regrtest \
     --verbose --findleaks \
     -x test_distutils \

--> This test fails in Koji but works fine locally, I'll look into
    why that could be the case, but I think it's safe to disable it
    for now.

+    %if 0%{!with_rewheel}
+    -x test_ensurepip \
+    -x test_venv \
+    %endif
     %ifarch ppc64le aarch64
     -x test_faulthandler \
     %endif
@@ -1776,7 +1792,9 @@ rm -fr %{buildroot}

--> These failures are expected early in the bootstrap
 
 %{_libdir}/%{py_INSTSONAME_optimized}
 # removed in EPEL, see explanation in install section
-#%%{_libdir}/libpython3.so
+%if 0%{?main_python3}
+%{_libdir}/libpython3.so
+%endif
 %if 0%{?with_systemtap}
 %dir %(dirname %{tapsetdir})
 %dir %{tapsetdir}
@@ -1972,6 +1990,12 @@ rm -fr %{buildroot}
 # ======================================================

--> See above.

A Koji build is available at [0], hopefully everything is alright now. :)

[0] http://koji.fedoraproject.org/koji/taskinfo?taskID=10068934

Comment 8 Matej Stuchlik 2015-06-16 11:14:53 UTC
(In reply to Aurelien Bompard from comment #6)
> Oh one more thing, since you're using the python3_pkgversion macro, it would
> make sense to buildrequire the python3-pkgversion-macros package. I know
> it's supposed to be in the buildroot, but for those rebuilding the SRPM
> locally it would be helpful.

That's a good point. We may end up using a different package to hold the macros, but I'll be sure to add it to BR's once I know which one it'll be.

Comment 9 Aurelien Bompard 2015-06-16 22:31:29 UTC
> --> Looking into it further, we should keep libpython3.so in the main Python

Then please update the comment above the line.

Other than that, and provided you add the BR for the macro file, it all looks good to me!

I tested the binaries and they work fine, let's go ahead with this package. :-)

Comment 10 Matej Stuchlik 2015-06-17 07:57:24 UTC
New Package SCM Request
=======================
Package Name: python34
Short Description: Version 3 of the Python programming language aka Python 3000
Upstream URL: https://www.python.org/
Owners: mstuchli
Branches: epel7
InitialCC:

Comment 11 Gwyn Ciesla 2015-06-18 15:17:17 UTC
Git done (by process-git-requests).

Comment 12 Fedora Update System 2015-06-19 07:23:46 UTC
python34-3.4.3-2.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/python34-3.4.3-2.el7

Comment 13 Aurelien Bompard 2015-06-19 08:25:25 UTC
Cool! Next step: python34-setuptools and python34-pip I guess? Please add me in CC to those tickets.

Comment 14 Fedora Update System 2015-06-20 21:11:58 UTC
python34-3.4.3-2.el7 has been pushed to the Fedora EPEL 7 testing repository.

Comment 15 Matej Stuchlik 2015-06-25 10:43:30 UTC
(In reply to Aurelien Bompard from comment #13)
> Cool! Next step: python34-setuptools and python34-pip I guess? Please add me
> in CC to those tickets.

Right you are, but I should first make sure the guidelines pass through FPC, I'm just awfully busy until the end of next week, so it'll take a while. :(

And I'll be sure to CC you. :)

Comment 16 Nick Coghlan 2015-07-01 06:18:07 UTC
Just noting that once this makes it through to the main EPEL repos, it would be good to post an EPEL based answer to https://stackoverflow.com/questions/8087184/installing-python3-on-rhel

Comment 17 Matej Stuchlik 2015-07-01 06:58:36 UTC
(In reply to Nick Coghlan from comment #16)
> Just noting that once this makes it through to the main EPEL repos, it would
> be good to post an EPEL based answer to
> https://stackoverflow.com/questions/8087184/installing-python3-on-rhel

Good idea, will do :)

Comment 18 Fedora Update System 2015-07-08 17:10:49 UTC
python34-3.4.3-2.el7 has been pushed to the Fedora EPEL 7 stable repository.

Comment 19 Aurelien Bompard 2015-10-28 09:29:48 UTC
Hey Matej, did you get a chance to submit your python34-setuptools and python34-pip packages? I can't find them. Is anything else blocking you?


Note You need to log in before you can comment on or make changes to this bug.