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

[MacPorts] #48278: MyPaint-devel: build brush engine library with optional GEGL support
by MacPorts 18 Oct '16

18 Oct '16

#48278: MyPaint-devel: build brush engine library with optional GEGL support -------------------------+--------------------------- Reporter: devans@… | Owner: ryandesign@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: MyPaint-devel -------------------------+--------------------------- Current versions of gimp2-devel have an optional dependency on MyPaint with GEGL support enabled to allow use of MyPaint brushes in GIMP. The pkgconfig requirement is {{{ libmypaint-gegl >= 1.1 }}} It appears this requires GEGL >= 0.3 so building with this functionality will require babl-devel, gegl-devel as well as gobject-introspection. See brushlib/README.md for details. -- Ticket URL: <https://trac.macports.org/ticket/48278> MacPorts <https://www.macports.org/> Ports system for OS X

1 7

[MacPorts] #48849: MyPaint-devel crashes on start
by MacPorts 18 Oct '16

18 Oct '16

#48849: MyPaint-devel crashes on start ---------------------------+-------------------------------- Reporter: bunk3m@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: MyPaint-devel | Port: MyPaint-devel ---------------------------+-------------------------------- Thought I should let you know that MyPaint-devel @1.2.0-beta.20150828+git.04511511_0 crashes on start. I'm not sure how to debug to provide more info to track down what's happening but I'm happy to help if you have time to guide me through that. The error I get from the Console app is: 2015-09-13 11:19:48.143 AM com.apple.xpc.launchd[1]: (com.github.mypaint.mypaint.MyPaint.5712[15553]) Service exited with abnormal code: 1 -- Ticket URL: <https://trac.macports.org/ticket/48849> MacPorts <https://www.macports.org/> Ports system for OS X

1 10

[MacPorts] #45616: Compile error with g++ 4.8.2
by MacPorts 14 Oct '16

14 Oct '16

#45616: Compile error with g++ 4.8.2 -------------------------+-------------------------------- Reporter: gsteele13@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.2 Keywords: | Port: boost -------------------------+-------------------------------- I recently reinstalled mac OS on my macbook, and in doing so, have switched from a 10.6 fink system to a 10.9 macports system. I was recently trying to compile some software (code available here http://nsweb.tn.tudelft.nl/~gsteele/spyview/) using the macports environment (primarily linking to librarires fltk and boost). The code compiled fine on my old 10.6 fink installation, but I am now getting the following error in 10.9 with macports: In file included from /opt/local/include/boost/limits.hpp:19:0, from /opt/local/include/boost/integer_fwd.hpp:16, from /opt/local/include/boost/integer.hpp:18, from /opt/local/include/boost/archive/basic_binary_iprimitive.hpp:49, from /opt/local/include/boost/archive/binary_iarchive_impl.hpp:21, from /opt/local/include/boost/archive/binary_iarchive.hpp:20, from myboost.h:5, from ImagePrinter.H:9, from ImageWindow.H:19, from spyview_ui.h:6, from spyview_ui.C:3: /opt/local/include/gcc48/c++/limits:1405:35: error: template argument 1 is invalid struct numeric_limits<__int128> I have also tried the apple-gcc42 compiler, and with this compiler, the code compiles fine, but fails at linking (I guess probably the gcc-4.8 c++ libraries are not linkable with gcc-4.2?). Has anyone else had this problem? Thanks, Gary -- Ticket URL: <https://trac.macports.org/ticket/45616> MacPorts <https://www.macports.org/> Ports system for OS X

1 5

[MacPorts] #48564: pdfpc: update to version 4.0.0, moved to github
by MacPorts 14 Oct '16

14 Oct '16

