Removing extraneous files on buildbots that block activation

[Joshua Root]

On 2014-12-15 16:25 , David Evans wrote:
> 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?

This is the "same way" that I was referring to:

<https://lists.macosforge.org/pipermail/macports-dev/2014-November/028621.html>

- Josh