Removing extraneous files on buildbots that block activation

[David Evans]

On 12/14/14 9:56 PM, Joshua Root wrote:
> 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
>
Thanks for this reference but I think you and are not on the same page 
here somehow.

I don't think that the problem here was caused by py27-cython but by 
some transient failure on just one buildbot.  So once the offending file 
or files are removed, I don't expect to see this happen again. If my 
theory is correct it doesn't seem appropriate to add code to py-cython 
that is only needed for one build.

I was thinking more along the lines of adding a cleanup script somewhere 
in the buildbot build script that scans the install tree and deletes 
extraneous files at a point when all installed ports are deactivated.

Dave