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
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
python2.7 (Ubuntu)
Expired
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)

Revision history for this message
Gisle Enåsen (enaasen) wrote :
Revision history for this message
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
Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.