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