January 2016 - macports-tickets - lists.macosforge.org

[MacPorts] #48835: wireshark @1.12.7: Build fails with default variant +lua
by MacPorts 06 Jan '16

06 Jan '16

#48835: wireshark @1.12.7: Build fails with default variant +lua -----------------------------+-------------------------------- Reporter: md14-macports@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: wireshark -----------------------------+-------------------------------- Building wireshark @1.12.7 fails after the upgrade to lua @5.3.1. {{{ $ sudo port -vs install wireshark ... CC lua_bitop.lo CC lrexlib.lo CC lrexlib_glib.lo CC lrexlib_glib_f.lo CC wslua_tvb.lo CC wslua_proto.lo CC wslua_int64.lo CC wslua_tree.lo ./lua_bitop.c:85:2: error: "Unknown number type, check LUA_NUMBER_* in luaconf.h" #error "Unknown number type, check LUA_NUMBER_* in luaconf.h" ^ 1 error generated. make[4]: *** [lua_bitop.lo] Error 1 ... Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_wireshark/wireshark/work/wireshark-1.12.7" && /usr/bin/make -j8 -w all Exit code: 2 Error: org.macports.build for port wireshark returned: command execution failed Warning: targets not executed for wireshark: org.macports.activate org.macports.build org.macports.destroot org.macports.install Please see the log file for port wireshark for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_net_wireshark/wireshark/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port wireshark failed }}} The build succeeds if the lua variant is disabled: {{{ $ sudo port -vs install wireshark -lua }}} For a similar issue with gnuplot and lua, see #48826. -- Ticket URL: <https://trac.macports.org/ticket/48835> MacPorts <https://www.macports.org/> Ports system for OS X

1 33

Re: [MacPorts] #40782: wireshark: update to 2.0.1 (was: wireshark-devel: update to 1.11.0)
by MacPorts 06 Jan '16

06 Jan '16

#40782: wireshark: update to 2.0.1 ------------------------------+----------------------- Reporter: ryandesign@… | Owner: hsivank@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: wireshark-devel | ------------------------------+----------------------- Changes (by mojca@…): * cc: ricci@… (added) Old description: > [https://www.wireshark.org/download.html#development_release wireshark > 1.11.0 is out]; you may want to update the wireshark-devel port to this > version. Note that with this version comes a major > [https://blog.wireshark.org/2013/10/switching-to- > qt/?utm_source=rss&utm_medium=rss&utm_campaign=switching-to-qt change > from gtk to qt]. New description: [https://www.wireshark.org/download.html wireshark 2.0.1 is out]; you may want to update the wireshark[-devel] port to this version. Note that with this version comes a major [https://blog.wireshark.org/2013/10/switching- to-qt/?utm_source=rss&utm_medium=rss&utm_campaign=switching-to-qt change from gtk to qt]. -- Comment: I'm attaching a `Portfile` for `wireshark` 2.0.1 using CMake. It is heavily based on msavory's template, but with a number of changes and not all the variants have been tested yet. I kept `post-destroot` as added by msavory, but I commented it out as I don't yet see the added value of it (Wireshark can do it automatically; not sure if also for GTK). I didn't test GTK3 yet, but it works nicely with quartz (if I just replace the version in the old configure-based installation starting from wireshark 1). I would suggest to retire `wireshark-devel` for now (`replaced_by wireshark`). If there is a need to keep Wireshark 1, a "`svn cp wireshark wireshark1`" from current and minor corrections should do (or major ones if there is need to keep the ports more similar to each other). See also the port abandonement ticket in #50243. -- Ticket URL: <https://trac.macports.org/ticket/40782#comment:54> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #50238: gpg2 can't connect to the agent specified in GPG_AGENT_INFO
by MacPorts 06 Jan '16

06 Jan '16

