Removing extraneous files on buildbots that block activation

[David Evans]

On 12/14/14 8:57 PM, Joshua Root wrote:
> On 2014-12-15 15:46 , David Evans wrote:
>> I've seen a number of instances recently on the buildbots where a port
>> fails on activation because of extraneous files left in the installation
>> tree by some previous failure.
>>
>> My most recent example is py27-cython on buildports-snowleopard-x86_64:
>>> Error: org.macports.activate for port py27-cython returned: Image error: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/cygdb already exists and does not belong to a registered port.  Unable to activate port py27-cython. Use 'port -f activate py27-cython' to force the activation.
>>> DEBUG: Error code: registry::image-error
>>> DEBUG: Backtrace: Image error: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/cygdb already exists and does not belong to a registered port.  Unable to activate port py27-cython. Use 'port -f activate py27-cython' to force the activation.
>> Typically this is occurs when the activation process is interrupted
>> before completion and is fixed by manually forcing the activation and
>> removing the offending file(s) that are moved aside in the process.
>>
>> Is there any way of fixing these problems on the buildbots as they occur
>> (or maybe when the buildbot is restarted) without resorting to manual
>> intervention by a sysadmin?
> This more commonly occurs because ports installed directly into $prefix
> instead of into ${destroot}${prefix} (this is often caught by sandboxing
> now.) So even if that's not what happened here, you could fix it the
> same way.
>
> - Josh
>
Yes, I've seen this occur as well but in this case, the offending port 
correctly activates on the other buildbots (and on my local machine) so 
I don't think there's anything to
fix in the port.  In this case, my port of interest is py-poppler and 
this dependency is breaking the build.

However this happens, once it does and even if the root cause in a port 
is fixed, the problem will continue until the offending file is removed 
and deactivating the port won't do it because it's seen as not belonging 
to a registered port.  I don't see anyway to remove the offending file 
on the buildbot without doing so manually and most folks don't have the 
access to do it.  So do we queue a request to the sysadmins when this 
occurs or is there some other way to deal with it that I'm not thinking of?

Dave