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

[MacPorts] #49452: rsync.macports.org is very slow
by MacPorts 17 Oct '16

17 Oct '16

#49452: rsync.macports.org is very slow -------------------------+-------------------------------- Reporter: lpancescu@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: -------------------------+-------------------------------- I installed MacPorts 2.3.4 using the official pkg installer on OS X 10.11.1 (first on Saturday, and now again, to try to figure out why it takes 52 minutes on my Mac Mini "late 2009"). The last 30 minutes of that time are spent by tclsh building the PortIndex, already reported as bug #49050. The first 20 minutes seem to be just the rsync-ing of base.tar and ports.tar, with a transfer rate jumping between 14KB/s and 33KB/s, as seen in Activity Monitor. To make sure this isn't due to a regression in El Capitan, I tried rsync- ing base.tar manually from my Fedora netbook, and compared the main server, rsync.macports.org, with the French mirror (I'm in Germany): {{{ $ time rsync -rztv rsync://rsync.macports.org/release/tarballs/base.tar . receiving incremental file list base.tar sent 48 bytes received 14,253,729 bytes 21,678.75 bytes/sec total size is 27,013,120 speedup is 1.90 real 10m57.161s user 0m0.696s sys 0m0.907s $ rm base.tar $ time rsync -rztv rsync://lil.fr.rsync.macports.org/release/tarballs/base.tar . _ _ _ | | o | | | | | | | | | | ,_ ,_ , _ _ __ _ _ _ __, __ _ __ ,_ _|_ , __ ,_ __, |/ | |/ |/ / | / | / \_ | | / |/ | / / |/ |/ | / | / |/ \_ / \_ / | | / \_ / \_ / | / | |__/ |_/ |__/ o |__/ |_/ o |_/ \/ \_/|/ | |_/ \___/ o | | |_/ \_/|_/ \___/ |__/ \__/ |_/ |_/ \/ o \__/ |_/ \_/|/ |\ /| /| /| |/ \| \| \| rsync://lil.fr.rsync.macports.org rsync://rsync.ionic.de rsync://macports.rsync.ionic.de This is your local MacPorts mirror. You may sync whenever and how often you want, but keep in mind, that we enforce a maximum of 5 (five) concurrent connections per host. If you feel this is too little, please contact the administration. The server is physically located in Roubaix, France and hosted by OVH. It though features a German RIPE failover IP. If any problems or questions arise, please contact Mihai Moldovan <ionic(a)ionic.de>, Karlsruhe, Germany (primary) or Joerg Hoffmann <jh2000(a)root24.eu>, Nordholz, Germany. receiving incremental file list base.tar sent 43 bytes received 14,254,789 bytes 1,357,603.05 bytes/sec total size is 27,013,120 speedup is 1.90 real 0m10.873s user 0m0.719s sys 0m0.782s }}} Is rsync.macports.org intentionally limiting its bandwidth for clients outside the USA? Unfortunately, I didn't see any option of selecting a different mirror in the pkg installer. -- Ticket URL: <https://trac.macports.org/ticket/49452> MacPorts <https://www.macports.org/> Ports system for OS X

1 15

[MacPorts] #49842: Update vCenter Server to 5.5 Update 3a
by MacPorts 17 Oct '16

17 Oct '16

#49842: Update vCenter Server to 5.5 Update 3a ----------------------------+--------------------- Reporter: ryandesign@… | Owner: admin@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: server/hosting | Version: Keywords: | Port: ----------------------------+--------------------- We are currently running vCenter Server 5.5 Update 2e. We should upgrade to [http://pubs.vmware.com/Release_Notes/en/vsphere/55/vsphere-vcenter- server-55u3a-release-notes.html 5.5 Update 3a] because this will allegedly fix the problems with uploading files to datastores with modern browsers that don't support the old Netscape Plugin Application Programming Interface (NPAPI). -- Ticket URL: <https://trac.macports.org/ticket/49842> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #49759: git checkout should produce some output
by MacPorts 16 Oct '16

16 Oct '16

#49759: git checkout should produce some output --------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.4 Keywords: | Port: --------------------------+-------------------------------- [https://build.macports.org/builders/buildports-snowleopard- x86_64/builds/38635 This buildbot build] was interrupted after the third of seven ports, because there was no output for 20 minutes. A git clone command was running at the time, but had not yet completed. Run locally on a fast network, that git clone completes in 2.5 minutes and the clone occupies 372MB. Run on the buildbot builder, the same command has only downloaded 211MB by the 20 minute mark. For whatever reason there is a slow network connection between our builder and this git server, at least right now. The git clone commands are being run by MacPorts base with the -q flag to suppress all output. Can we change this so that some output is produced while cloning, so that the buildbot knows the build is not stuck? I agree the buildbot should abort builds that don't produce output for a time, but they shouldn't interrupt file transfers which are just progressing slowly, and this shouldn't cause subsequent ports in the portlist not to be tried. -- Ticket URL: <https://trac.macports.org/ticket/49759> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #49812: buildbots: compile failures due to stalled bzr fetches
by MacPorts 15 Oct '16