#50238: gpg2 can't connect to the agent specified in GPG_AGENT_INFO ---------------------------+-------------------------------- Reporter: neil_mayhew@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: gnupg2 | Port: ---------------------------+-------------------------------- I have a running `gpg-agent`: {{{ $ ps x | grep gpg 44980 ?? Ss 0:00.09 gpg-agent --daemon --write-env-file }}} The environment is set correctly: {{{ $ env | grep GPG GPG_AGENT_INFO=/tmp/gpg-qIkaon/S.gpg-agent:44980:1 }}} The socket exists: {{{ $ ls -l ${GPG_AGENT_INFO%%:*} srwxr-xr-x 1 mayhewn wheel 0 Jan 5 16:11 /tmp/gpg-qIkaon/S.gpg-agent }}} The environment file also exists: {{{ $ cat ~/.gpg-agent-info GPG_AGENT_INFO=/tmp/gpg-qIkaon/S.gpg-agent:44980:1 }}} However, when I run `gpg2` it can't find the agent: {{{ $ touch foo $ gpg2 --sign foo You need a passphrase to unlock the secret key for user: "Neil Mayhew <...>" 1024-bit DSA key, ID XXXXXXXX, created 2005-11-21 gpg: can't connect to the agent - trying fall back }}} At this point, it manages to find the agent that was started by `launchd`, and a pinentry dialog pops up on the screen. This is unfortunate, since I'm using `ssh` and not sitting in front of the computer. I've tried using `dtruss -f`, and as far as I can tell `gpg2` and its children never stat or open the socket, and in fact never refer to it at all. They do, however, try to stat `~/.gnupg/S.gpg-agent` which normally doesn't exist, but even if I symlink the actual socket to this location, `gpg2` still can't find the agent. -- Ticket URL: <https://trac.macports.org/ticket/50238> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #50213: globus-core: update
by MacPorts 06 Jan '16

06 Jan '16

#50213: globus-core: update ---------------------+------------------------- Reporter: mojca@… | Owner: dennisvd@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: globus-core ---------------------+------------------------- It seems that globus-core has been updated. -- Ticket URL: <https://trac.macports.org/ticket/50213> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #48832: dolfin @1.6.0_0+mpich+suitesparse ImportError
by MacPorts 06 Jan '16

06 Jan '16

#48832: dolfin @1.6.0_0+mpich+suitesparse ImportError ------------------------------+-------------------------------- Reporter: gideon.simpson@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: dolfin ------------------------------+-------------------------------- I just installed the new dolifn port, and I'm still getting: {{{ >>> import dolfin Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /site-packages/dolfin/__init__.py", line 16, in <module> from . import cpp File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /site-packages/dolfin/cpp/__init__.py", line 42, in <module> exec("from . import %s" % module_name) File "<string>", line 1, in <module> ImportError: cannot import name common }}} -- Ticket URL: <https://trac.macports.org/ticket/48832> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #50222: py-netcdf4: update to version 1.2.2, add support for Yython 3.5
by MacPorts 06 Jan '16

06 Jan '16

#50222: py-netcdf4: update to version 1.2.2, add support for Yython 3.5 ----------------------+------------------------ Reporter: mojca@… | Owner: sean@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: haspatch | Port: py-netcdf4 ----------------------+------------------------ I'm attaching a patch for an update of py-netcdf4 to version 1.2.2, also adding support for python 3.5. Some warnings show up that might be worth looking into: {{{ In file included from netCDF4/_netCDF4.c:269: In file included from /opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5 /site-packages/numpy/core/include/numpy/arrayobject.h:4: In file included from /opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5 /site-packages/numpy/core/include/numpy/ndarrayobject.h:18: In file included from /opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5 /site-packages/numpy/core/include/numpy/ndarraytypes.h:1781: /opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5 /site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2: warning: "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-W#warnings] #warning "Using deprecated NumPy API, disable it by " \ ^ netCDF4/_netCDF4.c:6459:86: warning: passing 'char **' to parameter of type 'const char **' discards qualifiers in nested pointer types [-Wincompatible-pointer-types] __pyx_v_ierr = nc_put_att_string(__pyx_t_6, __pyx_v_varid, __pyx_v_attname, 1, (&__pyx_v_datstring)); ^~~~~~~~~~~~~~~~~~~~ /opt/local/include/netcdf.h:1041:30: note: passing argument to parameter 'op' here size_t len, const char **op); ^ 2 warnings generated. }}} but I'm not sure where it comes from and it might not be relevant at all. -- Ticket URL: <https://trac.macports.org/ticket/50222> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #47330: SPRNG support for PETSc
by MacPorts 06 Jan '16

