EPEL: Python34 moving to Python36

[Stephen John Smoogen]

Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George,
and several helpers have gotten nearly all of the python34 packages
moves over to python36 in EPEL-7.  They are being included in 6 Bodhi
pushes because of a limitation in Bodhi for the text size of packages
in an include.

The current day for these package groups to move into EPEL regular is
April 2nd. We would like to have all tests we find in the next week or
so also added so that the updates can occur in a large group without
too much breakage.


https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9e9f81e581
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0d62608bce
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5be892b745
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0f4cca7837
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ed3564d906

Please heavily test them by doing the following:
Stage 1 Testing
Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
Install or enable the EPEL repository for this system
Install various packages you would normally use
yum --enablerepo=epel-testing update
Report problems to epel-devel(a)lists.fedoraproject.org
Stage 2 Testing
Check for any updated testing instructions on this blog or EPEL-devel list.
Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
Install or enable the EPEL repository for this system
yum install python34
yum --enablerepo=epel-testing update
Report problems to epel-devel(a)lists.fedoraproject.org
Stage 3 Testing
Check for any updated testing instructions on this blog or EPEL-devel list.
Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
Install or enable the EPEL repository for this system
yum install python36
yum --enablerepo=epel-testing update
Report problems to epel-devel(a)lists.fedoraproject.org
This should cover the three most common scenarios. Other scenarios
exist and will require some sort of intervention to work around. We
will outline them as they come up.

Many Many Thanks go to Troy, Jeroen, Carl, and the many people on the
python team who made a copr and did many of the initial patches to
make this possible.
-- 
Stephen J Smoogen.

[Wart]

Attempts to upgrade python34-six fail with an unexpected file conflict.
 I didn't see any Conflicts: or Obsoletes: tags in the spec file, so I'm
not sure where this conflict is coming from.

# yum --enablerepo epel-testing-upstream upgrade python34-six
Loaded plugins: langpacks, priorities
164 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package python34-six.noarch 0:1.11.0-1.el7 will be updated
---> Package python34-six.noarch 0:1.11.0-2.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package          Arch       Version            Repository
   Size
================================================================================
Updating:
 python34-six     noarch     1.11.0-2.el7       epel-testing-upstream
   32 k

Transaction Summary
================================================================================
Upgrade  1 Package

Total download size: 32 k
Is this ok [y/d/N]: y
Downloading packages:
python34-six-1.11.0-2.el7.noarch.rpm                       |  32 kB
00:00
Running transaction check
Running transaction test


Transaction check error:
  file /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info from
install of python34-six-1.11.0-2.el7.noarch conflicts with file from
package python34-six-1.11.0-1.el7.noarch


--Wart

On 3/13/19 9:30 AM, Stephen John Smoogen wrote:
>  Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W
> George,
>  and several helpers have gotten nearly all of the python34 packages
>  moves over to python36 in EPEL-7.  They are being included in 6 Bodhi
>  pushes because of a limitation in Bodhi for the text size of packages
>  in an include.
>  
>  The current day for these package groups to move into EPEL regular is
>  April 2nd. We would like to have all tests we find in the next week or
>  so also added so that the updates can occur in a large group without
>  too much breakage.
>  
>  
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9e9f81e581
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0d62608bce
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5be892b745
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0f4cca7837
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ed3564d906
>  
>  Please heavily test them by doing the following:
>  Stage 1 Testing
>  Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  Install or enable the EPEL repository for this system
>  Install various packages you would normally use
>  yum --enablerepo=epel-testing update
>  Report problems to epel-devel(a)lists.fedoraproject.org
>  Stage 2 Testing
>  Check for any updated testing instructions on this blog or EPEL-devel list.
>  Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  Install or enable the EPEL repository for this system
>  yum install python34
>  yum --enablerepo=epel-testing update
>  Report problems to epel-devel(a)lists.fedoraproject.org
>  Stage 3 Testing
>  Check for any updated testing instructions on this blog or EPEL-devel list.
>  Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  Install or enable the EPEL repository for this system
>  yum install python36
>  yum --enablerepo=epel-testing update
>  Report problems to epel-devel(a)lists.fedoraproject.org
>  This should cover the three most common scenarios. Other scenarios
>  exist and will require some sort of intervention to work around. We
>  will outline them as they come up.
>  
>  Many Many Thanks go to Troy, Jeroen, Carl, and the many people on the
>  python team who made a copr and did many of the initial patches to
>  make this possible.
>

[Miro Hrončok]

On 13. 03. 19 18:42, Wart wrote:
>  Transaction check error:
>     file /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info from
>  install of python34-six-1.11.0-2.el7.noarch conflicts with file from
>  package python34-six-1.11.0-1.el7.noarch 
IS that a file to directory problem? Otherwise python34-six-1.11.0-2.el7.noarch 
should just replace python34-six-1.11.0-1.el7.noarch "naturally" without any 
specific conflict.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Orion Poplawski]

On 3/13/19 11:48 AM, Miro Hrončok wrote:
>  On 13. 03. 19 18:42, Wart wrote:
> > Transaction check error:
> >    file /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info from
> > install of python34-six-1.11.0-2.el7.noarch conflicts with file from
> > package python34-six-1.11.0-1.el7.noarch
>  
>  IS that a file to directory problem? Otherwise 
>  python34-six-1.11.0-2.el7.noarch should just replace 
>  python34-six-1.11.0-1.el7.noarch "naturally" without any specific conflict.
>   
It appears to be a directory -> file problem.  Why did this change?

# ls -l /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info
total 16
-rw-r--r--. 1 root root    1 Sep 28 12:18 dependency_links.txt
-rw-r--r--. 1 root root 1818 Sep 28 12:18 PKG-INFO
-rw-r--r--. 1 root root  253 Sep 28 12:18 SOURCES.txt
-rw-r--r--. 1 root root    4 Sep 28 12:18 top_level.txt

# repoquery --enablerepo=epel-testing -l 
python34-six-1.11.0-2.el7.noarch | grep egg
/usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info


-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: [phone]
3380 Mitchell Lane                       orion(a)nwra.com
Boulder, CO 80301                 https://www.nwra.com/

[Orion Poplawski]

On 3/13/19 11:48 AM, Miro Hrončok wrote:
>  On 13. 03. 19 18:42, Wart wrote:
> > Transaction check error:
> >    file /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info from
> > install of python34-six-1.11.0-2.el7.noarch conflicts with file from
> > package python34-six-1.11.0-1.el7.noarch
>  
>  IS that a file to directory problem? Otherwise 
>  python34-six-1.11.0-2.el7.noarch should just replace 
>  python34-six-1.11.0-1.el7.noarch "naturally" without any specific conflict.
>   
I think I figured this out.  During the install step if we didn't have a 
tests_require package installed we got:

running install_egg_info
Writing 
/builddir/build/BUILDROOT/python3-six-1.11.0-2.el7.noarch/usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info
BUILDSTDERR: /usr/lib64/python3.4/distutils/dist.py:260: UserWarning: 
Unknown distribution option: 'tests_require'
BUILDSTDERR:   warnings.warn(msg)

and ended up with a file egg-info instead of a directory.

I've rebuilt python3-six with the test requirements installed for both 
versions now.  I'll add python3-six-1.11.0-3.el7.src.rpm to the update.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: [phone]
3380 Mitchell Lane                       orion(a)nwra.com
Boulder, CO 80301                 https://www.nwra.com/

[Miro Hrončok]

On 14. 03. 19 0:53, Orion Poplawski wrote:
>  On 3/13/19 11:48 AM, Miro Hrončok wrote:
> > On 13. 03. 19 18:42, Wart wrote:
> >> Transaction check error:
> >>    file /usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info from
> >> install of python34-six-1.11.0-2.el7.noarch conflicts with file from
> >> package python34-six-1.11.0-1.el7.noarch
> >
> > IS that a file to directory problem? Otherwise 
> > python34-six-1.11.0-2.el7.noarch should just replace 
> > python34-six-1.11.0-1.el7.noarch "naturally" without any specific
> conflict.
> >
>  
>  I think I figured this out.  During the install step if we didn't have a 
>  tests_require package installed we got:
>  
>  running install_egg_info
>  Writing 
>
> /builddir/build/BUILDROOT/python3-six-1.11.0-2.el7.noarch/usr/lib/python3.4/site-packages/six-1.11.0-py3.4.egg-info
>
>  
>  BUILDSTDERR: /usr/lib64/python3.4/distutils/dist.py:260: UserWarning: Unknown 
>  distribution option: 'tests_require'
>  BUILDSTDERR:   warnings.warn(msg)
>  
>  and ended up with a file egg-info instead of a directory.
>  
>  I've rebuilt python3-six with the test requirements installed for both versions 
>  now.  I'll add python3-six-1.11.0-3.el7.src.rpm to the update. 
Thanks.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

[Chris]

Amazing work!

I just wanted to ask if it was a bug that the Python v2 branch provided the
following RPMs, but the Python v3.6 did not:
- python36-requests-oauthlib
- python36-oauthlib
- python36-markdown
- python36-pytest-runner

Perhaps these ones just haven't been ported over yet? Thoughts?
Here's the source of my prob:
https://koji.fedoraproject.org/koji/taskinfo?taskID=33463886

Chris


On Wed, Mar 13, 2019 at 10:38 AM Stephen John Smoogen <smooge(a)gmail.com&gt;
wrote:

>  Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W
> George,
>  and several helpers have gotten nearly all of the python34 packages
>  moves over to python36 in EPEL-7.  They are being included in 6 Bodhi
>  pushes because of a limitation in Bodhi for the text size of packages
>  in an include.
>
>  The current day for these package groups to move into EPEL regular is
>  April 2nd. We would like to have all tests we find in the next week or
>  so also added so that the updates can occur in a large group without
>  too much breakage.
>
>
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9e9f81e581
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0d62608bce
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5be892b745
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0f4cca7837
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ed3564d906
>
>  Please heavily test them by doing the following:
>  Stage 1 Testing
>  Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  Install or enable the EPEL repository for this system
>  Install various packages you would normally use
>  yum --enablerepo=epel-testing update
>  Report problems to epel-devel(a)lists.fedoraproject.org
>  Stage 2 Testing
>  Check for any updated testing instructions on this blog or EPEL-devel list.
>  Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  Install or enable the EPEL repository for this system
>  yum install python34
>  yum --enablerepo=epel-testing update
>  Report problems to epel-devel(a)lists.fedoraproject.org
>  Stage 3 Testing
>  Check for any updated testing instructions on this blog or EPEL-devel list.
>  Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  Install or enable the EPEL repository for this system
>  yum install python36
>  yum --enablerepo=epel-testing update
>  Report problems to epel-devel(a)lists.fedoraproject.org
>  This should cover the three most common scenarios. Other scenarios
>  exist and will require some sort of intervention to work around. We
>  will outline them as they come up.
>
>  Many Many Thanks go to Troy, Jeroen, Carl, and the many people on the
>  python team who made a copr and did many of the initial patches to
>  make this possible.
>  --
>  Stephen J Smoogen.
>  _______________________________________________
>  devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
>  To unsubscribe send an email to
>  devel-announce-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/[e-mail]...
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to 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/[e-mail]
>

[Orion Poplawski]

On 3/13/19 9:05 PM, Chris wrote:
>  Amazing work!
>  
>  I just wanted to ask if it was a bug that the Python v2 branch provided 
>  the following RPMs, but the Python v3.6 did not:
>  - python36-requests-oauthlib
>  - python36-oauthlib 
The above python2 packages are in RHEL7, so new python3- packages will 
need to be created in Fedora for EPEL7.

>  - python36-markdown
>  - python36-pytest-runner 
These are now in epel-testing.  Buildroot overrides would need to be 
created for them for them to be in the buildroot.

>  
>  Perhaps these ones just haven't been ported over yet? Thoughts?
>  Here's the source of my prob: 
>  https://koji.fedoraproject.org/koji/taskinfo?taskID=33463886
>  
>  Chris 


-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: [phone]
3380 Mitchell Lane                       orion(a)nwra.com
Boulder, CO 80301                 https://www.nwra.com/

EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Miro Hrončok]

On 13. 03. 19 15:30, Stephen John Smoogen wrote:
>  Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W
> George,
>  and several helpers have gotten nearly all of the python34 packages
>  moves over to python36 in EPEL-7.  They are being included in 6 Bodhi
>  pushes because of a limitation in Bodhi for the text size of packages
>  in an include.
>  
>  The current day for these package groups to move into EPEL regular is
>  April 2nd. We would like to have all tests we find in the next week or
>  so also added so that the updates can occur in a large group without
>  too much breakage. 
A problem was pointed out in 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada#comme...

If you have 3rd party software using /usr/bin/python3 and you have python34 
installed, updating your system will remove that symlink and your software breaks.

However we cannot obsolete python34 form python36, because that breaks software 
that actually wants and uses /usr/bin/python3.4 and possibly make python34 
uninstallable (not sure).

So arguably, the update should update both python34 and install python36, 
keeping both Pythons available, the user/admin could than remove the one that is 
not needed.

AFAIK The only thing that would make this happen is to require python36 from 
python34. And that seems like a huge ugly workaround with unwanted side affects.

Any ideas?


-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Stephen John Smoogen]

On Mon, 25 Mar 2019 at 13:07, Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  On 13. 03. 19 15:30, Stephen John Smoogen wrote:
>  > Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George,
>  > and several helpers have gotten nearly all of the python34 packages
>  > moves over to python36 in EPEL-7.  They are being included in 6 Bodhi
>  > pushes because of a limitation in Bodhi for the text size of packages
>  > in an include.
>  >
>  > The current day for these package groups to move into EPEL regular is
>  > April 2nd. We would like to have all tests we find in the next week or
>  > so also added so that the updates can occur in a large group without
>  > too much breakage.
>
>  A problem was pointed out in
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada#comme...
>
>  If you have 3rd party software using /usr/bin/python3 and you have python34
>  installed, updating your system will remove that symlink and your software breaks.
>
>  However we cannot obsolete python34 form python36, because that breaks software
>  that actually wants and uses /usr/bin/python3.4 and possibly make python34
>  uninstallable (not sure).
>
>  So arguably, the update should update both python34 and install python36,
>  keeping both Pythons available, the user/admin could than remove the one that is
>  not needed.
>
>  AFAIK The only thing that would make this happen is to require python36 from
>  python34. And that seems like a huge ugly workaround with unwanted side affects.
>  
Here is a hair-brained idea. have them both require
python3-versioned-command which puts in the alternatives logic and
sets it to 1 of 3 options?
1. python34
2. python36
3. you didn't install a python silly


>  Any ideas?
>
>
>  --
>  Miro Hrončok
>  --
>  Phone: [phone]
>  IRC: mhroncok
>  _______________________________________________
>  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/[e-mail]... 


-- 
Stephen J Smoogen.

EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Kevin Fenzi]

