June 2015 - macports-tickets - lists.macosforge.org

[MacPorts] #46733: Multiple definitons of flock TCL command cause problems, e.g., with restore_ports.tcl
by MacPorts 30 Sep '15

30 Sep '15

#46733: Multiple definitons of flock TCL command cause problems, e.g., with restore_ports.tcl --------------------+-------------------------------- Reporter: mta@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.99 Keywords: | Port: --------------------+-------------------------------- When I ran restore_ports.tcl after upgrading to Yosemite it failed with the error {{{ expected integer but got "-exclusive" obtaining lock on /opt/local/var/macports/registry/.registry.lock while executing "registry::exclusive_lock" (procedure "mportexec" line 32) invoked from within "mportexec $workername $install_target" Unable to execute target 'install' for port 'fftw-3-single': expected integer but got "-exclusive" obtaining lock on /opt/local/var/macports/registry/.registry.lock while executing "install_ports $operationList" (file "restore_ports/restore_ports.tcl" line 300) }}} I tracked this down to the fact that there are two definitions of the flock TCL command installed as part of MacPorts. One is defined in TclX_FlockObjCmd which is in base/vendor/tclx8.4/generic/tclXflock.c. The other is defined in FlockCmd which is in base/src/pextlib1.0/flock.c. Macports seems to want, and get, the latter one. For some reason restore_ports sometimes, but not always, gets the other. Commenting out the call to TclX_FlockInit in Tclxcmd_Init which is in base/vendor/tclx8.4/generic/tclXinit.c seems to have fixed the problem. Unfortunately this isn't all that easy to do as part of the build since these files are installed unchanged from vendor archives. Perhaps a new archive with the appropriate change needs to be part of the MacPorts package. -- Ticket URL: <https://trac.macports.org/ticket/46733> MacPorts <https://www.macports.org/> Ports system for OS X

1 5

[MacPorts] #47283: Backslashes in file names in destroot cause activate to fail
by MacPorts 30 Sep '15

30 Sep '15

#47283: Backslashes in file names in destroot cause activate to fail ---------------------------------+-------------------------------- Reporter: jpo@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.3 Keywords: backslash, activate | Port: ---------------------------------+-------------------------------- Seems like a simple enough fix for anyone who is familiar with TCL and the base plumbing. I'm not unfortunately. Consider the following: {{{ PortSystem 1.0 name backslash-test version 1 categories devel platforms darwin description tests backslashes in filenames for the activate target fetch {} checksum {} use_configure no build {} destroot { touch "${destroot}${prefix}/share/back\\slash" } }}} Which produces the following results {{{ $ sudo port destroot backslash-test ---> Fetching distfiles for backslash-test ---> Verifying checksums for backslash-test ---> Extracting backslash-test ---> Configuring backslash-test ---> Building backslash-test ---> Staging backslash-test into destroot $ find backslash-test -type f backslash-test/work/.macports.backslash-test.state backslash-test/work/destroot/opt/local/share/back\slash $ sudo port activate backslash-test $ sudo port install backslash-test ---> Activating backslash-test @1_0 Error: org.macports.activate for port backslash-test returned: Image error: Source file /opt/local/var/macports/software/backslash- test/mpextractFapBvhDF/opt/local/share/back lash does not appear to exist (cannot lstat it). Unable to activate port backslash-test. Please see the log file for port backslash-test for details: /opt/local/var/macports/logs /_Volumes_case_src_macports_devel_backslash-test/backslash-test/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port backslash-test failed }}} I've attached a full log of an install of the above portfile from a clean state. -- Ticket URL: <https://trac.macports.org/ticket/47283> MacPorts <https://www.macports.org/> Ports system for OS X

1 11

[MacPorts] #46948: valgrind-devel suppressions file
by MacPorts 28 Sep '15

28 Sep '15

