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@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@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@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.
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@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@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@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.
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.
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
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.
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.
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@gmail.com 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@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@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@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@lists.fedoraproject.org To unsubscribe send an email to devel-announce-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/devel-announce@lists.fedorapro... _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
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
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#comment-...
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?
On Mon, 25 Mar 2019 at 13:07, Miro Hrončok mhroncok@redhat.com 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#comment-...
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: +420777974800 IRC: mhroncok _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject...
On 3/25/19 10:18 AM, Stephen John Smoogen wrote:
On Mon, 25 Mar 2019 at 13:07, Miro Hrončok mhroncok@redhat.com 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#comment-...
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?
- python34
- python36
- 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
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.
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.
On Thu, Mar 28, 2019 at 8:22 AM Miro Hrončok mhroncok@redhat.com 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.
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
On Thu, 28 Mar 2019 13:22:26 +0100 Miro Hrončok mhroncok@redhat.com 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.
On 28. 03. 19 21:54, Tuomo Soini wrote:
On Thu, 28 Mar 2019 13:22:26 +0100 Miro Hrončok mhroncok@redhat.com 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.
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@redhat.com 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
On Wed, Mar 13, 2019 at 7:31 AM Stephen John Smoogen smooge@gmail.com 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@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@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@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
-----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@gmail.com 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@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@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@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@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject...
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
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
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@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@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@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
epel-devel@lists.fedoraproject.org
-
Chris -
Kevin Fenzi -
Miro Hrončok -
Neal Gompa -
Orion Poplawski -
Phil Wyett -
Stephen John Smoogen -
Troy Dawson -
Tuomo Soini -
Wart