On 3/25/19 10:18 AM, Stephen John Smoogen wrote:
>  On Mon, 25 Mar 2019 at 13:07, Miro Hrončok
> <mhroncok(a)redhat.com&gt; wrote:
> >
> > On 13. 03. 19 15:30, Stephen John Smoogen wrote:
> >> Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George,
> >> and several helpers have gotten nearly all of the python34 packages
> >> moves over to python36 in EPEL-7.  They are being included in 6 Bodhi
> >> pushes because of a limitation in Bodhi for the text size of packages
> >> in an include.
> >>
> >> The current day for these package groups to move into EPEL regular is
> >> April 2nd. We would like to have all tests we find in the next week or
> >> so also added so that the updates can occur in a large group without
> >> too much breakage.
> >
> > A problem was pointed out in
> > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada#comme...
> >
> > If you have 3rd party software using /usr/bin/python3 and you have python34
> > installed, updating your system will remove that symlink and your software breaks.
> >
> > However we cannot obsolete python34 form python36, because that breaks software
> > that actually wants and uses /usr/bin/python3.4 and possibly make python34
> > uninstallable (not sure).
> >
> > So arguably, the update should update both python34 and install python36,
> > keeping both Pythons available, the user/admin could than remove the one that is
> > not needed.
> >
> > AFAIK The only thing that would make this happen is to require python36 from
> > python34. And that seems like a huge ugly workaround with unwanted side affects.
> >
>  
>  Here is a hair-brained idea. have them both require
>  python3-versioned-command which puts in the alternatives logic and
>  sets it to 1 of 3 options?
>  1. python34
>  2. python36
>  3. you didn't install a python silly 
I think that could be confusing (not that the alternatives are much
else. ;)

But we talked about this a lot on IRC.

Just make python36 obsolete the old version of python34 that had
/usr/bin/python3. This causes yum to install the new python34 and pull
in python36 for /usr/bin/python3.

It does mean people with 3rd party software are now using python36
instead of 34, but if they only speficied /usr/bin/python3, it should
just run with any python3 version right?

kevin

EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Miro Hrončok]

On 25. 03. 19 18:56, Kevin Fenzi wrote:
>  Just make python36 obsolete the old version of python34 that had
>  /usr/bin/python3. This causes yum to install the new python34 and pull
>  in python36 for /usr/bin/python3. 
If that works, we are good. Does it really behave like that with plain upgrade? 
E.g. without specifying what to upgrade?

I thought that obsoleting old py34 can do one of the following:

A) python34 gets queued for upgrading first, there is no more old python34 to be 
obsoleted by python36, python36 isn't installed.

B) python36 gets queued for obsoleting old python34 first, python34 gets queued 
for removing instead of updating, there is more pytho34 to be updated.

C) what you said.

If C) is the guaranteed behavior, I guess we are good to do this.

>  It does mean people with 3rd party software are now using python36
>  instead of 34, but if they only speficied /usr/bin/python3, it should
>  just run with any python3 version right? 
As long as they are only using standard library, yes. Otherwise there might be 
problems. However that was anticipated.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Miro Hrončok]

On 26. 03. 19 1:51, Miro Hrončok wrote:
>  On 25. 03. 19 18:56, Kevin Fenzi wrote:
> > Just make python36 obsolete the old version of python34 that had
> > /usr/bin/python3. This causes yum to install the new python34 and pull
> > in python36 for /usr/bin/python3.
>  
>  If that works, we are good. Does it really behave like that with plain upgrade? 
>  E.g. without specifying what to upgrade?
>  
>  I thought that obsoleting old py34 can do one of the following:
>  
>  A) python34 gets queued for upgrading first, there is no more old python34 to be 
>  obsoleted by python36, python36 isn't installed.
>  
>  B) python36 gets queued for obsoleting old python34 first, python34 gets queued 
>  for removing instead of updating, there is more pytho34 to be updated.
>  
>  C) what you said.
>  
>  If C) is the guaranteed behavior, I guess we are good to do this.
>  
> > It does mean people with 3rd party software are now using python36
> > instead of 34, but if they only speficied /usr/bin/python3, it should
> > just run with any python3 version right?
>  
>  As long as they are only using standard library, yes. Otherwise there might be 
>  problems. However that was anticipated. 
A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27

I'm still not sure about how it will behave. We should probably test it.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Neal Gompa]

On Thu, Mar 28, 2019 at 8:22 AM Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  On 26. 03. 19 1:51, Miro Hrončok wrote:
>  > On 25. 03. 19 18:56, Kevin Fenzi wrote:
>  >> Just make python36 obsolete the old version of python34 that had
>  >> /usr/bin/python3. This causes yum to install the new python34 and pull
>  >> in python36 for /usr/bin/python3.
>  >
>  > If that works, we are good. Does it really behave like that with plain upgrade?
>  > E.g. without specifying what to upgrade?
>  >
>  > I thought that obsoleting old py34 can do one of the following:
>  >
>  > A) python34 gets queued for upgrading first, there is no more old python34 to be
>  > obsoleted by python36, python36 isn't installed.
>  >
>  > B) python36 gets queued for obsoleting old python34 first, python34 gets queued
>  > for removing instead of updating, there is more pytho34 to be updated.
>  >
>  > C) what you said.
>  >
>  > If C) is the guaranteed behavior, I guess we are good to do this.
>  >
>  >> It does mean people with 3rd party software are now using python36
>  >> instead of 34, but if they only speficied /usr/bin/python3, it should
>  >> just run with any python3 version right?
>  >
>  > As long as they are only using standard library, yes. Otherwise there might be
>  > problems. However that was anticipated.
>
>  A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27
>
>  I'm still not sure about how it will behave. We should probably test it.
>  
Obsoletes means that the old package will get removed as part of the
upgrade. Conflicts means that yum has to figure out a way to keep it.
That's the difference.



