Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#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: newclosed

Unable to reproduce.

$ sudo port install py-dsv
--->  Computing dependencies for py-dsv
--->  Dependencies to be installed: py24-dsv
--->  Fetching distfiles for py24-dsv
--->  Attempting to fetch DSV-1.4.0.tar.gz from http://superb-dca2.dl.sourceforge.net/python-dsv
--->  Verifying checksums for py24-dsv
--->  Extracting py24-dsv
--->  Configuring py24-dsv
--->  Building py24-dsv
--->  Staging py24-dsv into destroot
--->  Installing py24-dsv @1.4.0_0
--->  Activating py24-dsv @1.4.0_0
--->  Cleaning py24-dsv
--->  Fetching distfiles for py-dsv
--->  Verifying checksums for py-dsv
--->  Extracting py-dsv
--->  Configuring py-dsv
--->  Building py-dsv
--->  Staging py-dsv into destroot
--->  Installing py-dsv @1.4.0_0
--->  Activating py-dsv @1.4.0_0
--->  Cleaning py-dsv

py-dsv is a stub port. It doesn't install anything, other than a README.

$ port contents py-dsv
Port py-dsv contains:
  /opt/local/share/doc/py-dsv/README

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 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 in reply to:  5 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.

Note: See TracTickets for help on using tickets.