HEADS UP: [msg #2] graphics/ilmbase and graphics/OpenEXR update planned includes openexr rename - feedback required until Sept 23/portmgr Sept 21

[Mathieu Arnold]

On Sun, Sep 16, 2018 at 12:21:18PM +0200, Matthias Andree wrote:
> 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 at ...) 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.

No, you will have to contact the maintainers, individually if needs be,
even if they are groups, and make sure they approve the update.

> 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.

No, you do not commit stuff and fix the fallout afterwards (or hope
someone will fix it for you, not sure what you are meaning here). You
can submit a patch for exp-run, and work on fixing the fallout before
you can commit your patch.  Once everything is ok to go, you will be
allowed to commit your patch.

> 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.
> > 
> >> amdmi3 at FreeBSD.org: games/pink-pony
> >> amdmi3 at FreeBSD.org: graphics/nvidia-texture-tools
> >> danfe at FreeBSD.org: graphics/alembic
> >> danfe at FreeBSD.org: graphics/appleseed
> >> danfe at FreeBSD.org: graphics/hdr_tools
> >> danilo at FreeBSD.org: graphics/vips
> >> dumbbell at FreeBSD.org: graphics/darktable
> >> ehaupt at FreeBSD.org: graphics/exrtools
> >> FreeBSD at Shaneware.biz: graphics/blender
> >> FreeBSD at Shaneware.biz: graphics/openimageio
> >> FreeBSD at Shaneware.biz: graphics/openshadinglanguage
> >> FreeBSD at Shaneware.biz: graphics/py-openimageio
> >> gnome at FreeBSD.org: graphics/gegl
> >> gnome at FreeBSD.org: graphics/gegl3
> >> grog at FreeBSD.org: graphics/enblend
> >> grog at FreeBSD.org: graphics/hugin
> >> h2+fbsdports at fsfe.org: graphics/luminance
> >> h2+fbsdports at fsfe.org: graphics/luminance-qt5
> >> jamesb-bsd at excamera.com: graphics/py-openexr
> >> kde at FreeBSD.org: devel/kio-extras
> >> kde at FreeBSD.org: editors/calligra
> >> kde at FreeBSD.org: graphics/kf5-kimageformats
> >> kde at FreeBSD.org: graphics/krita
> >> kde at FreeBSD.org: x11/kde-runtime-kde4
> >> kde at FreeBSD.org: x11/kdelibs-kde4
> >> multimedia at FreeBSD.org: graphics/gstreamer1-plugins-openexr
> >> olivier at FreeBSD.org: graphics/openfx-io
> >> rm at FreeBSD.org: graphics/gimp-gmic-plugin
> >> thierry at FreeBSD.org: graphics/cimg
> >> woodsb02 at FreeBSD.org: devel/synfig
> >> woodsb02 at FreeBSD.org: graphics/synfigstudio
> >> yuri at FreeBSD.org: graphics/gmic
> >> yuri at FreeBSD.org: multimedia/cinelerra-gg
> > 
> > Happy coding,
> > Matthias
> > 
> 
> 

-- 
Mathieu Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-freebsd/attachments/20180916/20164a0f/attachment.sig>