build-bot subport conflict issue

Joshua Root jmr at macports.org
Fri Mar 14 21:12:14 PDT 2014


On 2014-3-15 00:47 , Michael Dickens wrote:
> Some of my ports have required (and, in place) conflicts between
> subports -- for example, gnuradio (3.7 API) and gnuradio-legacy (3.6
> API). When I update a port which uses gnuradio and also provides a
> legacy subport (e.g., gr-osmosdr and gr-osmosdr-legacy), I get the
> following from the buildbots:
> 
> {{{
> Error: org.macports.activate for port gnuradio returned: Image error:
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/gnuradio/__init__.py
> is being used by the active gnuradio-legacy port.  Please deactivate
> this port first, or use "port -f activate gnuradio" to force the
> activation.
> }}}
> 
> So, it looks like gnuradio-legacy is installed to meet the requirements
> of the legacy subport, but the buildbot has moved on to the non-legacy
> port which requires just gnuradio, which conflicts with and cannot be
> activated over the gnuradio-legacy, and hence the subport fails because
> the buildbot is not handling the conflict correctly.
> 
> I've checked the ports which I maintain that use a release and legacy
> subport, and all of them (TTBOMK) have their conflicts correctly set up.
> 
> So .. since all the other subports work, I just ignore this issue.  But,
> it would be good to have it taken care of, whether on my end or on the
> buildbots.  Any ideas?  Thanks! - MLD

All ports are deactivated between builds. The only way this would happen
is if something had both gnuradio and gnuradio-legacy in its dependency
tree, which gr-osmosdr-legacy does (via gr-fcdproplus).

- Josh


More information about the macports-dev mailing list