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

[Tobias C. Berner]

Looks good for me with the kde@ hat on -- I think an exp-run wouldn't hurt.
But feel free to touch the required kde@ ports ad done in the diff.

mfg Tobias

On Mon, 17 Sep 2018 at 19:30, Matthias Andree <mandree at freebsd.org> wrote:

> Am 17.09.18 um 18:39 schrieb Tobias C. Berner:
> > Moin moin
> >
> > Do you have a list of the kde@ ports broken by the update? Or is this a
> > compile everything, then fix it call?
>
> Moin Tobias,
>
> Thanks for picking up the thread for kde at .
>
> This list you are asking about is empty, but you never know what happens
> with sweeping changes in the field after the fact, that's why I am
> pushing forward. We don't want a high-profile port diverging between
> quarterly and head, and we don't want to duplicate fix efforts right
> after the branch.
>
> I have compile-tested all ports in poudriere 11.2-RELEASE amd64 that
> have a direct dependency on ilmbase or OpenEXR listed that is either
> mandatory, or an option that defaults to "ON".
>
> The only casualty is the unmaintained (upstream and ports)
> graphics/ampasCTL (see below why) and none of the *kde* or *qt* ports
> have broken or killed ports that require them.  I may take one or two
> more stabs at ampasCTL to see if it turns out to be low-hanging fruit.
>
>
> My call is "check if you have any concerns about my proposed update to
> ilmbase/OpenEXR and the OpenEXR -> openexr rename".
> The proposed update is the one I provide as patch, not the earlier shar
> file.
>
> If you are keeping an outside private KDE repository, you may have to
> merge my patch into your private kde@ repository once I commit, and test
> your own ports that depend on ilmbase/openexr before you commit your
> tree back to the FreeBSD ports repository.
>
>
> NOTE:  I think I do not formally need to ask approval about PORTREVISION
> bumps and bumps to requisite library changes, we do not normally do that.
>
> I do want to coordinate nonetheless, and I'll happily receive approvals.
>
> I just can't afford to spend hours on end to chase down everybody behind
> mail exploders.  I believe I've done a thorough job of testing the
> builds and direct dependents, and if someone wants to do a full -exp
> run, use the patch from my previous message, URIs repeated below for
> convenience:
>
> - https://people.freebsd.org/~mandree/openexr-v2.patch
> - https://people.freebsd.org/~mandree/openexr-v2.patch.asc (GnuPG sign.)
>
>
> Note that OpenEXR is not formally advertised as incompatible, what I
> found out so far is:
>
> * "Iex::BaseExc no longer derived from std::string." is what appears to
> have broken ampasCTL
> <https://github.com/openexr/openexr/releases/tag/v2.3.0> because it
> can't seem to std::cout << ... those data types any more and I get a
> truckload of excuses why none of the candidates is viable for automatic
> type conversion.  Haven't yet dug deeper, but I don't consider an
> unmaintained (upstream & downstream) leaf port as sitting in the
> critical path anyways, we can fix it after the fact (and the fix could
> also be MFHd from head to quarterly without ado since it's unbreaking a
> broken port, hence pre-approved).
>
> Cheers,
> Matthias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-freebsd/attachments/20180917/40e408ef/attachment.html>