06 Jan '16

#47330: SPRNG support for PETSc ------------------------------+-------------------------------- Reporter: gideon.simpson@… | Owner: macports-tickets@… Type: request | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: petsc ------------------------------+-------------------------------- Could we add the SPRNG variant to the PETSc port (--download-sprng)? -- Ticket URL: <https://trac.macports.org/ticket/47330> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #49899: Can't set other graphics library variants than cairo
by MacPorts 06 Jan '16

06 Jan '16

#49899: Can't set other graphics library variants than cairo ------------------------+-------------------------------- Reporter: vsuorant@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: py-matplotlib ------------------------+-------------------------------- The default variant cairo is used even when specifying tkinter in the command line. The attached Portfile fixes the issue. -- Ticket URL: <https://trac.macports.org/ticket/49899> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #50042: py-sphinx-contrib: broken py26 subport
by MacPorts 06 Jan '16

06 Jan '16

#50042: py-sphinx-contrib: broken py26 subport --------------------+------------------------------- Reporter: petr@… | Owner: sean@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: py-sphinx-contrib --------------------+------------------------------- I discovered this when looking through some of my own build failures. For example on the Yosemite buildbot: {{{ [...] [OK] py-sphinx-contrib [FAIL] py26-sphinx-contrib [OK] py27-sphinx-contrib [...] }}} {{{ File "/opt/local/var/macports/build/_opt_local_var_macports_sources_svn.macports .org_trunk_dports_python_py-sphinx-contrib/py26-sphinx- contrib/work/7f39b7f255e3/argdoc/sphinxcontrib/argdoc/ext.py", line 122 all_patterns[char] = { K : re.compile(V) for K,V in patterns.items() } ^ SyntaxError: invalid syntax }}} Although I have not checked this in detail, this looks like a Py 2.6 language incompatibility, maybe caused by the update in r143552 or any of the earlier ones. I guess, we can just get rid of the py26 subport, just requires to check for dependents. -- Ticket URL: <https://trac.macports.org/ticket/50042> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #49511: scalapack: add test phase, define BLAS/LAPACK dependencies, don't install cmake files
by MacPorts 06 Jan '16

06 Jan '16

#49511: scalapack: add test phase, define BLAS/LAPACK dependencies, don't install cmake files -------------------------+----------------------- Reporter: dstrubbe@… | Owner: sean@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: haspatch | Port: scalapack -------------------------+----------------------- Enable test phase for scalapack. Doing so required setting MPIEXEC, allowing use of 'ps', and turning on BUILD_TESTING. Also, I found that about half of the tests failed, some after timing out (at 1500 s). To fix this, inspired by a Homebrew ticket I found, I need to avoid using the raw Accelerate framework. vecLibFort can be used instead. I also added variants to allow use of OpenBLAS or ATLAS instead. They all pass all the tests (promptly) now. Before, ScaLAPACK's own search for linear algebra libraries was being used, and could find a mix of Accelerate and ATLAS libraries depending on whether ATLAS was installed at the time or not, which is against the typical approach of MacPorts anyway. These issues did not seem to cause trouble in actual application usage for me, though maybe that is just a question of which routines were being used (since about half passed the tests). Removed some cmake files from installation which do not seem useful. -- Ticket URL: <https://trac.macports.org/ticket/49511> MacPorts <https://www.macports.org/> Ports system for OS X

1 1