Description of problem:
The python-requests package fails to update/install.
Version-Release number of selected component (if applicable):
Attempt to install python-requests on F21 workstation by running the following command.
# yum install python-requests
The install fails. After confirming that the users wants to proceed, yum outputs the following:
python-requests-2.3.0-3.fc21.noarch.rpm | 90 kB 00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction (shutdown inhibited)
Installing : python-requests-2.3.0-3.fc21.noarch 1/1
Error unpacking rpm package python-requests-2.3.0-3.fc21.noarch
error: unpacking of archive failed on file /usr/lib/python2.7/site-packages/requests-2.3.0-py2.7.egg-info: cpio: rename
Verifying : python-requests-2.3.0-3.fc21.noarch 1/1
Yum should complete the install without problems.
The system is running Fedora workstation 21, but was installed as Fedora 18 or 19 (don't remember which). Obviously it's been upgraded a few times. Currently it is completely updated, except for the fact that GNOME wants to have deja-dup-nautilus installed, which depends on python-requests (which can't upgrade/install properly). I'd be happy to provide any further information about this specific system, but unfortunately I don't have another system to test how reproducible this bug is.
Same problem, after I upgraded from F20 to F21 with FedUp.
Is /usr/lib/python2.7/site-packages/requests-2.3.0-py2.7.egg-info owned by any rpm on your system?
rpm -qf /usr/lib/python2.7/site-packages/requests-2.3.0-py2.7.egg-info
Is there anything else odd about that file? (Is it a file, or something else?) Does it have the immutable attribute set somehow?
The error message is rpm (really cpio) telling you that it failed to replace /usr/lib/python2.7/site-packages/requests-2.3.0-py2.7.egg-info for some reason.
I can't update my python-requests package from 2.3.0-3 to 2.5.0-3 because of a similar problem (error: unpacking of archive failed [...] cpio: rename)
But it's not the same file (in the error message).
I can give you the requested informations but don't know how to retrieve it. Can you give me some shell commands ?
(In reply to Guillaume AMAT from comment #3)
> I can't update my python-requests package from 2.3.0-3 to 2.5.0-3 because of
> a similar problem (error: unpacking of archive failed [...] cpio: rename)
> But it's not the same file (in the error message).
I'm guessing the error is on /usr/lib/python2.7/site-packages/requests/packages/chardet? And that is a directory on your system right now? And you see this output from rpm -qf:
$ rpm -qf /usr/lib/python2.7/site-packages/requests/packages/chardet
file /usr/lib/python2.7/site-packages/requests/packages/chardet is not owned by any package
That means you have installed requests by some other means than RPM (like sudo pip install ...) and now RPM is failing to replace that directory with a symlink because of an age-old RPM limitation.
In that case, the solution is to just remove the requests package and reinstall it with yum. And maybe don't use "sudo pip install" in future :-)
sudo rm -rf /usr/lib/python2.7/site-packages/requests
sudo yum install python-requests
You were right :)
/usr/lib/python2.7/site-packages/requests-2.3.0-py2.7.egg-info isn't owned by any package. However, it is a directory, not a file. From ls:
drwxr-xr-x. 2 root root 4096 Jul 4 2014 requests-2.3.0-py2.7.egg-info
Can I just remove it solve the problem, or is there a better way?
Pip notes that I do have the package installed, but I can't recall installing it unless it was a dependency or something.
Additional possibly useful information:
$ ls -l /usr/lib/python2.7/site-packages/requests-2.3.0-py2.7.egg-info
-rw-r--r--. 1 root root 1 Jul 4 2014 dependency_links.txt
-rw-r--r--. 1 root root 6645 Jul 4 2014 installed-files.txt
-rw-r--r--. 1 root root 1 Jul 4 2014 not-zip-safe
-rw-r--r--. 1 root root 32290 Jul 4 2014 PKG-INFO
-rw-r--r--. 1 root root 3283 Jul 4 2014 SOURCES.txt
-rw-r--r--. 1 root root 9 Jul 4 2014 top_level.txt
$ ls -l /usr/lib/python2.7/site-packages/ | grep requests
drwxr-xr-x. 3 root root 4096 Aug 3 17:46 requests
drwxr-xr-x. 2 root root 4096 Jul 4 2014 requests-2.3.0-py2.7.egg-info
-rw-r--r--. 1 root root 32290 Aug 3 17:45 requests-2.3.0-py2.7.egg-info;549b64a4
-rw-r--r--. 1 root root 32290 Aug 3 17:45 requests-2.3.0-py2.7.egg-info;549b7dbe
-rw-r--r--. 1 root root 32290 Aug 3 17:45 requests-2.3.0-py2.7.egg-info;549b7dd9
-rw-r--r--. 1 root root 32290 Aug 3 17:45 requests-2.3.0-py2.7.egg-info;549ba62b
-rw-r--r--. 1 root root 32290 Aug 3 17:45 requests-2.3.0-py2.7.egg-info;549ee467
-rw-r--r--. 1 root root 32290 Aug 3 17:45 requests-2.3.0-py2.7.egg-info;549f0c64
-rw-r--r--. 1 root root 32290 Aug 3 17:45 requests-2.3.0-py2.7.egg-info;549f180d
-rw-r--r--. 1 root root 32290 Aug 3 17:45 requests-2.3.0-py2.7.egg-info;549f199f
Yeah, there is really no bug here. The error message is rpm saying it can't replace this unpackaged directory.
The solution is the same as in comment 4. Use "sudo pip uninstall" or just rm -rf the offending unpackaged directory/ies, and then reinstall requests.
As Dan says, there's really no bug on the Fedora package per se. Closing.
Thanks for reporting!
Ok, could we implement some more useful warning in RPM, like:
Can't replace directory with symlink.
Or, at least:
cpio: rename() failed
Was not very helpful.
Except strace/gdb, rpm -qpl new_pkg, etc., what is the proper way to diagnose
what is happening in such scenario?
(reopening the old bug to have some existing background story)
Same problem if a file tries to substitute a directory:
$ rpm -qpl nombre_programa-0.1-1.x86_64.rpm
$ rpm -qpl nombre_programa-0.2-1.x86_64.rpm
# rpm -i nombre_programa-0.1-1.x86_64.rpm
# rpm -U nombre_programa-0.2-1.x86_64.rpm
error: unpacking of archive failed on file /data/egg-dir: cpio: rename failed - Is a directory
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 21 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
*** Bug 1319071 has been marked as a duplicate of this bug. ***
(In reply to Pavel Raiskup from comment #10)
> Ok, could we implement some more useful warning in RPM, like:
> Can't replace directory with symlink.
> Or, at least:
> cpio: rename() failed
> cpio: rename
> Was not very helpful.
> Except strace/gdb, rpm -qpl new_pkg, etc., what is the proper way to diagnose
> what is happening in such scenario?
> (reopening the old bug to have some existing background story)
Yes, that make sense and previously rpm was displaying following message:
error: unpacking of archive failed on file /test/test: cpio: rename - failed - Is a directory
but creating of this message was broken in this commit . Now I am thinking if just fix the regression from commit  or improve the message more.
Fixed upstream in the way described in commit message:
- For general rename failure display "rename failed -" followed by
string representation of errno. This fixes regression from
- When rename fails with errno ISDIR, show special message:
File from package already exists as a directory in system
I think the severity of this bug is low so I will close this bug as upstream because it is fixed upstream and this will get into fedora when a new version of rpm will get into fedora. If you really need this fix in the current fedora then please reopen the bug.
*** Bug 1275058 has been marked as a duplicate of this bug. ***