Hide Forgot
Description of problem: after doing a fedup --network 20 to my fedora 19 laptop, i found several attempts to upgrade the python-six-1.3.0-1.fc19 to python-six-1.4.1-0.fc20 failing. since the python-six lib is crucial to many other python libraries, it cannot be simply removed. Version-Release number of selected component (if applicable): python-six-1.3.0-1.fc19 python-six-1.4.1-0.fc20 How reproducible: i don't know if this is reproducible, but every time i attempt to yum update, it tries and fails to update this package. --- # yum update Loaded plugins: langpacks, refresh-packagekit, versionlock Resolving Dependencies --> Running transaction check ---> Package python-six.noarch 0:1.3.0-1.fc19 will be updated ---> Package python-six.noarch 0:1.4.1-1.fc20 will be an update --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: python-six noarch 1.4.1-1.fc20 fedora 22 k Transaction Summary ================================================================================ Upgrade 1 Package Total download size: 22 k Downloading packages: No Presto metadata available for fedora Running transaction check Running transaction test Transaction test succeeded Running transaction Updating : python-six-1.4.1-1.fc20.noarch 1/2 error: unpacking of archive failed on file /usr/lib/python2.7/site-packages/six-1.4.1-py2.7.egg-info: cpio: rename Verifying : python-six-1.4.1-1.fc20.noarch 1/2 Verifying : python-six-1.3.0-1.fc19.noarch 2/2 Failed: python-six.noarch 0:1.3.0-1.fc19 python-six.noarch 0:1.4.1-1.fc20 Complete! --- Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: i did attempt to use pip-python to update the package to python-six-1.4.1, and although it seemed to put the correct package in place in the /usr/lib/python2.7/site-packages directory, yum still failed to recognize the upgrade. i removed the __db.00? files in /var/lib/rpm and have tried a yum clean all several times as well. nothing seems to make a difference.
well, i checked a machine on which i ran fedup --network 20 several days before my laptop and it does not suffer from the older python-six problem. i checked another laptop i ran fedup on several days after the errant laptop and it does not suffer either from the older python-six problem. it would seem that i just happened to update this particular laptop when the python-six update script piece was borked. does that sound correct? my next question: how can i fix this without a clean install?
well, i don't know how it had happened, but perhaps my pip install had downloaded the 1.4.1 version into the site-packages directory. so, in the end, i got it fixed by: 1. grabbing the 1.3.0-1.fc19 version from koji 2. removing the 1.4.1-0.fc20 egg version (directory) and the six.py* files from the site-packages directory 3. yum update that seemed to be less confusing to yum, and it upgraded successfully. closing the ticket.
Created attachment 868581 [details] removes six 1.3.0 egg-info before initial install
I hit something similar on RHEL 6.4 x86_64 and ppc64, except I didn't have a python-six-1.3.0 rpm. I was installing python-six-1.4.1 and it installs fine, but at runtime six 1.3.0 is being loaded on the python path and then dependencies fail which require six >= 1.4.1 (think openstack havana+). There was a six 1.3.0 egg-info file on the site-packages path which is a directory, and six 1.4.1 installs egg-info as a file, so there is some conflict there. Given I didn't have pip installed or a python-six-1.3.0 rpm, I have no idea how the six 1.3.0 egg-info directory got on the system. I worked around it by patching the six 1.4.1 rpm spec to remove the six 1.3.0 egg-info directory before the base install of six 1.4.1. I've attached the rpm spec patch. Granted the scriplet could be smarter, but I was in a rush. :)
So actually I think I figured out something else that had nothing to do with the patch I posted here, it wouldn't actually fix the issue. We have a system setup where we're installing packages from a yum repo (which is where my python-six-1.4.1 comes from) and then we're later setting up a test environment using pip and as part of that it installs nose version 1.3.0. I found out that there were build artifacts leftover for nose and six 1.3.0 under /tmp/pip-build-root/ so I have a feeling that when nose 1.3.0 was getting installed, it was somehow building six 1.3.0 and putting that in the python path. The six.py file wasn't overwritten but the egg was, and that's what screwed everything up. I'm not aware of any issues reported against nose if that's indeed what's making the six 1.3.0 show up, but the timestamps on my system from when those happened are the right around the same time (seconds apart maybe) so I have to believe it's related and not some problem with rpms.