#48564: pdfpc: update to version 4.0.0, moved to github ----------------------+------------------- Reporter: devans@… | Owner: cal@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: pdfpc ----------------------+------------------- pdfpc repository has now moved to https://github.com/pdfpc/pdfpc/ where the latest version of the port is 4.0.0. Updates include the use of gstreamer-1.0 and libgee-0.8. Port libgee06 is no longer necessary. -- Ticket URL: <https://trac.macports.org/ticket/48564> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #48577: subversion 1.9.0+ causes port lint Portfile property checks to fail
by MacPorts 14 Oct '16

14 Oct '16

#48577: subversion 1.9.0+ causes port lint Portfile property checks to fail ----------------------+-------------------------------- Reporter: devans@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.3 Keywords: | Port: ----------------------+-------------------------------- This concerns the behavior of the '''port lint''' command when the standard svn properties have not been set on a given Portfile. Using subversion 1.8.14 and earlier, failure to set these properties on the Portfile results in the useful message: {{{ ---> Verifying Portfile for argyll Error: Missing subversion property on Portfile, please execute: svn ps svn:keywords Id Portfile ---> 1 errors and 0 warnings found. }}} However, after upgrading to subversion 1.9.0, the message is less helpful: {{{ $ port lint ---> Verifying Portfile for argyll Warning: Unable to check for svn:keywords property: svn: warning: W200017: Property 'svn:keywords' not found on '/opt/macports/trunk/dports/graphics/argyll/Portfile' svn: E200000: A problem occurred; see other errors for details child process exited abnormally ---> 0 errors and 0 warnings found. }}} The cause is due to the fact that, in 1.9.0, subversion now considers it an error if propget is executed on a file when the target property does not exist. In the earlier subversion versions, subversion does not generate an error and just returns with null output. The current code depends on this latter behavior to identify when a property has not been set. If subversion returns an error, the error is printed as shown in the 1.9.0 case. The new 1.9.0 behavior in this situation needs to be accommodated as well as that of the older versions. Tested in MacPorts 2.3.3 but examination of current subversion HEAD shows that the problem has not yet been dealt with. -- Ticket URL: <https://trac.macports.org/ticket/48577> MacPorts <https://www.macports.org/> Ports system for OS X

1 4

[MacPorts] #46897: llvm-3.7 @3.7-r229298: error: only virtual member functions can be marked 'override'
by MacPorts 12 Oct '16

12 Oct '16

#46897: llvm-3.7 @3.7-r229298: error: only virtual member functions can be marked 'override' --------------------------+------------------------ Reporter: ryandesign@… | Owner: jeremyhu@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: llvm-3.7 --------------------------+------------------------ llvm-3.7 failed to build on Lion: https://build.macports.org/builders/buildports-lion-x86_64/builds/27032 {{{ In file included from OrcMCJITReplacement.cpp:10: In file included from /opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/llvm-3.7/work/trunk/lib/ExecutionEngine/Orc/OrcMCJITReplacement.h:20: /opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/llvm-3.7/work/trunk/include/llvm/ExecutionEngine/Orc/LazyEmittingLayer.h:110:67: error: only virtual member functions can be marked 'override' bool provides(StringRef Name, bool ExportedSymbolsOnly) const override { ^~~~~~~~ llvm[3]: Compiling ValueEnumerator.cpp for Release+Debug+Asserts build if /usr/bin/clang++ -I/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/llvm-3.7/work/trunk/include -I/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/llvm-3.7/work/trunk/lib/Bitcode/Writer -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O3 -g -std=c++11 -fvisibility-inlines-hidden -fno- exceptions -fno-common -Wcast-qual -pipe -Os -arch x86_64 -stdlib=libc++ -I/opt/local/include -m64 -pedantic -Wno-long-long -Wall -W -Wno-unused- parameter -Wwrite-strings -Wcovered-switch-default -Wno-uninitialized -Wno-missing-field-initializers -Wno-comment -c -MMD -MP -MF "/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/llvm-3.7/work/trunk/lib/Bitcode/Writer/Release+Debug+Asserts/ValueEnumerator.d.tmp" -MT "/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/llvm-3.7/work/trunk/lib/Bitcode/Writer/Release+Debug+Asserts/ValueEnumerator.o" -MT "/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/llvm-3.7/work/trunk/lib/Bitcode/Writer/Release+Debug+Asserts/ValueEnumerator.d" ValueEnumerator.cpp -o /opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/llvm-3.7/work/trunk/lib/Bitcode/Writer/Release+Debug+Asserts/ValueEnumerator.o ; \ then /bin/mv -f "/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/llvm-3.7/work/trunk/lib/Bitcode/Writer/Release+Debug+Asserts/ValueEnumerator.d.tmp" "/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/llvm-3.7/work/trunk/lib/Bitcode/Writer/Release+Debug+Asserts/ValueEnumerator.d"; else /bin/rm "/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/llvm-3.7/work/trunk/lib/Bitcode/Writer/Release+Debug+Asserts/ValueEnumerator.d.tmp"; exit 1; fi 1 error generated. make[3]: *** [/opt/local/var/macports/build/_opt_mports_dports_lang_llvm-3.7/llvm-3.7/work/trunk/lib/ExecutionEngine/Orc/Release+Debug+Asserts/OrcMCJITReplacement.o] Error 1 }}} -- Ticket URL: <https://trac.macports.org/ticket/46897> MacPorts <https://www.macports.org/> Ports system for OS X

1 6

[MacPorts] #45675: Crypt lib fails to build on 10.10 with XCode 6.1
by MacPorts 11 Oct '16

11 Oct '16

#45675: Crypt lib fails to build on 10.10 with XCode 6.1 ---------------------+-------------------------------- Reporter: dhein@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.2 Keywords: | Port: ---------------------+-------------------------------- Getting errors like this: :info:build bn/bn_asm.c:734:2: error: integer constant is larger than the largest unsigned integer type :info:build sqr_add_c2(a,1,0,c2,c3,c1); :info:build ^ And lots of warnings like this: info:build bn/bn_asm.cbn/bn_asm.c::8888::33:: warning: warning: shift count >= width of type [-Wshift-count-overflow] :info:build mul_add(rp[0],ap[0],w,c1); :info:build ^~~~~~~~~~~~~~~~~~~~~~~~~ :info:build ./bn/bn_lcl.hshift count >= width of type [-Wshift-count- overflow] :info:build mul_add(rp[0],ap[0],w,c1); :info:build ^~~~~~~~~~~~~~~~~~~~~~~~~ :info:build ./bn/bn_lcl.h:315:7: note: expanded from macro 'mul_add' :info:build (c)= Hw(t); \ :info:build ^~~~~ :info:build ./bn/bn_lcl.h:296:34: note: expanded from macro 'Hw' :info:build #define Hw(t) (((BN_ULONG)((t)>>BN_BITS2))&BN_MASK2) :info:build ^ ~~~~~~~~ Full log is attached. -- Ticket URL: <https://trac.macports.org/ticket/45675> MacPorts <https://www.macports.org/> Ports system for OS X

1 9

[MacPorts] #47941: Submission: New port: py-triangle
by MacPorts 10 Oct '16

10 Oct '16

#47941: Submission: New port: py-triangle ------------------------+-------------------------------- Reporter: smithsp@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: py-triangle ------------------------+-------------------------------- Adds a port for the python bindings to the triangle library. -- Ticket URL: <https://trac.macports.org/ticket/47941> MacPorts <https://www.macports.org/> Ports system for OS X

1 7

[MacPorts] #48967: submission: port:qt5-kde
by MacPorts 10 Oct '16

10 Oct '16

#48967: submission: port:qt5-kde -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: qt5-kde -------------------------+-------------------------------- Marko Käning and I discussed the benefits of having a dedicated Qt5 ports on which future KF5 ports could depend in the past, and the idea became much more appealing just before summer after mcalhoun updated his long- neglected port:qt5-mac discarding my own months of work on this port almost completely. In short, this proposed port:qt5-kde : - currently provides Qt 5.5.0 - is coinstallable with Qt4 (but not other Qt5 port(s) of course) - incorporates a set of patches based on those for Qt4 that improve the user experience with KF5 apps (formerly provided as the +KDE variant) - uses the install layout based on the tried-and-true layout of the non- coinstallable port:qt4-mac; version-specific executables and libraries/frameworks are installed under ${prefix}/libexec/qt5, headerfiles under ${prefix}/include/qt5 and the rest under ${prefix}/share/qt5 and ${prefix}/share/doc/qt5 (which is how port:qt4-mac installed these items). I am convinced that this layout to be preferred when using Qt-based applications that adhere to Freedesktop conventions and are supposed to be able to interact and share resources with other Freedesktop applications (GTk/Gnome). - includes a patch that will allow (KF5) applications to find shared resources in the standard XDG-style locations (${prefix}/share, etc) rather than in OS X style locations (~/Library/Application Support, etc). This patch needs to be activated so doesn't affect (pure Qt) applications that were built without the activator. - provides a legacy variant that builds Qt 5.3.2; this is automatic on OS X 10.6 where that Qt version is the latest that can be built (requires port:clang-3.4 or port:clang-3.5). I believe the above feature set justifies having an additional, alternative Qt5 port. In order for dependent ports to function with both ports, I split up the Qt5 Portgroup in a qt5-mac and a qt5-kde Portgroup; the new Qt5 Portgroup contains a selection mechanism to force select either the one or the other but will also load the appropriate Portgroup as a function of whether port:qt5-mac or port:qt5-kde is installed. The default/fallback is to install port:qt5-mac ; the changes to the Qt5 Portgroup should be transparent (and are indeed according to my testing). Binary builds against port:qt5-mac will of course not function with port:qt5-kde. Therefore, the qt5-kde Portgroup defines a (default) variant (qt5kde) that should only be known to the build bots for ports that require port:qt5-kde specifically. A user having port:qt5-kde installed and requesting the install/upgrade of a generic Qt5 port (say, port:qt5-creator) will in fact request port:qt5-creator+qt5kde, which is not available in binary version. This mechanism is of course not tested exhaustively, and I am open to ways to improve it. As a bonus feature, this port also builds on Linux. ;) I'm uploading a tarchive that contains everything needed; uploading diffs wouldn't make a lot of sense (they wouldn't be easier to peruse than studying the Portfile, patches and portgroup files, IMHO). The evolution of this port can also be followed on my repo, github.com/RJVB/macstrop . -- Ticket URL: <https://trac.macports.org/ticket/48967> MacPorts <https://www.macports.org/> Ports system for OS X

1 41

[MacPorts] #47374: unison freezes entire machine
by MacPorts 10 Oct '16

10 Oct '16

#47374: unison freezes entire machine ----------------------+-------------------------------- Reporter: geezel@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: freeze | Port: unison ----------------------+-------------------------------- Running unison on a single folder with only a few (about 50) large files freezes the entire machine. Unison itself does not crash or display an error message, but it consumes more and more memory until the machine reboots. Other processes also become unresponsive, i.e. once the unison command is launched there is no way to recover. For reasons discussed in this ticket https://trac.macports.org/ticket/45621 this has been tested with various versions (unison 2.40.102 compiled against ocaml 4.01 and 4.02, and unison 2.48.3 against ocaml 4.01). They all exhibit the same behaviour. Unison on FreeBSD runs fine on the same set of files (all versions). Also, a temporary workaround on Mac OS X is to run unison with the option "copythreshold = 1024", which makes unison use rsync to transfer large files. This might well be an upstream bug. If anybody is able to confirm this behaviour I'd be willing to report it upstream. -- Ticket URL: <https://trac.macports.org/ticket/47374> MacPorts <https://www.macports.org/> Ports system for OS X

1 2