---
title: 2023-09-13
parent: Meetings
---

# ASWF CI Working Group

Meeting: 13 September 2023

[https://zoom-lfx.platform.linuxfoundation.org/meeting/97730566101](https://zoom-lfx.platform.linuxfoundation.org/meeting/97730566101)

## Attendees

* Jean-Francois Panisset, VES Technology Committee
* Jean-Christophe Morin, Rez
* Aloys Baillet, NVIDIA
* Kerby Geffrard, OpenRV
* Larry Gritz, Sony Imageworks
* Jeff Bradley, Dreamworks
* Steven Mackenzie

## Apologies

* Christina Tempelaar-Lietz, ILM

## New items

* #release-announcements Slack channel
* 22 subscribers
* Missing projects?
* OCIO Configs
* Difficult to get visibility (only channel creator / John has access)
* Key off GitHub "draft a release" (RSS URL?)
* Larry: want to key off the release announcement, not just any tag. JF: is there an RSS feed for that? Larry: don't know, would need to check. Hopefully there's an RSS feed for just the releases, not every tag.
* Steven: before Rez was an ASWF project, we had in our Slack instance 4 channels for different GitHub Actions: when PR got made, moved. We have those channels in the ASWF Slack, but haven't hooked them up yet. How can we do that? JF: #opentimeio-github channel, also in the OCIO dedicated Slack. Open a LF-releng ticket and CC John Mertic.
* TODO: look at available RSS URLs
* VFX Platform 2024 containers
* Latest available versions specified by [VFX Platform](https://vfxplatform.org)
* Stick with Rocky 8.8 / NVIDIA CUDA base image?
* What CUDA version? We were at 11.8.0
* dependency with NVIDIA driver version
* Larry: still using 11.x at SPI, eventually will move to 12. Still struggling to get the OptiX part on CI.
* JF: no progress on regaining access to beta GPU runners
* Larry: would really like to regain access to GPU runners, would like to test every PR in OSL in GPU mode. Right now have to test PRs locally / manually.
* What about non specified items:
* Aloys: should try to update 2023 up to December
* Larry: for things not on VFX Platform, if I'm testing against 2021, what should I test against? I don't use Dec 31st as a cutoff, want to be representative of what people are building against for that year. So maybe pick something around the middle of the year? But for 2024, go with the latest we got, and upgrade as we get into 2024 so it's more representative of that year. But don't over think it, these are "samples", nothing will be perfect, but want something typical.
* Blosc (was 1.17.0)
* CCache (was 4.7.4)
* CMake (was 3.27.2)
* Is there such a thing as "too recent" a CMake?
* Larry: Cmake is one of the simplest dependencies to change if you need to, they also have binary downloads.
* Conan (was 1.58.0, anyone want to help with transition to 2.x?)
* Aloys: yes, we could wait after initial 2024 release for the transition. NVIDIA has quite a few Conan packages, but not sure if we've upgrade internally. Stephen: we haven't yet moved to Conan 2. Aloys: probably stay on 1.x for now. Steven: too early to say much, but may have task on my plate to do NVIDIA Conan 2, so may get a chance to poke at it, but also a Conan noob.
* CPPUnit (was 1.15.1)
* Glew (was 2.1.0)
* GLFW (was 3.1.2)
* GTest (was 1.11.0)
* HDF5 (was 1.0.23)
* Log4Cplus (was 1.1.2)
* MaterialX (was 1.38.7)
* 1.38.8
* Ninja (1.11.1)
* OptiX (7.7.0, but we install every version)
* OIIO
* Just entered beta, hopping for release in Oct (2.5.xxx)
* OSL (was 1.12.13.0)
* Larry: same as for OIIO, would like that also, but not quite ready yet (1.13 in about a month)
* OTIO (was 0.15)
* Partio (was 1.17.1)
* Pybind11 (was 2.9.2)
* 2.9.2 was last version before some big changes
* JC: 2.10 removes Python 2 support. Larry: does anyone build against Python 2 in 2024 container? I build against Python 2, but in a 2020 container.
* JC: between 2.9 and 2.10 that was one of the major changes, but it's an invisible upgrade if you don't depend on Python 2. But if you use a lot of internal functions it could be problematic, but otherwise should be OK. Have not heard of a failure updating from 2.9 to 2.10, including personal experience at work. We now building all packages with Pybind11 2.11
* USD (was 23.05)
* JF: latest at the time? Aloys: yes, usually update to the latest of the year.
* Additional project-specific build containers
* OIIO
* Larry: have been using the OSL one, but if it was a smaller docker container, it would be nice (don't need LLVM for instance), maybe help speed up the initial container download time. But it's not critical.
* OpenFX
* OpenAssetIO
* ?
* Additional build time dependencies
* libdeflate for OpenEXR
* OpenEXR 3.2 can use that. Larry: it's OpenEXR 3.2 if it's not found, it will download and install (default to use that instead of gzip lib).
* oiio:
* JPEGTurbo -> optional replacement (faster) for libjpeg, doesn't change OIIO functionality
* OpenCV -> only used for a couple of functions that act as a bridge with OpenCV, only useful for people who use both
* DCMTK
* ffmpeg -> YES
* libheif -> YES
* Ptex -> YES
* R3DSDK
* Nuke
* Qt6 -> for the simple viewer
* Qt5
* anything else? Larry: see build scripts in OIIO repo
* Larry: does anyone use those binaries? JF: I do
* Larry: don't forget the ORI projects, which may have carried dependencies. Kerby: we have built internally a Docker image from Rocky 9 to build RV, we have a task to push to ASWF docker. Should happen in the following weeks. We just need to change the FROM statement. That container won't require anything special, for now we still pull projects and build them, except Qt. For ASWF we'll have to use the latest open source Qt. Once done with Linux we'll add to our CI and then move on to Windows and Mac. So coming for OpenRV. We build OIIO, but we add special flags. Everything we build has special flags because reasons.
* CI WG Project Requirements Survey
* How best to communicate with ASWF projects, gather requirements
* Suggestion to run a survey
* Who is the target? Project TSCs?
* The TSCs are our clients
* Structured vs open ended
* Feedback on current initiatives vs future deliverables?
* Survey Length?
* JC: what kind of questions would we ask?
* What more would you need for ASWF containers for your project?
* What's missing in terms of infrastructure for your project? What would you change about the infrastructure? JC: MaterialX complaining about builds getting too slow when they have dependencies between jobs. Would bigger instances help? JF: would you use GPU or larger instances if available and for what builds.
* JC: do you know who to contact / how to ask for help? Do projects know who to talk to? Some projects try things on their own and don't necessarily reach out, perhaps they don't know who to ask / just want to solve their problems. Or maybe we don't get requests because everything is working!
* TODO: JF to provide sample questions for next meeting.
* Questions about DCOs (Kerby)
* Had hiccups with DCO process on OpenRV, some issues due to bad configuration
* A revert on GitHub UI doesn't work, can bypass the check from UI but not what we want.
* There's a DCO repo that exists
* Want to make sure we don't undermine the legal aspect of DCO. We may have a way to deal with reverting commits and DCO.
* JC: if you do a merge and squash, you have to move things around in the message to add the "Signed Off". With a normal merge it just work. Haven't seen failures.
* [DCO App Repo](https://github.com/dcoapp/app/tree/main#modes-of-operations)
* Are we allowed to put specific configuration in place? Doesn't seem like we need to have a DCO for reversing commits?
* JF: can create a ticket. JC: follow this [Link to the LF ASWF helpdesk](https://github.com/AcademySoftwareFoundation/foundation/issues/new/choose)
* Kerby: for now I click on the "Make it work" button so it's not a show stopper
* JC: you're not the only one who has problems, DCO is often tricky. And it's a bit awkward to sign for someone else.
* JC: on Rez have a failing PR since it's not signed with the "right" email address. Steven: if in GitHub perferences you use a GitHub private email and your local config uses your normal email, GitHub is trying to make sure you don't expose your real email, and is default on for most people.
* OpenShadingLanguage graduation and CII badges
* [Silver Level Checklist at 67%](https://www.bestpractices.dev/en/projects/3061?criteria_level=1)
* [Gold Level Checklist at 70%](https://www.bestpractices.dev/en/projects/3061?criteria_level=2)
* Is there something we can do to help the project complete Silver and Gold CII so it meets the [OpenSFF Best Practices Badge at the gold level requirements](https://github.com/AcademySoftwareFoundation/tac/blob/main/process/lifecycle.md#requirements-2)
* Larry: we are continuing to chip away over time, just because we've graduated doesn't mean we won't keep working on it. None of the projects that graduated before are at the Silver or Gold level.

## Follow Ups
* Pre-2023 ASWF containers vs Node GLIBC requirements
* No real solution without breaking VFX Platform glibc requirement
* Explicit policy on supporting previous years?
* GitHub Actions
* [Update on GPU runner beta availability](https://jira.linuxfoundation.org/plugins/servlet/desk/portal/2/IT-25805)
* Update on GPU runner release availability
* Update on Apple Silicon runners
* Update on monthly spend

## Tools and Links
* [Perfectly Reproducible, Verified Go Toolchains](https://go.dev/blog/rebuild)
* [Using Spack to build the VFX Reference Platform](https://dev.to/chadrik/using-spack-to-build-the-vfx-refence-platform-5788)
* [Discussion on running `pip` inside a DCC and structuring packages accordingly](https://academysoftwarefdn.slack.com/archives/C0169RX7MMK/p1694608441647749)
* [JetBrains RustOver Rust IDE](https://www.jetbrains.com/rust/)
*