package python2.7-minimal 2.7.4-2ubuntu3.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

Bug #1198439 reported by Gisle Enåsen on 2013-07-06
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
python2.7 (Ubuntu)
Undecided
Unassigned

Bug Description

Description: Ubuntu 13.04
Release: 13.04

software update/upgrade

ProblemType: Package
DistroRelease: Ubuntu 13.04
Package: python2.7-minimal 2.7.4-2ubuntu3.1
ProcVersionSignature: Ubuntu 3.8.0-26.38-generic 3.8.13.2
Uname: Linux 3.8.0-26-generic i686
ApportVersion: 2.9.2-0ubuntu8.2
Architecture: i386
Date: Sat Jul 6 13:03:11 2013
DuplicateSignature: package:python2.7-minimal:2.7.4-2ubuntu3.1:subprocess installed post-installation script returned error exit status 1
ErrorMessage: subprocess installed post-installation script returned error exit status 1
InstallationDate: Installed on 2013-02-01 (154 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release i386 (20121017.2)
MarkForUpload: True
SourcePackage: python2.7
Title: package python2.7-minimal 2.7.4-2ubuntu3.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
UpgradeStatus: Upgraded to raring on 2013-05-04 (62 days ago)

Gisle Enåsen (enaasen) wrote :
Barry Warsaw (barry) wrote :

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

Changed in python2.7 (Ubuntu):
status: New → Incomplete
tags: removed: need-duplicate-check
tags: added: bot-stop-nagging
Launchpad Janitor (janitor) wrote :

[Expired for python2.7 (Ubuntu) because there has been no activity for 60 days.]

Changed in python2.7 (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers