Hi All, I'm a new to both Nuke and OCIO. For some reason, I need to develop a nuke OP similar to OCIOFileTransform. But when I add just one simple line such as "OCIO::GetCurrentConfig()", I got a

Hi, For some reason, I need to write a pixelOp similar to OCIOFileTransform with OCIO API. But when I add just one simple line such as "OCIO::GetCurrentConfig()", I got a crash with the terrible "Pure

Hi all, I would like to know if OCIO java public interface is used? and should be maintained ? OCIO currently supports three public interfaces: 1) The native C++, 2) The Python interface (built on top

Version 1.1.0 has just been released and is located on the "RB-1.1" branch for long-term support. Please continue to evaluate and we will release patches as necessary. Thanks!

Crap, never mind again... Richard

Ok, I spoke too soon, this doesn't look like a missing package problem: ! Package babel Error: You haven't specified a language option. See the babel package documentation for

I'm getting it figured out... It's missing texlive packages but I don't want to install EVERYTHING because there's tons of packages, so I'm having to find what's missing one at a time and keep trying

In my previous email I pasted the output from building the pdf documentation. For some reason pdflatex is getting to an interactive prompt which is of course bad when trying to build a package :)

What issues are you having with the documentation?

Yes, this is with the PR already being applied as a patch, I appear to only be having issues with building the documentation. I can disable that but I would hate to release a new package without the

Richard, have you tested Patrick's PR for the GCC fixes? I'm looking to release today and don't want to slot in unnecessary commits to the release, they have already been merged to master so will show

Ok, so I "fixed" it by adding --install-dir to all the python external projects but now I run into this: [ 61%] Building pdf doc cd

Yeah, I've thought about it. I actually added most of the USE_EXTERNAL... stuff when I first got OCIO in Fedora but I have far fewer free cycles these days. Thanks, Richard

If you have some time you could do a pull request :) to help the community...

I think that's because ubuntu uses debian's scheme instead of /usr/lib{,64} like RPM based distros. Either way, there's still the question about why the system installed setuptools isn't

double-checked using the ubuntu 16 & gcc 5.4.0 docker image and setuptools is working fine.

Ok, next error, setuptools is built thinking it needs /usr/lib but installs to /usr/lib64 (as it should) and then it gets confused. Side question: Why do we have to build a bundled setuptools instead

Please have a look to PR #498 to have the standalone fix (for gcc 5.4.0)

Using newer gcc version (i.e. 7.2.1), you are facing new warnings. Please have a look to PR 488 where most of your problems should have been

Ok, so I changed to yaml-cpp 0.5.x (was still using 0.3.x) and got past cmake, now: /home/build/rpmbuild/OpenColorIO/BUILD/OpenColorIO-RB-1.1/src/core/Lut1DOp.cpp:192:14: error: 'void