as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
to GCC 9.1 under most circumstances now after revision 507371.
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, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.
PR: 238330
* Bump PORTREVISION of ports depending on them.
Also while I'm here:
* Add "gnome" to USES if the XML option is enabled to avoid warnings about
using USE_GNOME alone.
* Pet portlint
Notable changes since 2.5.16 (graphics/libgphoto2) [1]:
* Added new USB Ids for various camera types
* Updated translations
* Report file changes via GP_EVENT_FILE_CHANGED (hooked up for Canon EOS
currently)
Changes since 2.5.15 (graphics/gphoto2) [2]:
* Maximum number in file ranges bumped from 16384 to 65536
* Add shell commands to match commandline: summary, storage-info,
trigger-capture
* Fixed a fd leak
* Updated translations
* Handle GP_EVENT_FILE_CHANGED event
https://github.com/gphoto/libgphoto2/blob/libgphoto2-2_5_22-release/NEWShttps://github.com/gphoto/gphoto2/blob/gphoto2-2_5_20-release/NEWS
PR: 235817 [1], 235818 [2]
Submitted by: Darren Mulligan <fixer@bsdmail.com>
Approved by: woodsb02 (maintainer timeout)
- Expire after the last version without /usr/lib/libomp.so
- Drop SOVERSION for seamless transition (i.e., avoid conditionals)
PR: 236907
Approved by: bapt (maintainer)
Differential Revision: https://reviews.freebsd.org/D19767
Changelog:
http://www.exiv2.org/changelog.html
- All depending ports have been bumped.
- graphics/py-exiv2 has been marked broken; use graphics/gexiv2 for python bindings
Exp-run by: antoine
PR: 235943
PR: 234830
Release notes:
* https://www.darktable.org/2018/12/darktable-260-released/
The initial patch was provided by Darren Mulligan. On top of it:
* Warnings about USES=gl and USES=gnome were fixed.
* The CMake CMAKE_POLICY_DEFAULT_CMP0056 setting was removed.
PR: 234800
Submitted by: Darren Mulligan <fixer@bsdmail.com>
Reported by: kunda <chitty_cloud@me.com>
Ports that build out of source now simply can use "USES=cmake"
instead of "USES=cmake:outsource". Ports that fail to build
out of source now need to specify "USES=cmake:insource".
I tried to only set insource where explictely needed.
PR: 232038
Exp-run by: antoine
defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 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, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
Release notes: <https://github.com/openexr/openexr/releases/tag/v2.3.0>
Adjust LIB_DEPENDS of all ports that require ilmbase or openexr to chase
the new lower-case spelling of the name, and to omit the version from the
library name to ease future maintenance.
Bump PORTREVISION of all ports that depend on ilmbase or openexr directly,
so that they all get rebuilt on upgrades.
Add patches to graphics/ampasCTL to keep it alive, with (a) ilmbase now
that its Iex::BaseExc class is no longer derived from std::string,
details were given upstream through https://github.com/ampas/CTL/issues/71
and (b) to unwind semicolon/;-lists in cmake that stem from openexr/
ilmbase pkg-config variables.
(Note ampasCTL is unmaintained as FreeBSD port, and upstream,
and I cannot run-time test it.)
Poudriere build tests on 11.2-RELEASE-p1 amd64 of ALL ports depending
directly or indirectly on ilmbase and/or openexr have passed without
regressions. Thus invoking due diligence, I believe I have done the
equivalent of an -exp run, and do not require approval for the dependency
chases to third-party ports.
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
... instead of LLVM 5.0. The reason is to stay in sync with Mesa to keep
the number of LLVM copies to build to the minimum.
It looks like the hack to explicitely set `LDFLAGS` to have OpenMP
support isn't necessary anymore. The last time it was revisited was with
LLVM 3.9.1.
The `CheckZlib.cmake` module uses `NULL` in the test source code to
check for the `zError()` symbol. This fails to build on FreeBSD 10.3
with the following error:
CheckPrototypeDefinition.c:15:10: error: use of undeclared identifier 'NULL'
return NULL;
^
I don't know the root cause for this failure, but including `stddef.h`
in this test source code fixes the problem.
PR: 225501
Reported by: cpm@
graphics/gphoto2: Update to 2.5.15
graphics/py-gphoto2: Update to 1.8.2
Also bump PORTREVISION of ports depending on these.
PR: 224611
Submitted by: bsam (graphics/libgphoto2)
While here, fix libIlmImfUtil_la_LDFLAGp so that when linking libIlmImfUtil,
the locally built libIlmImf gets precedence over the one in /usr/local,
to permit upgrades in a running system with the older version installed.
This changes the library's SONAME, so bump PORTREVISION of all dependees.
Unfortunately, this looks a bit too intrusive for an MFH to 2017Q4.
Security: CVE-2017-9110
Security: CVE-2017-9111
Security: CVE-2017-9112
Security: CVE-2017-9113
Security: CVE-2017-9114
Security: CVE-2017-9115
Security: CVE-2017-9116
Security: 803879e9-4195-11e7-9b08-080027ef73ec
(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
Using ninja instead of make (1) can lead to significant speed ups while building.
Therefore switch from having the ninja generator opt-in to having it opt-out.
Previously cmake-ports that wanted to use ninja could set
CMAKE_NINJA=yes
now, ports that do not work with ninja can set
cmake:<existing args>,noninja
Note, that needing this should be an exception and most often points to a broken
cmake of the port.
The ports using cmake were modified
* removed USES=gmake, if ninja is used
* removed MAKE_ARGS, if ninja is used
* added the cmake-argument noninja if necessary
PR: 219629
PR: 213331
Exp-run by: antoine
Reviewed by: rakuco
Differential Revision: https://reviews.freebsd.org/D10748
We try to keep the same LLVM version as Mesa to avoid the need to have
several versions of LLVM.
Approved by: bapt (mentor)
Differential Revision: https://reviews.freebsd.org/D10403
lang/gcc which have moved from GCC 4.9.4 to GCC 5.4 (at least under some
circumstances such as versions of FreeBSD or platforms).
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using using Mk/bsd.octave.mk which in turn has USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c++11-lib, c++14-lang,
c++11-lang, c++0x, c11, or gcc-c++11-lib.
PR: 216707
Version 2.2.3 was released shortly after 2.2.2 with the patch to
src/develop/imageop_math.c applied.
Approved by: bapt (mentor)
Differential Revision: https://reviews.freebsd.org/D9400
Use devel/openmp to provide OpenMP runtime instead of the entire LLVM
(submitted by mandree@). This allows to use LLVM 3.9 at build time,
without fearing any dependency to multiple LLVM versions at runtime
(Mesa pulls LLVM 3.7 for instance).
Change `COMPILER_TYPE` to `CHOSEN_COMPILER_TYPE`, (submitted by
mandree@). This was blocking bug 199098.
Include the following patch from upstream, which fixes a regression
(suggested by upstream):
f7bc2b3338.patch
PR: 216561
Submitted by: mandree (CHOSEN_COMPILER_TYPE and devel/openmp dep.)
Approved by: bapt (mentor)
Differential Revision: https://reviews.freebsd.org/D9363
ChangeLogs since previous 2.0.7:
https://www.darktable.org/2016/12/darktable-2-2-0-released/https://www.darktable.org/2017/01/darktable-2-2-1-released/
- Permit build on ARM64 (previously: AMD64 only)
- Squish is no longer a build requisite, but po4a is for localized
documentation.
- USE_GEO -> USE_MAP in the cmake context
- SLIDESHOW and GNOMEKEYRING options are gone upstream
- Move to OpenJPEG 2.1 (used to use 1.5), needs a patch to the
CMakeLists.txt to resolve include path shadows if both releases are
installed.
- Remove support for FreeBSD 9.3.
Post-review-change: Take BUILD_DEPENDS on textproc/po4a and extend
pkg-plist by several translated manual pages.
PR: 215687 (related) [1]
Submitted by: Greg V [1], mandree@ (most)
Reviewed by: Roman Lebedev, dumbbell@
Approved by: dumbbell@
Differential Revision: https://reviews.freebsd.org/D8994
Add several missing dependencies, as reported by `make stage-qa`.
Clean up port options:
o `COLORD` and `OPENEXR` had an incomplete an dependencies list.
o `NLS` was broken when turned off.
o `RAWSPEED` and `SQUISH` were not CMake knobs anymore in darktable.
Approved by: mat
Differential Revision: https://reviews.freebsd.org/D7147
As there is an shlib version bump, bump them portrevision of dependent ports.
While doing so, also switch to the cmake build system, as it requires less
patching and is easier to handle.
PR: 211329
Reviewed by: mat, rakuco, kwm
Approved by: rakuco (mentor)
Differential Revision: https://reviews.freebsd.org/D7283
This update also fixes the build on FreeBSD 9.3-RELEASE where the
definition of powl(3) is hidden behind _DECLARE_C99_LDBL_MATH.
Reviewed by: kwm
Approved by: kwm
Differential Revision: https://reviews.freebsd.org/D5279
