ci: Lock down 2023 container to prevent build breaks for OCIO

[lgritz]

Unbreak CI

[jfpanisset]

That will work, and presumably is meant to address:

  229 | #if MZ_VERSION_BUILD >= 040000
      |     ^~~~~~~~~~~~~~~~
/github/home/ext/OpenColorIO/src/OpenColorIO/OCIOZArchive.cpp:245:5: error: user-defined literal in preprocessor expression

in this run: `icx/C++17 llvm14 py3.10 oiio-3.0 avx2 / icpx c++17 py3.10

The 2023 images have OCIO 2.2.1, so the questions are:

• Why does this job try to build OCIO 2.3.2 instead of using the 2.2.1 already in the image? Does it make sense to try to build in a VFX Platform year with a different OCIO version than what's called for by that platform year?
• Why does this particular 2023 job fail, when others seem to be working? This job seems to be using the Intel compiler.

The actual root of the issue is that the 2023 images have minizip-ng 3.0.10, 2024-2026 have 4.0.10. In 3.0.10 the main include mz.h defines:

#define MZ_VERSION_BUILD                (03000a)

which is not a valid hex constant and breaks the comparisons against the pre-processor symbol in OCIO 2.3.2. minizip-ng 4.0.10 has a correctly formed MZ_VERSION_BUILD:

#define MZ_VERSION_BUILD (0x04000A)

I can definitely build OCIO 2.2.1 in the updated 2023 ci-ocio image since it doesn't have this comparison code against an invalid hex constant.

[jfpanisset]

This will help unbreak the CI, see my comment about the root cause being the minizip-ng version and trying to build OCIO 2.3.x in a VFX Platform 2023 environment.

[jfpanisset]

I can reproduce the build failure in OCIOZArchive.cpp when compiling OCIO 2.3.2 in the 2023.3 images, which is not a combination I test against.

If this is required for OSL, I would have to check with the OCIO folks if they would be OK with updating minizip-ng in the 2023 images since OCIO is the only consumer of that package.

[lgritz]

• Why does this job try to build OCIO 2.3.2 instead of using the 2.2.1 already in the image? Does it make sense to try to build in a VFX Platform year with a different OCIO version than what's called for by that platform year?

That's a good question, and I don't know the answer. I will try just relying on the container and see if that's an adequate solution (which would be better from my point of view, because it's less my CI needs to take the time to build from scratch).

[jfpanisset]

I'm guessing OSL needs a newer OIIO than the 2.4.17.0 it finds in the 2023.3 image, tries to build latest OIIO, which in turn needs newer OIIO than the 2.2.1 in that image, so it tries to build 2.3.2?

See AcademySoftwareFoundation/OpenColorIO#2314 (comment) for a possible patch to mz.h / OCIO 2.3.2 which should allow building in the 2023.3 image if that's of interest.

[lgritz]

It sure looks like it succeeds if I only remove the line that forces an OCIO build. The one in the container seems good enough. I will file a separate PR for that solution, and if it looks ok, we can close this one.