HEADS UP: [msg #3] graphics/ilmbase and graphics/OpenEXR update planned includes openexr rename - update

Matthias Andree mandree at FreeBSD.org
Thu Sep 20 20:42:36 BST 2018


Am 17.09.18 um 19:30 schrieb Matthias Andree:

> * "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).

I had checked out the ports tree earlier this week and ran poudriere on
all direct and indirect dependencies, no new casualties, two ignores
(one of them was ampasCTL), but hadn't let libreoffice complete.

Result: two ignored ports, libreoffice suffered the user abort, all
other ports could be built, so I'll forego the -exp run for good, no
fails, no skips.

One ignored port was a KDE4 port that was already marked broken on 11.2
due to wanting kernel internals, and as to the other ignored one, it was
graphics/ampasCTL (unmaintained). I could -after the poudriere test run-
fix the latter port for ilmbase 2.3.0 compatibility with a one-liner
patch to ampasCTL in the C++ exception propagation that turns a caught
exception "e" into "e.what()", to substitute for the missing
auto-conversion method from the Iex::BaseExc into std::string.  This
changes matches what one of the unit tests does.

The fix will, of course, be added to the commit, and has been posted
upstream, https://github.com/ampas/CTL/issues/71 -- although I do not
believe anyone there will care.

I'll retry to rebuild all ilmbase/OpenEXR dependants with a newly
updated ports tree and commit if no new casualties show up.


If anyone knows a trick to have VirtualBox 5.2.x on an amd64 alias
x86_64 Linux host (Fedora 28) expose all Ryzen 7 1700 SMT logical CPUs
to a FreeBSD 11.2 guest, let me know - I only see 8 of the 16 in
VirtualBox, but do get 16 natively.  The extpack is installed.


More information about the kde-freebsd mailing list