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