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