#46948: valgrind-devel suppressions file -------------------------+-------------------------------- Reporter: jhi@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: valgrind-devel -------------------------+-------------------------------- Hi, I just learned that while the main valgrind port doesn't yet support Yosemite, there is valgrind-devel, which does. Great, thanks for that! It seems that there are some purported leaks from system libraries (I'm running Yosemite 10.10.2, kernel 14.1.0). I used --gen-suppressions=all to create a suppressions file, which you might find useful. I left the suppressions as they were, didn't collapse any of the "stack traces", and named them unimaginatively just "leakN". -- Ticket URL: <https://trac.macports.org/ticket/46948> MacPorts <https://www.macports.org/> Ports system for OS X

1 7

[MacPorts] #47558: valgrind-devel build failure with Xcode 6.3.1 (apple clang 6.1)
by MacPorts 28 Sep '15

28 Sep '15

#47558: valgrind-devel build failure with Xcode 6.3.1 (apple clang 6.1) -----------------------+-------------------------------- Reporter: william@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: valgrind-devel -----------------------+-------------------------------- It looks as if the compiler version detection fails for current Xcode command-line tools … main.log attached. -- Ticket URL: <https://trac.macports.org/ticket/47558> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #47649: [Port Abandoned] redis
by MacPorts 25 Sep '15

25 Sep '15

#47649: [Port Abandoned] redis --------------------+---------------------------- Reporter: mf2k@… | Owner: brianjlandau@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: redis --------------------+---------------------------- The maintainer of redis has not responded to tickets in years. The port currently has [query:status=assigned&status=new&status=reopened&port=~redis&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority an open ticket]. -- Ticket URL: <https://trac.macports.org/ticket/47649> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #46029: port submission: qtchooser
by MacPorts 25 Sep '15

25 Sep '15

#46029: port submission: qtchooser ------------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: submission | Status: new Priority: High | Milestone: Component: ports | Version: 2.3.3 Keywords: qt4-mac, qt5-mac | Port: ------------------------------+-------------------------------- Please find attached a portfile with an initial set-up for qtchooser, the utility that makes it possible/easy to have Qt4 and Qt5 (and soon enough probably Qt6) installed in parallel. It replaces certain of the standard Qt binaries (like qmake) with links to itself, and then uses configuration files and (optional) arguments to determine what version of the binary in question is called. Thus, with qmake a symlink to qtchooser > qmake --version # prints the version of the default Qt installation > qmake -qt=4 --version # prints the version of the Qt4 installation > qmake -qt=5 --version # prints the version of the Qt5 installation What's missing are the configuration files that will determine which Qt goes and is expected where, though I have given an upbeat by assuming that'd be ${prefix}/libexec/qtN . I hope this helps and brings the possibility to have concurrent qt4-mac and qt5-mac installs a step closer. -- Ticket URL: <https://trac.macports.org/ticket/46029> MacPorts <https://www.macports.org/> Ports system for OS X

1 18

[MacPorts] #47549: opencv @2.4.11_0 - fails to load tiff files
by MacPorts 23 Sep '15

23 Sep '15

#47549: opencv @2.4.11_0 - fails to load tiff files -----------------------------+-------------------------------- Reporter: jose.goicolea@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: opencv -----------------------------+-------------------------------- The latest version of opencv @2.4.11_0 fails when loading .tiff files. However, if I activate the previous version @2.4.10 _0 it runs ok. My operating system is mac OS X 10.7.5, xcode version 4.6.2 I noticed the problem when running auto-multiple-choice, which uses the opencv libraries. With the help of the auto-multiple-choice developer, we have spotted the problem and reproduced it in a basic example. This example includes a simple load.c file and a tiff file, included. The compilation and execution commands for the test case I provide are {{{ gcc -I/opt/local/include/opencv -I/opt/local/include -L/opt/local/lib -lopencv_core -lopencv_highgui -lopencv_imgproc load.c -o load ./load t6_0000.tif }}} Under opencv @2.4.10_0 it compiles and runs ok (no output expected). Under opencv @2.4.11_1 it fails with "Segmentation fault: 11". I have run it with gdb and backtrace, the output is: {{{ Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x000000010720e180 0x000000010060dadc in put1bitbwtile () (gdb) backtrace #0 0x000000010060dadc in put1bitbwtile () #1 0x000000010060b7b0 in gtStripContig () #2 0x000000010060953d in TIFFReadRGBAStrip () #3 0x000000010027f264 in cv::TiffDecoder::readData () #4 0x0000000100262a9a in cv::imread_ () #5 0x000000010026651f in cvLoadImage () #6 0x000000010000322b in main () (gdb) }}} Regards -- Ticket URL: <https://trac.macports.org/ticket/47549> MacPorts <https://www.macports.org/> Ports system for OS X

