#40310 closed defect (invalid)
py-dsv: py-dsv and py24-dsv install the same files and conflict with each other
Reported by: | mojca (Mojca Miklavec) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | ryandesign (Ryan Carsten Schmidt) | |
Port: | py-dsv |
Description
From the buildbot:
---> Activating py-dsv @1.4.0_0 DEBUG: Using /usr/bin/tar DEBUG: Using /usr/bin/bzip2 x ./ x ./+COMMENT x ./+CONTENTS x ./+DESC x ./+PORTFILE x ./+STATE x ./opt/ x ./opt/local/ x ./opt/local/lib/ x ./opt/local/share/ x ./opt/local/share/doc/ x ./opt/local/share/doc/py-dsv/ x ./opt/local/share/doc/py-dsv/README x ./opt/local/lib/python2.4/ x ./opt/local/lib/python2.4/site-packages/ x ./opt/local/lib/python2.4/site-packages/DSV/ x ./opt/local/lib/python2.4/site-packages/DSV/__init__.py x ./opt/local/lib/python2.4/site-packages/DSV/__init__.pyc x ./opt/local/lib/python2.4/site-packages/DSV/DSV.py x ./opt/local/lib/python2.4/site-packages/DSV/DSV.pyc Error: org.macports.activate for port py-dsv returned: Image error: /opt/local/lib/python2.4/site-packages/DSV/DSV.py is being used by the active py24-dsv port. Please deactivate this port first, or use 'port -f activate py-dsv' to force the activation. DEBUG: Error code: registry::image-error DEBUG: Backtrace: Image error: /opt/local/lib/python2.4/site-packages/DSV/DSV.py is being used by the active py24-dsv port. Please deactivate this port first, or use 'port -f activate py-dsv' to force the activation.
Change History (6)
comment:1 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… added |
---|---|
Resolution: | → invalid |
Status: | new → closed |
comment:2 Changed 11 years ago by mojca (Mojca Miklavec)
Is it possible that it needs a revbump then? It might be that the server has an existing version of py-dsv
installed. See https://build.macports.org/builders/buildports-mtln-x86_64/builds/7570.
comment:3 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
I find no packages for py-dsv: http://packages.macports.org/py-dsv
The buildbots never keep any ports installed. All ports are uninstalled after every build.
The buildbot log you linked to above concerns 43 ports. Examining logs that large taxes my computer so it will take some time for me to look through it and see what failures it contains.
comment:4 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
py-robotframework-ride failed because:
Error: Cannot install py-robotframework-ride for the arch(s) 'i386' because Error: its dependency py27-robotframework-ride only supports the arch(s) 'x86_64'.
The port says:
# TODO: this is not a proper way to do it; # wxWidgets.use should take care of supported architectures # depending on whether the port depends on carbon or gtk variant of wxpython-2.8 universal_variant no supported_archs i386
It's not proper for py-robotframework-ride (or any py- stub port) to have supported_archs set to anything other than noarch
(which is what the python portgroup sets it to).
I thought the wxpython portgroup already took care of this. Can't those 5 lines just be removed from the port?
py26-robotframework-ride failed because:
Error: Dependency 'py26-wxpython-3.0' not found.
py27-wxpython-3.0 failed because:
In file included from src/helpers.cpp:17: include/wx/wxPython/wxPython_int.h:35:10: fatal error: 'wx/wx.h' file not found #include <wx/wx.h> ^
py24-wxpython-2.8, py25-wxpython-2.8, py26-wxpython-2.8 and py27-wxpython-2.8 failed because:
src/helpers.cpp:28:10: fatal error: 'gdk/gdk.h' file not found #include <gdk/gdk.h> ^
py-dsv failed because:
Error: org.macports.activate for port py-dsv returned: Image error: /opt/local/lib/python2.4/site-packages/DSV/DSV.py is being used by the active py24-dsv port. Please deactivate this port first, or use 'port -f activate py-dsv' to force the activation.
The log only shows activation; I guess the reason why it didn't do the phases before that and why it still contains the pre-unification contents is that Joshua forgot to increase the port's revision when he unified it in r102032. Thanks for increasing the revision in r110421 to fix this.
grass failed because:
Error: /usr/bin/llvm-gcc-4.2 -E -I/opt/local/include -DPACKAGE="grasslibs" -DPACKAGE="grasslibs" -I/opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/grass-6.4.2/dist.i386-apple-darwin12.3.0/include: In file included from /usr/include/stdio.h:64, Error: /usr/bin/llvm-gcc-4.2 -E -I/opt/local/include -DPACKAGE="grasslibs" -DPACKAGE="grasslibs" -I/opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/grass-6.4.2/dist.i386-apple-darwin12.3.0/include: from /opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/grass-6.4.2/dist.i386-apple-darwin12.3.0/include/grass/gis.h:24, Error: /usr/bin/llvm-gcc-4.2 -E -I/opt/local/include -DPACKAGE="grasslibs" -DPACKAGE="grasslibs" -I/opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/grass-6.4.2/dist.i386-apple-darwin12.3.0/include: from /opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/grass-6.4.2/dist.i386-apple-darwin12.3.0/include/grass/stats.h:5, Error: /usr/bin/llvm-gcc-4.2 -E -I/opt/local/include -DPACKAGE="grasslibs" -DPACKAGE="grasslibs" -I/opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/grass-6.4.2/dist.i386-apple-darwin12.3.0/include: from /opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/.tmp/tmp1UOQVF.h:1: Error: /usr/bin/llvm-gcc-4.2 -E -I/opt/local/include -DPACKAGE="grasslibs" -DPACKAGE="grasslibs" -I/opt/local/var/macports/build/_opt_mports_dports_gis_grass/grass/work/grass-6.4.2/dist.i386-apple-darwin12.3.0/include: /usr/include/sys/cdefs.h:81:2: warning: #warning "Unsupported compiler detected"
You reported #40307 for this.
comment:5 follow-up: 6 Changed 11 years ago by mojca (Mojca Miklavec)
I fixed all py2*-wxpython-*
ports now (one was a bug in wxWidgets 2.9.4 and the rest was mostly a missing pkg-config
dependency). The problem is that there is also a bunch of other ports in that build that failed because of broken wxpython
and it is not clear to me which ones of those need a revbump and for which a rebuild would be sufficient: spe stimfit relax py26-pyphant py-winpdb
(maybe also py-pyface bittorrent
). Some wxPython
dependencies only call python code from wxPython
in which case there is no need for a revbump. I have no clue which ones also compile parts of the code that would actually link to some wxWidgets' .dylib
.
So what is the following line doing in py-robotframework-ride
then?
notes "To run, use 'arch -i386 ride.py-${python.branch}' to use 32bit architecture"
comment:6 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to mojca@…:
The problem is that there is also a bunch of other ports in that build that failed because of broken
wxpython
and it is not clear to me which ones of those need a revbump and for which a rebuild would be sufficient
I would say if they failed to build, they don't need a revbump, but you could ask the buildbot to try building them again now.
So what is the following line doing in
py-robotframework-ride
then?notes "To run, use 'arch -i386 ride.py-${python.branch}' to use 32bit architecture"
It's telling users how to run ride.py-${python.branch}
, in the event that the port was installed for i386 on an x86_64 system.
Unable to reproduce.
py-dsv is a stub port. It doesn't install anything, other than a README.