-- 
真実はいつも一つ！/ Always, there's only one truth!

EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Kevin Fenzi]

On 3/28/19 5:22 AM, Miro Hrončok wrote:
>  
>  A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27
>  
>  I'm still not sure about how it will behave. We should probably test it. 
I just did a bunch of testing and the Obsoletes works great.

It does mean if someone has only packages that depend on
/usr/bin/python3 and has python34 installed for that, on upgrade they
will get just python36 and no python34. However, I think thats fine.

If they have other things that depend on 34 (the abi, or libs or the
like), they will get python36 and the updated python34 that doesn't
provide /usr/bin/python3.

I'm +1 to add this to the update and give it some more baking time.

kevin

EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Tuomo Soini]

On Thu, 28 Mar 2019 13:22:26 +0100
Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:

>  
>  A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27 
>  I'm still not sure about how it will behave. We should probably
> test
>  it. 
https://bugzilla.redhat.com/show_bug.cgi?id=1687196

Check my bug report first. You only need obsoletes in one place and
there was my suggested patch which was not good enough for some, but it
i a lot better than suggested change from Conflicts to Obsoletes all
over.


-- 
Tuomo Soini <tis(a)foobar.fi&gt;
Foobar Linux services
[phone]
Foobar Oy <https://foobar.fi/>

EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Miro Hrončok]

On 28. 03. 19 21:54, Tuomo Soini wrote:
>  On Thu, 28 Mar 2019 13:22:26 +0100
>  Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
>  
> >
> > A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27
>  
> > I'm still not sure about how it will behave. We should probably test
> > it.
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=1687196
>  
>  Check my bug report first. You only need obsoletes in one place and
>  there was my suggested patch which was not good enough for some, but it
>  i a lot better than suggested change from Conflicts to Obsoletes all
>  over. 
I don't understand why the obsoletes all over are any worse than just one.

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Kevin Fenzi]

On 3/28/19 4:39 PM, Miro Hrončok wrote:
>  On 28. 03. 19 21:54, Tuomo Soini wrote:
> > On Thu, 28 Mar 2019 13:22:26 +0100
> > Miro Hrončok <mhroncok(a)redhat.com&gt; wrote:
> >
> >>
> >> A PR is at https://src.fedoraproject.org/rpms/python36/pull-request/27
> >
> >> I'm still not sure about how it will behave. We should probably test
> >> it.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1687196
> >
> > Check my bug report first. You only need obsoletes in one place and
> > there was my suggested patch which was not good enough for some, but it
> > i a lot better than suggested change from Conflicts to Obsoletes all
> > over.
>  
>  I don't understand why the obsoletes all over are any worse than just one. 
In this case it's likely more what we want anyhow, as we want people to
move off the python34 packages. I don't think we want to keep them
around and supporting them forever. Obsoletes on everything will remove
the old python34 (and not pull in the new one) unless there's something
installed that actually needs python34.

kevin

[Troy Dawson]

On Wed, Mar 13, 2019 at 7:31 AM Stephen John Smoogen <smooge(a)gmail.com&gt; wrote:
>  Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George,
>  and several helpers have gotten nearly all of the python34 packages
>  moves over to python36 in EPEL-7.  They are being included in 6 Bodhi
>  pushes because of a limitation in Bodhi for the text size of packages
>  in an include.
>
>  The current day for these package groups to move into EPEL regular is
>  April 2nd. We would like to have all tests we find in the next week or
>  so also added so that the updates can occur in a large group without
>  too much breakage.
>
>
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9e9f81e581
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0d62608bce
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5be892b745
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0f4cca7837
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ed3564d906
>
>  Please heavily test them by doing the following:
>  Stage 1 Testing
>  Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  Install or enable the EPEL repository for this system
>  Install various packages you would normally use
>  yum --enablerepo=epel-testing update
>  Report problems to epel-devel(a)lists.fedoraproject.org
>  Stage 2 Testing
>  Check for any updated testing instructions on this blog or EPEL-devel list.
>  Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  Install or enable the EPEL repository for this system
>  yum install python34
>  yum --enablerepo=epel-testing update
>  Report problems to epel-devel(a)lists.fedoraproject.org
>  Stage 3 Testing
>  Check for any updated testing instructions on this blog or EPEL-devel list.
>  Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  Install or enable the EPEL repository for this system
>  yum install python36
>  yum --enablerepo=epel-testing update
>  Report problems to epel-devel(a)lists.fedoraproject.org
>  This should cover the three most common scenarios. Other scenarios
>  exist and will require some sort of intervention to work around. We
>  will outline them as they come up.
>
>  Many Many Thanks go to Troy, Jeroen, Carl, and the many people on the
>  python team who made a copr and did many of the initial patches to
>  make this possible.
>  --
>  Stephen J Smoogen 
Thank you to everyone for all the feedback, testing, fixes and discussion.
I believe all of the blocking problems have been worked out and that
we are ready to push these to stable.

