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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev