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