15 Oct '16

#49812: buildbots: compile failures due to stalled bzr fetches ----------------------------+-------------------------- Reporter: devans@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: server/hosting | Version: Keywords: | Port: ----------------------------+-------------------------- Recent attempts to build inkscape-devel are causing the buildbots to abort with a compile failure. Examination of the stdio log file shows that builds stall waiting for the bzr fetch (which is admittedly slow) to complete and eventually throw the compile failure. This is new behavior which has only begun recently. The first svn commit to fail was r142782 dated 2015-11-22 23:34:24 -0800. Subsequent svn commit r142868 also failed. Last successful commit was r142636 dated 2015-11-17 18:36:45 -0800. Builds on my local machine fetch successfully within 2 to 3 minutes in all cases. Log from the latest failed attempt is https://build.macports.org/builders /buildports-yosemite-x86_64/builds/6367/steps/compile/logs/stdio/text which ends abruptly with {{{ CC_PRINT_OPTIONS='YES' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build /_opt_mports_dports_graphics_inkscape-devel/inkscape- devel/work/.CC_PRINT_OPTIONS' CPATH='/opt/local/include' LIBRARY_PATH='/opt/local/lib' MACOSX_DEPLOYMENT_TARGET='10.10' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build /_opt_mports_dports_graphics_inkscape-devel/inkscape-devel/work" && /opt/local/bin/bzr --builtin --no-aliases checkout --lightweight -r 14489 lp:inkscape inkscape-devel-0.91.99.14489' DEBUG: Executing command line: cd "/opt/local/var/macports/build /_opt_mports_dports_graphics_inkscape-devel/inkscape-devel/work" && /opt/local/bin/bzr --builtin --no-aliases checkout --lightweight -r 14489 lp:inkscape inkscape-devel-0.91.99.14489 2>&1 Not checking SSL certificate for xmlrpc.launchpad.net. You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. See "bzr help launchpad- login". }}} as do the others. Initial warnings from bzr are normal and innocuous. I'm wondering if you have access to more detailed network logs that would shed some light on what's happening (or not). Thanks. -- Ticket URL: <https://trac.macports.org/ticket/49812> MacPorts <https://www.macports.org/> Ports system for OS X

1 22

[MacPorts] #49459: routino @3.0 port submission
by MacPorts 15 Oct '16

15 Oct '16

#49459: routino @3.0 port submission ------------------------+-------------------------------- Reporter: framic5@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: routino ------------------------+-------------------------------- I'd like to propose to add routino to MacPorts. It is a route planner for OpenStreetMap data. qlandkartegt, which is also part of MacPorts is not developed anymore and is succeeded by qmapshack, which has routino as dependency. The port can be used as a simple route planner, an example can be found here: http://www.routino.org/documentation/usage.html Tested under OS X 10.11 with Xcode 7.1 Any comment on the Portfile is very much appreciated. -- Ticket URL: <https://trac.macports.org/ticket/49459> MacPorts <https://www.macports.org/> Ports system for OS X

1 10

[MacPorts] #49144: Error: Failed to install snappy
by MacPorts 14 Oct '16

14 Oct '16

#49144: Error: Failed to install snappy --------------------------------+-------------------------------- Reporter: peter.h.m.brooks@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: --------------------------------+-------------------------------- I've repeated errors doing a: port install updated " # port install outdated ---> Computing dependencies for blosc ---> Dependencies to be installed: snappy ---> Fetching distfiles for snappy ---> Verifying checksums for snappy ---> Extracting snappy ---> Configuring snappy ---> Building snappy Error: org.macports.build for port snappy returned: command execution failed Error: Failed to install snappy Please see the log file for port snappy for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_archivers_snappy/snappy/main.log Error: The following dependencies were not installed: snappy To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port blosc failed " Darwin eve.local 15.0.0 Darwin Kernel Version 15.0.0: Wed Aug 26 16:57:32 PDT 2015; root:xnu-3247.1.106~1/RELEASE_X86_64 x86_64 -- Ticket URL: <https://trac.macports.org/ticket/49144> MacPorts <https://www.macports.org/> Ports system for OS X

1 6

[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] #49317: python34 @3.4.3 Allow loading SQLite extensions
by MacPorts 12 Oct '16

12 Oct '16

#49317: python34 @3.4.3 Allow loading SQLite extensions -------------------------+-------------------------------- Reporter: m3drano@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: python34 -------------------------+-------------------------------- This patch adds the flag --enable-loadable-sqlite-extensions to the Python build, which allows to load extensions in SQLite databases natively. There is more information on the subject in the Python's documentation: https://docs.python.org/3.4/library/sqlite3.html#f1 This setting is enabled on other OSes as default too, such as Linux distributions (Debian, Arch) at least. This patch applies to the port python34, but we can certainly extend it to other Python versions too if it is deemed appropriate. Other option would be to make this a port variant. -- Ticket URL: <https://trac.macports.org/ticket/49317> MacPorts <https://www.macports.org/> Ports system for OS X

1 10