Comment 2 for bug 1198439

This could be related to the change in LP: #1058884 since the traceback lines up with the patched code. The os.rename() - which is just a shim around rename(2) - is producing an EPERM. The rename(2) manpage says:

       EPERM or EACCES
              The directory containing oldpath has the sticky bit (S_ISVTX)
              set and the process's effective user ID is neither the user ID
              of the file to be deleted nor that of the directory containing
              it, and the process is not privileged (Linux: does not have the
              CAP_FOWNER capability); or newpath is an existing file and the
              directory containing it has the sticky bit set and the
              process's effective user ID is neither the user ID of the file
              to be replaced nor that of the directory containing it, and the
              process is not privileged (Linux: does not have the CAP_FOWNER
              capability); or the file system containing pathname does not
              support renaming of the type requested.

Can you check to see if any of the above conditions exist? I think it would have to be in /usr/lib/python2.7 somewhere. Search for a .pyc file that has some numeric suffix, e.g. foo.pyc.123456