I will be doing the push to stable in 4 hours.
If you have something you think is a blocker, please let me know before then.

We have found that there were some packages left off the list of
packages to rebuild.  This is not a blocker, but please let me know
and I will get them rebuilt and they will have their own smaller bodhi
update.

Troy Dawson

[Phil Wyett]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 2019-04-02 at 07:18 -0700, Troy Dawson wrote:
>  On Wed, Mar 13, 2019 at 7:31 AM Stephen John Smoogen
> <smooge(a)gmail.com&gt; wrote:
>  > 
>  > Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W George,
>  > and several helpers have gotten nearly all of the python34 packages
>  > moves over to python36 in EPEL-7.  They are being included in 6 Bodhi
>  > pushes because of a limitation in Bodhi for the text size of packages
>  > in an include.
>  > 
>  > The current day for these package groups to move into EPEL regular is
>  > April 2nd. We would like to have all tests we find in the next week or
>  > so also added so that the updates can occur in a large group without
>  > too much breakage.
>  > 
>  > 
>  > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada
>  > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9e9f81e581
>  > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0d62608bce
>  > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5be892b745
>  > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0f4cca7837
>  > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ed3564d906
>  > 
>  > Please heavily test them by doing the following:
>  > Stage 1 Testing
>  > Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  > Install or enable the EPEL repository for this system
>  > Install various packages you would normally use
>  > yum --enablerepo=epel-testing update
>  > Report problems to epel-devel(a)lists.fedoraproject.org
>  > Stage 2 Testing
>  > Check for any updated testing instructions on this blog or EPEL-devel list.
>  > Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  > Install or enable the EPEL repository for this system
>  > yum install python34
>  > yum --enablerepo=epel-testing update
>  > Report problems to epel-devel(a)lists.fedoraproject.org
>  > Stage 3 Testing
>  > Check for any updated testing instructions on this blog or EPEL-devel list.
>  > Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  > Install or enable the EPEL repository for this system
>  > yum install python36
>  > yum --enablerepo=epel-testing update
>  > Report problems to epel-devel(a)lists.fedoraproject.org
>  > This should cover the three most common scenarios. Other scenarios
>  > exist and will require some sort of intervention to work around. We
>  > will outline them as they come up.
>  > 
>  > Many Many Thanks go to Troy, Jeroen, Carl, and the many people on the
>  > python team who made a copr and did many of the initial patches to
>  > make this possible.
>  > --
>  > Stephen J Smoogen
>  
>  Thank you to everyone for all the feedback, testing, fixes and discussion.
>  I believe all of the blocking problems have been worked out and that
>  we are ready to push these to stable.
>  
>  I will be doing the push to stable in 4 hours.
>  If you have something you think is a blocker, please let me know before then.
>  
>  We have found that there were some packages left off the list of
>  packages to rebuild.  This is not a blocker, but please let me know
>  and I will get them rebuilt and they will have their own smaller bodhi
>  update.
>  
>  Troy Dawson
>  _______________________________________________
>  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/[e-mail]... 
Hi,

Just performed migration from 34 to 36. After yum update to pull all packages
and install, I proceeded to install 36 packages to match my current 34 install
before removing 34 packages. The only issue in the whole process was the one
below that required python34-pylint be removed before installing the 36 version.

[philwyett@ks-kenobi ~]$ sudo yum install python36-pylint
[sudo] password for philwyett: 
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-
              : manager
Resolving Dependencies
- --> Running transaction check
- ---> Package python36-pylint.noarch 0:1.6.5-5.el7 will be installed
- --> Processing Dependency: python36-setuptools for package: python36-pylint-
1.6.5-5.el7.noarch
- --> Running transaction check
- ---> Package python36-setuptools.noarch 0:39.2.0-3.el7 will be installed
- --> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package                    Arch          Version             Repository   Size
================================================================================
Installing:
 python36-pylint            noarch        1.6.5-5.el7         epel        437 k
Installing for dependencies:
 python36-setuptools        noarch        39.2.0-3.el7        epel        631 k

Transaction Summary
================================================================================
Install  1 Package (+1 Dependent package)

Total download size: 1.0 M
Installed size: 5.7 M
Is this ok [y/d/N]: y
Downloading packages:
(1/2): python36-pylint-1.6.5-5.el7.noarch.rpm              | 437 kB   00:01     
(2/2): python36-setuptools-39.2.0-3.el7.noarch.rpm         | 631 kB   00:01     
- --------------------------------------------------------------------------------
Total                                              591 kB/s | 1.0 MB  00:01     
Running transaction check
Running transaction test


Transaction check error:
  file /usr/bin/epylint-3 from install of python36-pylint-1.6.5-5.el7.noarch
conflicts with file from package python34-pylint-1.6.5-4.el7.noarch
  file /usr/bin/pylint-3 from install of python36-pylint-1.6.5-5.el7.noarch
conflicts with file from package python34-pylint-1.6.5-4.el7.noarch
  file /usr/bin/pyreverse-3 from install of python36-pylint-1.6.5-5.el7.noarch
