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

[MacPorts] #45824: (still) impossible to install numpy on yosemite
by MacPorts 05 May '16

05 May '16

#45824: (still) impossible to install numpy on yosemite --------------------+-------------------------------- Reporter: vm@… | Owner: macports-tickets@… Type: defect | Status: new Priority: High | Milestone: Component: ports | Version: 2.3.2 Keywords: | Port: --------------------+-------------------------------- sudo port install py27-numpy ---> Computing dependencies for py27-numpy ---> Building py27-numpy Error: org.macports.build for port py27-numpy returned: command execution failed Please see the log file for port py27-numpy for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports .org_release_tarballs_ports_python_py-numpy/py27-numpy/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port py27-numpy failed -- Ticket URL: <https://trac.macports.org/ticket/45824> MacPorts <https://www.macports.org/> Ports system for OS X

1 6

[MacPorts] #51299: digikam-4.9.0_0.darwin_15.x86_64.tbz2 fails to build on OSX 10.11.4
by MacPorts 05 May '16

05 May '16

#51299: digikam-4.9.0_0.darwin_15.x86_64.tbz2 fails to build on OSX 10.11.4 -------------------------+-------------------------------- Reporter: terryw345@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: digiKam -------------------------+-------------------------------- After a few dependancy errors which I resolved I started a clean build of digicam ... command line... sudo port install digikam ---> Computing dependencies for digikam ---> Fetching archive for digikam ---> Attempting to fetch digikam-4.9.0_0.darwin_15.x86_64.tbz2 from http://osl.no.packages.macports.org/digikam ---> Attempting to fetch digikam-4.9.0_0.darwin_15.x86_64.tbz2 from https://packages.macports.org/digikam ---> Attempting to fetch digikam-4.9.0_0.darwin_15.x86_64.tbz2 from http://lil.fr.packages.macports.org/digikam ---> Fetching distfiles for digikam ---> Verifying checksums for digikam ---> Extracting digikam ---> Configuring digikam ---> Building digikam Error: org.macports.build for port digikam returned: command execution failed Please see the log file for port digikam for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_kde_digikam/digikam/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port digikam failed -- Ticket URL: <https://trac.macports.org/ticket/51299> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #50703: ffmpeg port modifications to enable splitting off legacy port versions with minimal effort
by MacPorts 04 May '16

04 May '16

#50703: ffmpeg port modifications to enable splitting off legacy port versions with minimal effort -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: has_patch | Port: ffmpeg -------------------------+-------------------------------- As announced elsewhere, I've implemented a proof of concept set of changes to the current (2.8.6) FFMpeg port so that it becomes trivial to support a legacy version installed in parallel to a current version. This would make it possible to keep the main `port:ffmpeg` at the latest/current release even if because of ABI changes certain dependent ports still require an older version. The principle is simple: use FFMpeg's configure options to build the binaries and libraries using an appropriate suffix (tentatively called `compat_version` in my draft) and accompanying options to ensure that items under ${prefix}/include and ${prefix}/share do not cause version conflicts. If the port is not configured in legacy mode, symlinks are used to make the relevant items available where they would be in a simple installation. Legacy mode is currently implemented as an inactive `port:ffmpeg-${compat_version}` subport, which means that dependents can request that compat_version explicitly. Thus: - dependents will find the main ffmpeg port and files as usual - dependents that need to use a legacy version only need to be patched so that they request the suffixed pkgconfig files (ports not using pkgconfig for this will take a bit more work) - currently installed dependents will continue to work thanks to the symlinks to (only) the runtime shared libraries (`libfoo.N.dylib`). This is a personal preference of mine; those symlinks could of course also be omitted in legacy mode too. Note that these modifications can be applied only to the v2.8.6 ffmpeg port; it should be able to co-exist peacefully with a v3.0.0 ffmpeg port built normally. I'd advise building all ffmpeg ports like this in the future though, if the possibility to keep a legacy version around is judged important enough. -- Ticket URL: <https://trac.macports.org/ticket/50703> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

[MacPorts] #51162: Current MacPorts version of Sunwait is out of date
by MacPorts 04 May '16

04 May '16

#51162: Current MacPorts version of Sunwait is out of date ----------------------------+-------------------------------- Reporter: mllists@… | Owner: macports-tickets@… Type: request | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: sunwait update | Port: sunwait ----------------------------+-------------------------------- Is there any chance of MacPorts providing the latest version of sunwait? The version on MacPorts (0.1) is woefully out of date and the original authors web site says he is no longer working on it and has passed responsibility to Ian Craig here;- [https://sourceforge.net/projects/sunwait4windows/ https://sourceforge.net/projects/sunwait4windows/] The latest version of the project (0.8) is much enhanced and considerably more useful than the out of date version on MacPorts. -- Ticket URL: <https://trac.macports.org/ticket/51162> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

[MacPorts] #49906: blitz-devel: mercurial fetch fails on all buildbots
by MacPorts 04 May '16

04 May '16

