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