conflicts with file from package python34-pylint-1.6.5-4.el7.noarch
  file /usr/bin/symilar-3 from install of python36-pylint-1.6.5-5.el7.noarch
conflicts with file from package python34-pylint-1.6.5-4.el7.noarch
  file /usr/share/man/man1/epylint-3.1.gz from install of python36-pylint-1.6.5-
5.el7.noarch conflicts with file from package python34-pylint-1.6.5-4.el7.noarch
  file /usr/share/man/man1/pylint-3.1.gz from install of python36-pylint-1.6.5-
5.el7.noarch conflicts with file from package python34-pylint-1.6.5-4.el7.noarch
  file /usr/share/man/man1/pylint-gui-3.1.gz from install of python36-pylint-
1.6.5-5.el7.noarch conflicts with file from package python34-pylint-1.6.5-
4.el7.noarch
  file /usr/share/man/man1/pyreverse-3.1.gz from install of python36-pylint-
1.6.5-5.el7.noarch conflicts with file from package python34-pylint-1.6.5-
4.el7.noarch
  file /usr/share/man/man1/symilar-3.1.gz from install of python36-pylint-1.6.5-
5.el7.noarch conflicts with file from package python34-pylint-1.6.5-4.el7.noarch

Error Summary
- -------------

Regards

Phil

- -- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Twitter: kathenasorg
IRC: kathenas
Web: https://kathenas.org
Github: https://github.com/kathenas
GitLab: https://gitlab.com/kathenas

GPG: A0C3 4C6A AC2B B8F4 F1E5 EDF4 333F 60DC B0B9 BB77
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBAgAGBQJcpbuhAAoJEDM/YNywubt3tXoQAIMuUcNr14+rBR4wHneT5uxZ
> 4d/QyJJHfOANEmv02qVcVr5ebfE5GFN9TDQ698YEGO8GmVxKt44c70NQq3T0csh5
> MjkCeDmghALuH3XAT/uqMJgBDAVLAE64VxJgD2arRD2xqoZVdD5L0W5ddCzYA9in
> LDAeWX0cKTllF29kBJjlF12WyfVwABa87eo8H7UK5vPQzo3BfsNfGf3zWwVdqW+e
> jfaCA5rZrMLoZ2b51bUZSPU1GY18oM+jLbLIE3hZI1I3Btt9aeWnxUTFIgj0zDSf
> 9VIgbRyU0kNwoUjh9Uc7lcGlWdd73Xx9Xtakeuch2svRArFtvT+UJZyLGkFsAsVk
> mHgeH+wNKCfBMymO7Sxc/3S7OZjZzRdW0TQjINCogupQ89B4SFdvLzCV2kAATixc
> Q0lwGpMYMt41YdVJtfnZrqiNxTpMH9xmRx/BTdS4lGm7iGHrxlsyLYcEVVlYCfL+
> ZLAwgkaOxTSAUbCKbZlB2UWA4enWIAsWUI/1kXUuAR4eMHNTDDaWlshJOpbIl3n2
> G4hG1LuOAKFNX5OR7K8ds405O8XzS1/IV5XXKohm8/AgTHzXUDDIwwB6PTxwVLL6
> nbkqKZKYFh738gMk6/dX1UrC85KaO96dqeUQhzLkIeTipdT+AmyxAWRYMyyWeMO8
> X8HUhyUeSh7/Cg1Czp1D
> =ygbq
> -----END PGP SIGNATURE-----

[Miro Hrončok]

On 04. 04. 19 10:08, Phil Wyett wrote:
>  Hi,
>  
>  Just performed migration from 34 to 36. After yum update to pull all packages
>  and install, I proceeded to install 36 packages to match my current 34 install
>  before removing 34 packages. The only issue in the whole process was the one
>  below that required python34-pylint be removed before installing the 36 version.
>  
>  [philwyett@ks-kenobi ~]$ sudo yum install python36-pylint
>  [sudo] password for philwyett:
>  Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-
>                 : manager
>  Resolving Dependencies
>  - --> Running transaction check
>  - ---> Package python36-pylint.noarch 0:1.6.5-5.el7 will be installed
>  - --> Processing Dependency: python36-setuptools for package: python36-pylint-
>  1.6.5-5.el7.noarch
>  - --> Running transaction check
>  - ---> Package python36-setuptools.noarch 0:39.2.0-3.el7 will be installed
>  - --> Finished Dependency Resolution
>  
>  Dependencies Resolved
>  
>  ================================================================================
>    Package                    Arch          Version             Repository   Size
>  ================================================================================
>  Installing:
>    python36-pylint            noarch        1.6.5-5.el7         epel        437 k
>  Installing for dependencies:
>    python36-setuptools        noarch        39.2.0-3.el7        epel        631 k
>  
>  Transaction Summary
>  ================================================================================
>  Install  1 Package (+1 Dependent package)
>  
>  Total download size: 1.0 M
>  Installed size: 5.7 M
>  Is this ok [y/d/N]: y
>  Downloading packages:
>  (1/2): python36-pylint-1.6.5-5.el7.noarch.rpm              | 437 kB   00:01
>  (2/2): python36-setuptools-39.2.0-3.el7.noarch.rpm         | 631 kB   00:01
>  - --------------------------------------------------------------------------------
>  Total                                              591 kB/s | 1.0 MB  00:01
>  Running transaction check
>  Running transaction test
>  
>  
>  Transaction check error:
>     file /usr/bin/epylint-3 from install of python36-pylint-1.6.5-5.el7.noarch
>  conflicts with file from package python34-pylint-1.6.5-4.el7.noarch
>     file /usr/bin/pylint-3 from install of python36-pylint-1.6.5-5.el7.noarch
>  conflicts with file from package python34-pylint-1.6.5-4.el7.noarch
>     file /usr/bin/pyreverse-3 from install of python36-pylint-1.6.5-5.el7.noarch
>  conflicts with file from package python34-pylint-1.6.5-4.el7.noarch
>     file /usr/bin/symilar-3 from install of python36-pylint-1.6.5-5.el7.noarch
>  conflicts with file from package python34-pylint-1.6.5-4.el7.noarch
>     file /usr/share/man/man1/epylint-3.1.gz from install of python36-pylint-1.6.5-
>  5.el7.noarch conflicts with file from package python34-pylint-1.6.5-4.el7.noarch
>     file /usr/share/man/man1/pylint-3.1.gz from install of python36-pylint-1.6.5-
>  5.el7.noarch conflicts with file from package python34-pylint-1.6.5-4.el7.noarch
>     file /usr/share/man/man1/pylint-gui-3.1.gz from install of python36-pylint-
>  1.6.5-5.el7.noarch conflicts with file from package python34-pylint-1.6.5-
>  4.el7.noarch
>     file /usr/share/man/man1/pyreverse-3.1.gz from install of python36-pylint-
>  1.6.5-5.el7.noarch conflicts with file from package python34-pylint-1.6.5-
>  4.el7.noarch
>     file /usr/share/man/man1/symilar-3.1.gz from install of python36-pylint-1.6.5-
>  5.el7.noarch conflicts with file from package python34-pylint-1.6.5-4.el7.noarch 
Thanks for the report. A fix:

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f076346dfb

-- 
Miro Hrončok
--
Phone: [phone]
IRC: mhroncok

EPEL-ANNOUNCE EPEL: Python34 moving to Python36

[Wart]

On 3/13/19 9:30 AM, Stephen John Smoogen wrote:
>  Over the last 5 days, Troy Dawson, Jeroen van Meeuwen, Carl W
> George,
>  and several helpers have gotten nearly all of the python34 packages
>  moves over to python36 in EPEL-7.  They are being included in 6 Bodhi
>  pushes because of a limitation in Bodhi for the text size of packages
>  in an include.
>  
>  The current day for these package groups to move into EPEL regular is
>  April 2nd. We would like to have all tests we find in the next week or
>  so also added so that the updates can occur in a large group without
>  too much breakage.
>  
>  
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-f2d195dada
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-9e9f81e581
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0d62608bce
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-5be892b745
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-0f4cca7837
>  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-ed3564d906
>  
>  Please heavily test them by doing the following:
>  Stage 1 Testing
>  Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  Install or enable the EPEL repository for this system
>  Install various packages you would normally use
>  yum --enablerepo=epel-testing update
>  Report problems to epel-devel(a)lists.fedoraproject.org
>  Stage 2 Testing
>  Check for any updated testing instructions on this blog or EPEL-devel list.
>  Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  Install or enable the EPEL repository for this system
>  yum install python34
>  yum --enablerepo=epel-testing update
>  Report problems to epel-devel(a)lists.fedoraproject.org
>  Stage 3 Testing
>  Check for any updated testing instructions on this blog or EPEL-devel list.
>  Install RHEL, CentOS, or Scientific Linux 7 onto a TEST system.
>  Install or enable the EPEL repository for this system
>  yum install python36
>  yum --enablerepo=epel-testing update
>  Report problems to epel-devel(a)lists.fedoraproject.org
>  This should cover the three most common scenarios. Other scenarios
>  exist and will require some sort of intervention to work around. We
>  will outline them as they come up. 
I've come across 3 packages that cause problems with the
python34-python36 migration:

python36-pyflakes:  Running 'yum install python36-pyflakes' on a system
with python34-pyflakes installed results in a conflict due to the
python3-prefixed executable and man pages:

Transaction check error:
  file /usr/bin/pyflakes-3 from install of
python36-pyflakes-1.6.0-4.el7.noarch conflicts with file from package
python34-pyflakes-1.3.0-2.el7.noarch
  file /usr/share/man/man1/pyflakes-3.1.gz from install of
python36-pyflakes-1.6.0-4.el7.noarch conflicts with file from package
python34-pyflakes-1.3.0-2.el7.noarch

python36-future, python36-pylint:  These explicitly "Obsolete:" the
python34 versions.  Presumably this is to avoid the conflict with the
man pages, like the above problem with pyflakes.

Forcing the removal of the python34 version of the packages can be
problematic for user communities (such as  mine) that are still working
to migrate their code from python34 to python36.

I can submit patches to resolve this, but I wonder what the policy
should be for auto-removing the python34 equivalents?

--Wart