We accept SHLIB version changes when moving to USE=libtool, so stop
overriding it with the intent of prevent library version changes, which
is considered the better approach over the long term. Two ports are
dependent on mpqc, so bump them for the second time today.
requested by: tijl@
science/ghemical would not link because libghemical.so (from science/
libghemical port) had never been properly linked. Links to all mpqc "SC"
libraries were added to LDFLAGS to rectify this. The configure breakage
and solution is described below.
After the version of lang/gcc was bumped from 4.7 to 4.8,
science/libghemical ceased to configure and it was marked broken. After
recreating the conftest, it was discovered that two versions incompatible
versions of libgcc_s.so were getting pulled in by the realtime linker:
the base version and the gcc48 ports version.
The base version was getting pulled in by science/libint. To unbreak
libghemical, libint is now built with lang/gcc. It was necessary to
force libtool to link with LDFLAGS that Mk/bsd.gcc.mk sets so that
the runpaths match across libraries used by libghemical.
When science/mpqc was staged, it utilized libtool which renumbered all
the library versions from 8.0.1 to 7.1.0. This was caused by the age
component being greater than 0. By patching configure.in with a new
version, we can generate major SHLIB of 8 again. While here, fix the
bin/sc-config tool to remove a bad include cflag.
With this fixes, science/ghemical builds successfully. Bump all 4 of
these ports, remove any BROKEN designation and remove redundant
@dirrm in pkg-plist
Note: this is not the latest. Now there is no separate release for ncs
and the sources are distributed as code_saturne-x.y.z. Next upgrades in
preparation!
checking for main in -llapack... yes
checking for sc-config... /usr/local/bin/sc-config
checking SC - version... no
*** Could not run SC test program, checking why...
*** The test program compiled, but did not run. This usually means
*** that the run-time linker is not finding SC or finding the wrong
*** version of SC.
Reported by: pkg-fallout
- Update WWW
While here:
- Update LICENSE
- Convert non-functional (since February) USE_FORTRAN to USES=fortran
- Convert USE_PYTHON to USES=python:2 (3.x doesn't seem to work)
- Further convert to options helpers
- FORTRAN and QT4 options seem to build fine together, so make
them non-exclusive regular options
PR: 193590
Submitted by: pfg
PySAL is a cross-platform library of spatial analysis functions written in
Python. It is intended to support the development of high level applications for
spatial analysis.
WWW: https://pypi.python.org/pypi/PySAL
WWW: http://pysal.org/
- Remove LATEST_LINK and the usage of math/py-numpy's options - both do not
seem to have any value for the port
PR: 192893
Submitted by: myself
Approved by: wen@ (maintainer)
The 3.0 series is an incremental improvement over the previous 2.8 series
despite the major version number change. A list of important changes is
available at http://www.cmake.org/cmake/help/v3.0/release/3.0.0.html
On the porting side
* The minimum FreeBSD release we have to support in the ports tree is now
recent enough that ports/168671 can finally be committed: instead of
building and using CMake's own copies of bzip2, curl, expat, libarchive,
liblzma and zlib, we use the versions in ports and/or the base system.
* CMake's documentation system has been changed and vastly improved at the
cost of now depending on Sphinx. We still generate only man pages, but can
start generating the HTML documentation in the future if desired.
* devel/cmake-gui now uses Qt5 instead of Qt4 and does not needlessly build
the ncurses UI that is installed by devel/cmake itself.
* CMake commit 3816cd2 fixes a longstanding issue in the detection of the
Python interpreter and its libraries, but requires us to revert a
workaround for that in Mk/Uses/python.mk itself, effectively reverting
the patch introduced by ports/168159.
* Similarly, a few ports had to be fixed manually due to CMake being
stricter when parsing some files or the ports detecting Python the wrong
way. Fortunately, they all had been fixed upstream so I just grabbed the
appropriate commits and pointed to them in the patches.
science/gnudatalanguage had to have its PORTREVISION bumped because
switching to USES=cmake:outsource removed a few files from the plist that
were not supposed to have been installed in the first place.
PR: 168671
PR: 192644
I clobbered the Makefile diff (sorry danfe@). The entire makefile was
tabbed over 3 times. There was also no respect for 80 columns so a good
part of the clobber came from line wrapping. I also made $TAR use
real switches (e.g. -xzf) rather than undocumented by supported (zxf)
This is another manual package / obtain restricted data files/ only port
so I can't test much of it.
PR: 193090
Submitted by: turutani (Kyoto)
The ECMWF GRIB API is an application program interface accessible from C,
FORTRAN and Python programs developed for encoding and decoding WMO FM-92 GRIB
edition 1 and edition 2 messages. A useful set of command line tools is also
provided to give quick access to GRIB messages.
WWW: https://software.ecmwf.int/wiki/display/GRIB/Home
- Mk/bsd.database.mk rewrite, new default to db5.
- db6 is eligible by default only if installed on the system.
- Bump PORTREVISION of all ports that directly depend on BerkeleyDB or
where USE_BDB is found in the port's directory
- Patch a few ports such that they will pick up or work with newer
versions.
- Add UPDATING entry
- Drive-by format fix for pks
- Drop BerkeleyDB option from mail/popular for now, requires more work.
- Exp-run logs linked from the PR below.
- Ports that do not build (IGNORE, BROKEN, etc.) have pro-forma changes
for new Berkeley DB, but are untested.
NOTE: please read UPDATING and the Wiki page before proceeding!
Announcement: http://lists.freebsd.org/pipermail/freebsd-ports-announce/2014-August/000090.html
Wiki reference: https://wiki.freebsd.org/Ports/BerkeleyDBCleanup
PR: 192690
Approved by: portmgr (implicit, PORTREVISION bump on unstaged ports)
rubyforge.org shutdown on May 15, 2014. This commit accounts for that by doing
several things:
- Deprecate ruby that had only rubyforge.org as MASTER_SITES (and so are now
only fetchable via our cache)
- Deprecate ports that depend on those
- Update the WWW pkg-descr line that points to rubyforge.org for rubygem ports
(which are still fetchable from rubygems.org)
The next step will be to remove rubyforge.org from bsd.sites.mk, after these
deprecated ports are deleted.
Phabric: D591
With hat: ruby
Approved by: portmgr (because of committing to unstaged graphics/mingplot port)
GCC 4.2 in FreeBSD 8.X/9.X base is now too old to compile OpenEXR, so
GCC-based systems will upgrade to the default ports compiler (GCC 4.7
currently.)
Add two patches to OpenEXR to permit building it in a live system with
the older OpenEXR version installed. Bug report filed to upstream Github
at https://github.com/openexr/openexr/issues/130
Couple OpenEXR more tightly to ilmbase and require its exact .so
version.
Add UPDATING note, and bump PORTREVISION of all dependent ports.
Proto-STAGE hugin-devel, and mark it IGNORE because hugin is newer.
Approved by: portmgr (implicit for bumping PORTREVISION on unstaged ports)
