Unfortunately, this was missed with the ilmbase update, and
causes yet another PORTREVISION bump on all dependent ports.
repeating ilmbase's commit log here:
"Patch release with various bug/sanitizer/security fixes, primarily related to
reading corrupted input files."
<https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v2.5.4>
Cherry-pick upstream commit for GCC 11 compatibility:
<a40a6151c4>
Since this changes the patchlevel of the solibs, bump PORTREVISION of dependent
ports just to be sure.
(graphics/py-openshadinglanguage is unaltered and .includes the revision bump
from .../openshadinglanguage.)
MFH: 2021Q1 (this requires discussion by ports-secteam@!)
Reported by: VVD (IRC, #bsdports)
"Patch release with various bug/sanitizer/security fixes, primarily related to
reading corrupted input files."
<https://github.com/AcademySoftwareFoundation/openexr/releases/tag/v2.5.4>
Cherry-pick upstream commit for GCC 11 compatibility:
<a40a6151c4>
Since this changes the patchlevel of the solibs, bump PORTREVISION of dependent
ports just to be sure.
(graphics/py-openshadinglanguage is unaltered and .includes the revision bump
from .../openshadinglanguage.)
MFH: 2021Q1 (this requires discussion by ports-secteam@!)
powerpc64le needs already committed patch for opencl, aarch64 is untested because:
[00:00:12] Finished lang/rust | rust-1.47.0: Ignored: fails to build with qemu-user-static
It may need another fix.
- switch to the more modern version of librsvg2 on architectures
supporting rust
- this will fix some graphical issues on these architectures
PR: 250276
Exp-run by: antoine
Submitted by: tobik
Differential Revision: https://reviews.freebsd.org/D18878
Reason is that graphics/darktable itself had a commit by dumbbell@
(r544820) that also bumped PORTREVISION=2 but that happened before
I'd committed the OpenEXR updates, and the svn update just merged
that change.
So, unfortunately, we need another PORTREVISION update.
See r544849, r544853.
Else the cmake setup will not install the extract_wb_from_images.sh
script, leading to inconsistent installs or packaging failures.
Reported by: poudriere
Approved by: portmgr@ (blanket approval to add missing requisites)
This fixes the build after the latest Perl update to 5.32:
FAILED: doc/man/es/darktable-cltest.pod
cd /wrkdirs/usr/ports/graphics/darktable/work/darktable-3.0.2/doc/man && /usr/local/bin/po4a-translate -f pod -m darktable-cltest.pod -p po/es.po -l /wrkdirs/usr/ports/graphics/darktable/work/.build/doc/man/es/darktable-cltest.pod -k 0
Unknown format type: pod.
List of valid formats:
- asciidoc: AsciiDoc format.
- dia: uncompressed Dia diagrams.
- docbook: DocBook XML.
- guide: Gentoo Linux's XML documentation format.
- ini: INI format.
- kernelhelp: Help messages of each kernel compilation option.
- latex: LaTeX format.
- man: Good old manual page format.
- pod: Perl Online Documentation format.
- sgml: either DebianDoc or DocBook DTD.
- texinfo: The info page format.
- tex: generic TeX documents (see also latex).
- text: simple text document.
- wml: WML documents.
- xhtml: XHTML documents.
- xml: generic XML documents (see also docbook).
ninja: build stopped: subcommand failed.
===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1
PR: 248541
Submitted by: m.ne@gmx.net
Reported by: Robert Cina <transitive@gmail.com>
OpenEXR and ILMBASE updates to 2.5.2 rename the full shlib version
names from .0.0 to .0.1 => to be on the safe side, bump PORTREVISIONs.
Approved by: portmgr (blanket)
MFH: 2020Q3 (PORTREVISION bump after OpenEXR/ilmbase update)
Security: 714e6c35-c75b-11ea-aa29-d74973d1f9f3
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.
This patch is to fix this problem:
| CMake Error at data/kernels/CMakeLists.txt:34 (foreach):
| Unknown argument:
| /usr/ports/graphics/darktable/work/darktable-3.0.0/data/kernels/atrous.cl
Approved by: portmgr@ (blanket approval to fix broken builds)
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)
Announcement:
<https://www.darktable.org/2019/12/darktable-300-released/>
<https://www.darktable.org/2019/12/darktable-30/>
Additional changes:
- ONLY_FOR_ARCHS* variables moved up to please portlint
- some CMAKE_ARGS hacks with CMAKE_*_COMPILER_LAUNCHER to get ccache back in
- switch from hardcoding LLVM_VER=60 to ${LLVM_DEFAULT}
- strip out -D_XOPEN_SOURCE=... (upstream CMakeLists.txt) because it is harmful
in hiding, for instance, u_char typedefs, which causes compilation failure
down the road for cups_print.
PR: 242943
Approved by: dumbbell@ (maintainer)
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.
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
