trainer.cpp:106:18: error: no matching function for call to 'make_pair'
x_.push_back(std::make_pair<std::string, FeatureNode *>(y, fn));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PR: 224669
Reported by: pkg-fallout
We were not setting the flag to select the GNUstep ABI, so were defaulting to
using the GCC-compatible version, which was likely to trigger a lot of subtle
bugs. This was noticed when C++ exceptions thrown through Objective-C stack
frames caused segfaults.
Ports using USE_PYTHON=distutils are now flavored. They will
automatically get flavors (py27, py34, py35, py36) depending on what
versions they support.
There is also a USE_PYTHON=flavors for ports that do not use distutils
but need FLAVORS to be set. A USE_PYTHON=noflavors can be set if
using distutils but flavors are not wanted.
A new USE_PYTHON=optsuffix that will add PYTHON_PKGNAMESUFFIX has been
added to cope with Python ports that did not have the Python
PKGNAMEPREFIX but are flavored.
USES=python now also exports a PY_FLAVOR variable that contains the
current python flavor. It can be used in dependency lines when the
port itself is not python flavored. For example, deskutils/calibre.
By default, all the flavors are generated. To only generate flavors
for the versions in PYTHON2_DEFAULT and PYTHON3_DEFAULT, define
BUILD_DEFAULT_PYTHON_FLAVORS in your make.conf.
In all the ports with Python dependencies, the *_DEPENDS entries MUST
end with the flavor so that the framework knows which to build/use.
This is done by appending '@${PY_FLAVOR}' after the origin (or
@${FLAVOR} if in a Python module with Python flavors, as the content
will be the same). For example:
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}six>0:devel/py-six@${PY_FLAVOR}
PR: 223071
Reviewed by: portmgr, python
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D12464
armv7, mark them so.
This is part two of a multipart commit to bring armv7 ports to parity
with armv6.
Approved by: portmgr (tier-2 blanket)
Obtained from: lonesome.com -exp run
- port is marked BROKEN since april or so
- port is a browser for 2ch.net
- 2ch.net changed their API, so even if fixed, it would no longer work
PR: 218650
Submitted by: townwear@gmail.com (maintainer)
I chose filelight-17.* as it contains its own localization,
which is good, as kde4-l10n is very outdated, and may not
match modern filelight anymore.
Unfortunately this lead to conflicts with the kde4-l10n.
So strip the filelight parts from kde4-l10n-*.
Reported by: VVD (via IRC)
Reviewed by: rakuco
Pointyhat to: tcberner
Differential Revision: https://reviews.freebsd.org/D12393
(via Mk/bsd.default-versions.mk and lang/gcc) which has moved from
GCC 5.4 to GCC 6.4 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c++11-lib, c++11-lang,
c++14-lang, c++0x, c11, or gcc-c++11-lib.
PR: 219275
Update the default Objective-C compiler.
Fix various build failures in GNUstep ports from newer versions of the GNUstep
core libraries and from changes to GNUstep Make.
Update various ports that use GNUstep and bump the portrevision of the ones
that haven't had a new release.
