took a look into upstream's Gopkg.lock, checking for modifications;
changed 2 depencies to use version instead of revision;
google:go-cmp and golang:text
get QA done right; thanks to portlint;
moved PLIST_FILES to appear after USES.
Approved by: araujo (mentor), rene (mentor)
Differential Revision: https://reviews.freebsd.org/D17530
in the ports tree (via Mk/bsd.default-versions.mk and lang/gcc) which
has now moved from GCC 6 to GCC 7 by default.
This includes ports
- featuring USE_GCC=yes or USE_GCC=any,
- featuring USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and those
- with USES=compiler specifying one of openmp, nestedfct, c11, c++0x,
c++11-lib, c++11-lang, c++14-lang, c++17-lang, or gcc-c++11-lib.
PR: 222542
This module attempts to implement reasonably robust benchmarking with little
extra effort and expertise required from the user. That is to say, benchmarking
using this module is likely an improvement over
time some-command --to --benchmark
or
use Benchmark qw/timethis/;
timethis(1000, 'system("some-command", ...)');
The module currently works similar to the former command line, except (in layman
terms) it will run the command many times, estimate the uncertainty of the
result and keep iterating until a certain user-defined precision has been
reached. Then, it calculates the resulting uncertainty and goes through some
pain to discard bad runs and subtract overhead from the timings. The reported
timing includes an uncertainty, so that multiple benchmarks can more easily be
compared.
Please note that Dumbbench works entirely with wallclock time as reported by
Time::HiRes' time() function.
WWW: https://metacpan.org/release/Dumbbench
While I'm upgrading, I fix the atomic 64 bit detection on clang6
The current solution is to for the noinline attribute to the
atomic detection code
PR: 229885
Based on the timeout of 3+ months (2018-03-23-now) on bug#226885 for net/ucarp
Also, looking at the subversion log, there were timeouts on:
* bug#224169 r465659 | ygy | 2018-03-26 19:51:12
* bug#224768 r459066 | swills | 2018-01-15 07:16:28
* bug#224755 r459058 | swills | 2018-01-15 06:55:08
The last approval from alexey@renatasystems.org was over a year ago:
bug#218563 r438885 | lifanov | 2017-04-19 08:30:28 (devel/py-colorama)
While there, cleanup, and sort depends.
When build and run dependencies are the same, there are three ways to
avoid duplicating the list while not adding the framework added
BUILD_DEPENDS to the RUN_DEPENDS. In order of preference, they are:
1) use RUN_DEPENDS to set BUILD_DEPENDS:
BUILD_DEPENDS= ${RUN_DEPENDS}
RUN_DEPENDS= foo:bar/baz
2) create another variable and use it:
MY_DEPENDS= foo:bar/baz
BUILD_DEPENDS= ${MY_DEPENDS}
RUN_DEPENDS= ${MY_DEPENDS}
3) use BUILD_DEPENDS to set RUN_DEPENDS and force evaluation:
BUILD_DEPENDS= foo:bar/baz
RUN_DEPENDS:= ${BUILD_DEPENDS}
Sponsored by: Absolight
This a security release for libwww to take into account security advisories
CVE-2016-9063 and CVE-2017-9233.
In order to take into account current and future expat security advisories,
the expat source code was removed from the libwww tree. The makefiles were
modified so that libwww dynamically links against the system's expat library.
Patches removed were incorporated upstream.
Bump PORTREVISION of dependent ports due shlib change.
Changes: https://raw.githubusercontent.com/w3c/libwww/5.4.2/ChangeLog
MFH: 2018Q3
Security: e375ff3f-7fec-11e8-8088-28d244aee256
- Fetch the distfile from the upstream GitHub instead of my mirror
- Project was relicensed under Apache License 2
- Fix shebang in the wrapper script and call ${JAVA} via ``exec'' so
it replaces sh(1) process (makes it look nicer in the ps(1) output)
- Fix an apparent typo in the port description text
most cases, the failure mode is the same. Also, mark them broken on
mips when necessary.
While here, pet portlint.
Approved by: portmgr (tier-2 blanket)
As usual, it is recommended to rebuild or reinstall all the
dependent ports and the lang/ghc port itself in one of the following
ways:
# portmaster -w -r ghc
or
# portupgrade -fr lang/ghc
In case of pkg(8), it is probably safer to remove all the GHC-dependent
packages along with GHC and reinstall everything from scratch. For
example:
# pkg query "%ro" ghc > ghc-pkgs.txt
# pkg delete -y lang/ghc
In ghc-pkgs.txt, check and remove all the packages that have been moved
on the update, then use this command:
# pkg install -y `cat ghc-pkgs.txt`
Approved by: tcberner (mentor)
Differential Revision: https://reviews.freebsd.org/D16038
