Upstream release notes:
* A patch release that corrects the SO version for the v2.5 release,
which missed getting bumped in v2.5.0.
* This release also fixes an improper failure in IlmImfTest
when running on ARMv7 and AAarch64.
Bump PORTREVISION of all port directly requiring ilmbase or openexr
that are not marked BROKEN (shlib/.so file version bump).
Test build of all port directly depending on ilmbase or openexr
succeeded in poudriere in a 12.1-RELEASE amd64 jail.
ChangeLog:
- https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v2.5.0
* Bump PORTREVISION of all consumers except py-openimageio (BROKEN).
* cad/PrusaSlicer:
LIB_DEPENDS: remove version from libHalf.so
BUILD_DEPENDS+=qt5-buildtools as package (needed on bare metal builds)
USE_GL+=gl
USES+=pkgconfig (needed to find libHalf)
Change if to explicit ifdef to prevent:
/wrkdirs/usr/ports/graphics/openimageio/work/oiio-Release-2.0.10/src/libutil/ustring.cpp:328:27: error: expected value in expression
# if _LIBCPP_BIG_ENDIAN
PR: 242134
Approved by: FreeBSD@ShaneWare.Biz (maintainer timeout)
graphics/gstreamer1-plugins-openexr: switch from C++98 to C++11 to
match new OpenEXR headers and unbreak compilation.
Bump PORTREVISION of all ports depending directly on either, based
on assessing INDEX-12 (bump_portrevision.pl -l (shallow) used).
Release Notes:
https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v2.4.0
The update was deliberately deferred until after 2020Q1, and should
not be MFH'd back to it.
- Depend on x11-fonts/droid-fonts-ttf instead of installing own copies:
Droid fonts shipped with openimageio don't have Cyrillic symbols.
For some reason LibreOffice picks up Droid fonts from openimageio
and this breaks LibreOffice UI for non-Latin locales.
PR: 240963
Approved by: maintainer
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
- Demosaic packs are no longer distributed nor supported upstream
- Bump PORTREVISON on all consumers due to libraw shlib version increase
Changes: https://www.libraw.org/news/libraw-0-19-2-release
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
While here, chase some KDE4 ports and functionality, these are scheduled for
removal on 2018-12-31. Change the default option/flavor to QT5 where applicable
or use alternative toolkits like GTK.
Submitted by: tcberner
Reviewed by: adridg, jhale, rene, tcberner
Approved by: portmgr (implicit, flavor hook)
Differential Revision: https://reviews.freebsd.org/D17741
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
From now on, ports that depend on Qt4 will have to set
USES= qt:4
USE_QT= foo bar
ports depending on Qt5 will use
USES= qt:5
USE_QT= foo bar
PR: 229225
Exp-run by: antoine
Reviewed by: mat
Approved by: portmgr (antoine)
Differential Revision: →https://reviews.freebsd.org/D15540
-- Boost python support not found -- will not build python components!
[...]
install -s -m 0644 /wrkdirs/usr/ports/graphics/py-openimageio/work/.build/src/python/OpenImageIO.so /wrkdirs/usr/ports/graphics/py-openimageio/work/stage/usr/local/lib/python2.7/site-packages
install: /wrkdirs/usr/ports/graphics/py-openimageio/work/.build/src/python/OpenImageIO.so: No such file or directory
PR: 227427
Reported by: antoine (via exp-run)
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
