Greetings, following up on myself, I have:
* ... included item #4 below and have uploaded a full patch against the ports tree as of SVN r479880 here for your perusal, with MOVED and UPDATING info and all intended updates to _DEPENDS. - https://people.freebsd.org/~mandree/openexr-v2.patch - https://people.freebsd.org/~mandree/openexr-v2.patch.asc (GnuPG sign.) * ... test compiled on 11.2-RELEASE amd64 all direct dependencies of openexr or ilmbase, with PORTREVISION bumps, and things look sane, so I will forego (avoid) the -exp run. (This is in response to Mathieu mat@'s request.) There is one casualty, the unmaintained graphics/ampasCTL port. There is no port that requires ampasCTL. The upstream site https://github.com/ampas/CTL has apparently not seen code updates in c. 5 years. Getting the port to go anywhere with modern OpenEXR and pkg-config required some cmake hacking (included in the patch above) to unroll semicolon/;-lists in cmake, but there are further C++ incompatibilities in EXR data types. The patch above therefore marks ampasCTL as BROKEN, and we should probably also mark it for expiration and perhaps graphics/ampasACES-container, too. ## portmgr ## I figured that mail systems were getting in my way on the MAINTAINER= addresses in some places with "you are not subscribed" or "too many recipients" on kde@, or thereabouts, we can't have MAINTAINER= addresses break mass communication like that, for sweeping updates that's an obstacle. I seek portmgr@ approval until Sept 21st for substitute approval in advance in case group (kde@ gnome@ multimedia@...) maintainers are unreached or do not respond in due time. The update to the respective ports _DEPENDS lines is +++ REQUIRED +++ to keep ilmbase or openexr dependees building. I intend to commit in the European afternoon hours of Sept 23rd (probably somewhen between 11:00 and 16:00 h UTC). The proposed schedule leaves us one week before 2018Q4 to sort out unforeseen fall-out, or worst case, a roll-back until after the branch point. Best regards Matthias I wrote on 2018-09-09: > Greetings fellow porters, > > Each of you maintain one or more ports that directly depends on ilmbase > and/or OpenEXR, which are high-profile ports. > There are c. four dozen ports that depend directly on ilmbase and/or > OpenEXR, with indirect dependencies the entire list amounts to ~500 > affected ports. > > I intend to update the graphics/ilmbase and graphics/OpenEXR port to > v2.3.0, which brings shared library version bumps, and you may have to > update your ports' *_DEPENDS lines to chase the ilmbase/OpenEXR version > bumps accordingly. > Spot checks of the new ports with gegl, gegl3, darktable did not show > compile-time issues if the *_DEPENDS is updated and the port recompiled. > > I want to coordinate the update with you so your ports do not break, but > I do NOT intend to keep multiple versions of ilmbase/OpenEXR around. > > I need your input regarding the OpenEXR port upgrade on these items: > > 1. do we need an -exp run? If yes, please state your reason - a weak > but halfway plausible reason will suffice so that I request the -exp > run. > 2. do you need to handle a potential *_DEPENDENCIES update yourself > because you keep a master repository outside FreeBSD? If yes, which > ports and maintainer aliases are affected? > 3. if you are knowledgable about OpenEXR internals, should we flip the > switch for "large stack optimizations"; > or else: do you have an URL that you can point me to that assesses > stack size considerations under FreeBSD, for applications? > 4. can we take this opportunity to rename the OpenEXR port to openexr, > so it matches its distribution name? This would simplify the OpenEXR > port quite a bit, which works around the OpenEXR/openexr name > dichotomy. The distribution calls itself openexr these days and is > hosted on GitHub. > 5. any other comments? > > If I do NOT hear from anyone within 14 days, I will bump the shared > library name in each of your ports' *_DEPENDS and bump PORTREVISION. > > The proposed port update contains two ports under ${PORTSDIR}/graphics/ > and has been uploaded to: > > * https://people.freebsd.org/~mandree/OpenEXR-ilmbase.shar > * https://people.freebsd.org/~mandree/OpenEXR-ilmbase.shar.asc <- this > is the detached GnuPG signature for the shar above > > Further links: > > * OpenEXR web site <http://www.openexr.com/> > * openexr project on GitHub <https://github.com/openexr/openexr> > > This is the list of maintained ports that have a direct dependency on > ilmbase and/or OpenEXR, with OpenEXR elided for obvious reasons. > > Thanks for your cooperation. > >> amd...@freebsd.org: games/pink-pony >> amd...@freebsd.org: graphics/nvidia-texture-tools >> da...@freebsd.org: graphics/alembic >> da...@freebsd.org: graphics/appleseed >> da...@freebsd.org: graphics/hdr_tools >> dan...@freebsd.org: graphics/vips >> dumbb...@freebsd.org: graphics/darktable >> eha...@freebsd.org: graphics/exrtools >> free...@shaneware.biz: graphics/blender >> free...@shaneware.biz: graphics/openimageio >> free...@shaneware.biz: graphics/openshadinglanguage >> free...@shaneware.biz: graphics/py-openimageio >> gn...@freebsd.org: graphics/gegl >> gn...@freebsd.org: graphics/gegl3 >> g...@freebsd.org: graphics/enblend >> g...@freebsd.org: graphics/hugin >> h2+fbsdpo...@fsfe.org: graphics/luminance >> h2+fbsdpo...@fsfe.org: graphics/luminance-qt5 >> jamesb-...@excamera.com: graphics/py-openexr >> k...@freebsd.org: devel/kio-extras >> k...@freebsd.org: editors/calligra >> k...@freebsd.org: graphics/kf5-kimageformats >> k...@freebsd.org: graphics/krita >> k...@freebsd.org: x11/kde-runtime-kde4 >> k...@freebsd.org: x11/kdelibs-kde4 >> multime...@freebsd.org: graphics/gstreamer1-plugins-openexr >> oliv...@freebsd.org: graphics/openfx-io >> r...@freebsd.org: graphics/gimp-gmic-plugin >> thie...@freebsd.org: graphics/cimg >> woods...@freebsd.org: devel/synfig >> woods...@freebsd.org: graphics/synfigstudio >> y...@freebsd.org: graphics/gmic >> y...@freebsd.org: multimedia/cinelerra-gg > > Happy coding, > Matthias >