#49906: blitz-devel: mercurial fetch fails on all buildbots ----------------------------+-------------------------- Reporter: devans@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: server/hosting | Version: Keywords: | Port: blitz-devel ----------------------------+-------------------------- Attempts to build blitz-devel on the buildbots fail during fetch from the mercurial repository. Fetches on my local machine are successful. Mercurial uses port 8000. Is this blocked? See log at https://build.macports.org/builders/buildports-mavericks- x86_64/builds/15083/steps/compile/logs/stdio/text. -- Ticket URL: <https://trac.macports.org/ticket/49906> MacPorts <https://www.macports.org/> Ports system for OS X

1 5

[MacPorts] #51307: libplist fails on El Cap
by MacPorts 04 May '16

04 May '16

#51307: libplist fails on El Cap -------------------------------+-------------------------------- Reporter: bernard.meunier@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: -------------------------------+-------------------------------- Hi, I have an MacBook Pro with 10.11.2 El Capitan. I have made a lot of tests and read a lot of documents, but I amn't enable to install the last two library (libgpod libplist) used by digikam. I have joint two documents. The first give you the procedure I have followed. The second is the content of the log file generated. Can you help me. Thank a lot -- Ticket URL: <https://trac.macports.org/ticket/51307> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #51176: New libtorrent-rasterbar 1.1.0 seems to break current deluge @1.3.12_1+python27
by MacPorts 04 May '16

04 May '16

#51176: New libtorrent-rasterbar 1.1.0 seems to break current deluge @1.3.12_1+python27 ------------------------+---------------------------------- Reporter: beremour@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: deluge | Port: libtorrent-rasterbar ------------------------+---------------------------------- After upgrading to libtorrent-rasterbar @1.1_0+python27 my current torrent app deluge @1.3.12_1+python27 stops downloading or uploading anything. Activating the old one libtorrent-rasterbar @1.0.9_0+python27 brings all back to work. my OS is LION bash-3.2$ uname -a Darwin MACPRO11.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:26:45 PDT 2012; root:xnu-1699.32.7~1/RELEASE_I386 i386 -- Ticket URL: <https://trac.macports.org/ticket/51176> MacPorts <https://www.macports.org/> Ports system for OS X

1 9

[MacPorts] #51199: libextractor: missing dependency on libsmf causes opportunistic configuration
by MacPorts 04 May '16

04 May '16

#51199: libextractor: missing dependency on libsmf causes opportunistic configuration ----------------------+-------------------------- Reporter: devans@… | Owner: ryandesign@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: libextractor ----------------------+-------------------------- While working on libextractor ffmpeg issues earlier today, I noticed that libextractor will configure with libsmf to provide midi support if it is available. Doesn't seem to be an obvious way to disable this during configure so adding a dependency on libsmf is probably the easiest solution. -- Ticket URL: <https://trac.macports.org/ticket/51199> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #50969: Provide a generic extract (and compress) commands in base
by MacPorts 04 May '16

04 May '16

#50969: Provide a generic extract (and compress) commands in base -------------------------+---------------------- Reporter: mojca@… | Owner: raimue@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 2.3.4 Keywords: | Port: -------------------------+---------------------- It would be extremely useful to introduce a command like {{{ file_extract foo.tar.xz }}} in the core, so that ports could even "manually" extract (or compress) additional files when needed. At the moment MacPorts supports fetching distfiles from different mirrors, but it doesn't support extracting different filetypes, so all the "hard work" of extracting the proper file has to be repeated manually in the Portfile. It might also be useful to be able to extract additional tarballs when fetching from git/svn, so the command would be helpful in many different context. MacPorts could also have the ability to automatically use different extract methods based on filenames (that is: when file extension is specified; `use_xz` would then only influence the default type that could theoretically be overwritten). (The other nice-to-have functionality would be the ability to create (reproducible) tarballs on demand. But maybe that's for another ticket.) -- Ticket URL: <https://trac.macports.org/ticket/50969> MacPorts <https://www.macports.org/> Ports system for OS X

1 9

[MacPorts] #51303: netcdf: Request: Add static library libnetcdf.a to build
by MacPorts 04 May '16

04 May '16

#51303: netcdf: Request: Add static library libnetcdf.a to build ----------------------------+-------------------------------- Reporter: andy.nowacki@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: netcdf ----------------------------+-------------------------------- The majority of library ports that I have installed, but admittedly not all, seem to build and install both a static and dynamic version of the library. This is based on: {{{ $ ls /opt/local/lib/lib*.{a,dylib} | awk -F. '!/lib.*\..*\.dylib/ {lib[$1]++} END {for (l in lib) if (lib[l] > 1) { print l, "yes"; n++ } else { print l, "no"; m++ } print "\n"n, "of", n+m, "have static libraries"}' }}} Quite a few codes that I use, one example being SEATREE (http://geosys.usc.edu/projects/seatree/wiki/) seem to want to enforce static linking (presumably for executable portability or 'performance'), and so will not use a dynamic library. Would it be possible for the NetCDF port to create a static library? I apologise for not offering a patch for this, but my brain is not big enough to deal with CMake. I understand this is probably low priority, but I for one would find building a static library very useful, and it hopefully would be fairly trivial. I note that the `netcdf-fortran` port ''does'' build the static library, as does `hdf5`, which prompted me to believe the suggestion might be feasible. Please let me know if I can help in any way. -- Ticket URL: <https://trac.macports.org/ticket/51303> MacPorts <https://www.macports.org/> Ports system for OS X

1 3