1 7

[MacPorts] #47949: gringo 4.4 does not compile: no usable C++ compiler found
by MacPorts 19 Sep '15

19 Sep '15

#47949: gringo 4.4 does not compile: no usable C++ compiler found ---------------------------+-------------------------------- Reporter: damien.pous@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: gringo ---------------------------+-------------------------------- {{{ :info:build Checking for re2c... yes :info:build Checking whether the C++ compiler works... no :info:build error: no usable C++ compiler found :info:build Command failed: cd "/opt/local/var/macports/build/_opt_local_var_ma cports_sources_rsync.macports.org_release_ports_math_gringo/gringo/work/gringo-4 .4.0-source" && scons --build-dir=release gringo clingo :info:build Exit code: 1 }}} Failing build log is attached. I am running Mac OS 10.6.8. Macports installed gringo without any problem on a more recent machine, but I think I did not have to compile it locally. -- Ticket URL: <https://trac.macports.org/ticket/47949> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #46621: Update: lua 5.3.0
by MacPorts 19 Sep '15

19 Sep '15

#46621: Update: lua 5.3.0 ----------------------------+-------------------------------- Reporter: mschamschula@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: haspatch | Port: lua ----------------------------+-------------------------------- lua has been updated to version 5.3.0: Its main new features are support for integers, bitwise operators, and a basic utf-8 library. -- Ticket URL: <https://trac.macports.org/ticket/46621> MacPorts <https://www.macports.org/> Ports system for OS X

1 20

[MacPorts] #46551: New port submission: gnss-sdr
by MacPorts 18 Sep '15

18 Sep '15

#46551: New port submission: gnss-sdr --------------------------------+-------------------------------- Reporter: carles.fernandez@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: gnss-sdr --------------------------------+-------------------------------- GNSS-SDR [http://gnss-sdr.org] is an open source Global Navigation Satellite Systems software defined receiver. It implements all the processing chain from raw samples of GPS or Galileo signals to the computation of position and time, and can work either with raw samples stored in a file or in real-time with suitable radio frequency front-ends. This port comes in three flavors: port gnss-sdr -> This port is kept up with the GNSS-SDR release, currently 0.0.5, which is typically updated every few months. This version compiles against the gnuradio port, which represents the current GNU Radio release. port gnss-sdr-devel -> This port is kept up with the GNSS-SDR GIT ’next’ branch, which is typically updated daily to weekly. This version of GNSS- SDR generally contains fixes and new features that will be incorporated in an upcoming release, and compiles against the gnuradio-devel port, which represents GNU Radio GIT 'master' branch. This port may or not compile or function correctly, as it represents a work in progress. If it does not work, check back in a few days. Or try deactivating the currently active gnss-sdr and gnuradio ports, cleaning any current builds, and trying again. port gnss-sdr-next -> This port is kept up with the GNSS-SDR GIT ’next’ branch, which is typically updated daily to weekly. This version of GNSS- SDR generally contains fixes and new features that will be incorporated in an upcoming release, and compiles against the gnuradio-next port, which represents GNU Radio GIT ’next’ branch. This port may or not compile or function correctly, as it represents a work in progress. If it does not work, check back in a few days. Or try deactivating the currently active gnss-sdr and gnuradio ports, cleaning any current builds, and trying again. Tested on OS X 10.9, Macports 2.3.3, Xcode 6.1.1. -- Ticket URL: <https://trac.macports.org/ticket/46551> MacPorts <https://www.macports.org/> Ports system for OS X

1 8