Replace LIBKINETO_NO* build flags with KINETO_BACKEND by scotts · Pull Request #1388 · pytorch/kineto

scotts · 2026-05-04T22:30:15Z

Selecting a GPU backend (or no GPU at all) in libkineto's CMake build required setting up to three flags phrased in the negative: LIBKINETO_NOCUPTI, LIBKINETO_NOROCTRACER, LIBKINETO_NOXPUPTI. A CPU-only build had to pass all three: (-DLIBKINETO_NOCUPTI=1 -DLIBKINETO_NOROCTRACER=1 -DLIBKINETO_NOXPUPTI=1) The flags were also inconsistent with each other: only LIBKINETO_NOCUPTI was a real option(); LIBKINETO_NOXPUPTI was undeclared and required if(DEFINED ... AND NOT ...) everywhere it was checked.

Why

The flags grew up incrementally as each backend was added, and the NO* framing matched how the surrounding code already gated CUPTI. Meanwhile the C++ source uses positive macros (HAS_CUPTI, HAS_ROCTRACER, HAS_XPUPTI), so the negation lived only in the CMake/CI/PyTorch-glue layer. The mutual exclusivity of the backends was enforced by an if/elseif chain on three independent variables instead of being expressed directly.

Approach

Introduce a single KINETO_BACKEND variable taking one of cpu, cuda, rocm, xpu (default cpu). The variable directly expresses the "exactly one backend" constraint. Selection is now explicit: if the user picks cuda/rocm/xpu and the corresponding toolkit isn't available, configuration fails fast instead of silently degrading.

The C++ source is unchanged — HAS_CUPTI/HAS_ROCTRACER/HAS_XPUPTI are still emitted by the build, just driven by KINETO_BACKEND rather than the inverted flags.

A backwards-compatibility shim in libkineto/CMakeLists.txt translates the legacy LIBKINETO_NO* flags into KINETO_BACKEND so existing callers (notably pytorch/cmake/Dependencies.cmake) keep building during the changeover. The shim is marked with a TODO and will be removed once PyTorch migrates to KINETO_BACKEND.

The CI scripts under .github/scripts/config_*.sh are updated to use the new flag. The existing PyTorch build and test CI jobs check that this will still work when we release these changes upstream.

**Problem** Selecting a GPU backend (or no GPU at all) in libkineto's CMake build required setting up to three flags phrased in the negative: `LIBKINETO_NOCUPTI`, `LIBKINETO_NOROCTRACER`, `LIBKINETO_NOXPUPTI`. A CPU-only build had to pass all three (`-DLIBKINETO_NOCUPTI=1 -DLIBKINETO_NOROCTRACER=1 -DLIBKINETO_NOXPUPTI=1`), which is the opposite of what a reader expects when configuring "no GPU support." The flags were also inconsistent with each other: only `LIBKINETO_NOCUPTI` was a real `option()`; `LIBKINETO_NOXPUPTI` was undeclared and required `if(DEFINED ... AND NOT ...)` everywhere it was checked. **Why** The flags grew up incrementally as each backend was added, and the "NO*" framing matched how the surrounding code already gated CUPTI. Meanwhile the C++ source uses positive macros (`HAS_CUPTI`, `HAS_ROCTRACER`, `HAS_XPUPTI`), so the negation lived only in the CMake/CI/PyTorch-glue layer. The mutual exclusivity of the backends was enforced by an `if/elseif` chain on three independent variables instead of being expressed directly. **Approach** Introduce a single `KINETO_BACKEND` variable taking one of `cpu`, `cuda`, `rocm`, `xpu` (default `cpu`). The variable directly expresses the "exactly one backend" constraint. Selection is now explicit: if the user picks `cuda`/`rocm`/`xpu` and the corresponding toolkit isn't available, configuration fails fast instead of silently degrading. The C++ source is unchanged — `HAS_CUPTI`/`HAS_ROCTRACER`/`HAS_XPUPTI` are still emitted by the build, just driven by `KINETO_BACKEND` rather than the inverted flags. A backwards-compatibility shim in `libkineto/CMakeLists.txt` translates the legacy `LIBKINETO_NO*` flags into `KINETO_BACKEND` so existing callers (notably `pytorch/cmake/Dependencies.cmake`) keep building during the changeover. The shim is marked with a TODO and will be removed once PyTorch migrates to `KINETO_BACKEND`. The CI scripts under `.github/scripts/config_*.sh` are updated to use the new flag. **Test plan** Verified locally: - `cmake -DKINETO_BACKEND=cpu` configures and builds. - `cmake -DKINETO_BACKEND=cuda` configures, finds CUPTI, builds. - Legacy `-DLIBKINETO_NOCUPTI=1 -DLIBKINETO_NOROCTRACER=1 -DLIBKINETO_NOXPUPTI=1` flows through the shim to `KINETO_BACKEND=cpu`. - Legacy `-DLIBKINETO_NOXPUPTI=OFF` flows through the shim to `KINETO_BACKEND=xpu` and produces the expected explicit-selection error when SYCL is missing. - `cmake -DKINETO_BACKEND=foo` fails with a validation error.

**Problem** `libkineto/test/CMakeLists.txt` re-ran SYCL toolkit detection and warned-and-skipped the XPU test target if SYCL wasn't found. **Why** This block was unreachable. The main `CMakeLists.txt` calls `add_subdirectory(src/plugin/xpupti)` before reaching the test subdirectory, and that subdir now `FATAL_ERROR`s if SYCL is missing. By the time the test CMakeLists runs with `KINETO_BACKEND=xpu`, SYCL is necessarily available, so the warn-and-skip path could never fire. The associated `_kineto_test_with_xpu` local variable existed solely to preserve that dead behavior. **Fix** Drop the SYCL re-detection and the helper variable; gate the XPU test target directly on `KINETO_BACKEND STREQUAL "xpu"`.

The "Using built-in FindCUDAToolkit target" suffix and the comment about NVPERF being available "starting in CUDA 10.2" were notes from when the target had to be located by hand. CMake's FindCUDAToolkit has provided `CUDA::nvperf_host` for many years; the narration is no longer useful.

The defaults for `ROCM_INCLUDE_DIRS` and `ROCTRACER_INCLUDE_DIR`, the status message that prints them, and the `target_include_directories` call that wired them onto `kineto_base` all ran unconditionally. On a non-ROCm build this set the variables to nonsense like `"/include"` and attached that path as a SYSTEM PUBLIC include directory; CMake silently drops missing paths so it was harmless, but it was misleading in the configure log and clutter in the include set. Consolidate the defaults into the existing ROCm prerequisites block, remove the duplicate later in the file, and gate the include-attach and status message on `KINETO_BACKEND STREQUAL "rocm"`.

The ROCm prerequisites block and the "Detect ROCM Version" block were both gated on `KINETO_BACKEND STREQUAL "rocm"` and run sequentially with only the unrelated XPU plugin block between them. Combine them into a single rocm-gated section so all the ROCm-specific configure-time work lives together. Also reorder so the XPU plugin block comes after, keeping each backend's setup contiguous.

The status message had no ordering dependency on anything outside the ROCm prerequisites block — it's pure diagnostic output for a path that gets finalized inside that block. It was sitting next to the DYNOLOG/IPCFABRIC messages only as a relic of when the ROCm defaults were computed unconditionally. Move it up so all ROCm configure-log output appears together.

The two `if(KINETO_BACKEND STREQUAL "rocm")` and `if(KINETO_BACKEND STREQUAL "xpu")` blocks that attached system-public include directories to `kineto_base` were redundant with the existing per-backend `if/elseif` chain that wires up backend libraries. Both operate on the already- created `kineto_base` target with no ordering constraint between them, so consolidating into a single dispatch keeps each backend's header+library wiring adjacent and removes two separate guards on the same condition.

The three top-level `if(KINETO_BACKEND STREQUAL ...)` blocks for CUDA detection, ROCm prereqs+version detection, and the XPU subdirectory were mutually exclusive but written as three separate guards. Validation already enforces that exactly one branch matches, so an if/elseif/elseif chain expresses the intent more directly and skips the two redundant string comparisons in each configure.

…hain The four separate `if(KINETO_BACKEND STREQUAL ...)` guards setting backend-specific preprocessor definitions and compile options were mutually exclusive, with the cuda dispatch split across two of them (`HAS_CUPTI` plus the conditional `USE_CUPTI_RANGE_PROFILER`). Consolidate into a single if/elseif/elseif chain — one arm per backend — and fold the two cuda fragments together. Pre-existing Windows-exclusion comment on the range profiler is preserved.

The four if/elseif chains over `KINETO_BACKEND` had drifted into inconsistent ordering — file lists used cpu/rocm/cuda/xpu, the link chain used rocm/cuda/xpu. Reorder every chain to a single canonical sequence (cpu, cuda, rocm, xpu, with absent backends omitted) so readers can scan any chain with the same expectations.

**Fail loudly when the ROCm version header is missing** The find_file → conditional set → file(READ) sequence would call `file(READ "" ...)` if rocm_version.h wasn't found, producing a confusing error that didn't name the actual cause. Replace with an explicit FATAL_ERROR that points at the missing path. The latent bug was pre-existing but became more reachable once explicit selection removed the silent CPU fallback. **Switch `if(${VAR})` to `if(VAR)`** CMake's `if()` already does variable lookup, so the explicit `${...}` expansion is unnecessary and can interact badly with empty/quoted values. Functionally equivalent for the values these sites currently hold; the bare form is the modern convention. **Move ROCTRACER_FALLBACK from add_compile_options to KINETO_DEFINITIONS** `add_compile_options(-DROCTRACER_FALLBACK)` was directory-scope, applying to every target compiled in libkineto/ and its subdirectories — fmt, ipcfabric, gtest, the test binaries. Hoist it into KINETO_DEFINITIONS (gated on `NOT USE_ROCPROFILER_SDK`) so it propagates only through the kineto_base PUBLIC interface, reaching exactly the kineto targets and their consumers (e.g., the rocm test target). **XPU include-dir generator-expression consistency** The XPU site attached `${XPUPTI_INCLUDE_DIR}` bare while the ROCm site uses `$<BUILD_INTERFACE:...>`. Make XPU consistent so the include doesn't accidentally leak into the install interface. **Dual target_link_libraries: comment the invariant** Add a comment explaining why each backend dependency is attached to both `kineto_base` (object library, for source compilation) and `kineto` (wrapper, for downstream linking) — `$<TARGET_OBJECTS:>` does not propagate INTERFACE properties, so both halves are required. Future contributors adding a backend dependency need to know.

The compatibility shim only fires on the initial configure. On any subsequent configure, KINETO_BACKEND is in the cache, the shim is skipped, and newly-passed legacy flags are silently ignored. A user who sets `-DKINETO_BACKEND=cuda`, then later tries to switch to a CPU build by passing the legacy `-DLIBKINETO_NO*` flags, would still get a CUDA build with no indication that the legacy flags didn't take. Detect the disagreement and emit a CMake `WARNING` pointing at the implied backend and suggesting the explicit fix. The warning suppresses itself when the legacy flags agree with the cached value (the common case for re-runs of the same configure).

meta-codesync · 2026-05-05T17:33:19Z

@scotts has imported this pull request. If you are a Meta employee, you can view this in D103883609.

The generator-expression "consistency" cleanup had wrapped the XPU include attachment in $<BUILD_INTERFACE:${XPUPTI_INCLUDE_DIR}> to match the ROCm sites. That broke the XPU build because XPUPTI_INCLUDE_DIR is a multi-path semicolon list (SYCL toolkit include, SYCL header subdir, and Intel PTI include). When CMake wraps a multi-element list in a single $<BUILD_INTERFACE:...> expression, the second-and-later items lose their leading slash and get treated as relative paths off the source dir; the third item silently disappears entirely. The result on XPU CI was `sycl/sycl.hpp: No such file or directory` because the SYCL include path was being resolved as `<libkineto_src>/opt/intel/oneapi/...` rather than `/opt/intel/oneapi/...`. ROCm's `$<BUILD_INTERFACE:...>` sites get away with the same wrapping because `ROCM_INCLUDE_DIRS` and `ROCTRACER_INCLUDE_DIR` are each single paths, not lists. Revert just the XPU site to the bare form (which is what worked before the cleanup) and add an inline comment explaining the asymmetry so a future reader doesn't repeat the mistake. `kineto_base` is not installed, so the install-interface concern that motivates `BUILD_INTERFACE` elsewhere doesn't apply.

NicolasHug · 2026-05-08T06:49:01Z

+# Warn if legacy LIBKINETO_NO* flags disagree with the cached KINETO_BACKEND.
+# The shim only fires on initial configure; once KINETO_BACKEND is in the
+# cache, subsequent legacy-flag changes are silently ignored. Detect that and
+# tell the user. TODO: remove with the rest of the legacy shim.


you're being too nice!

I'm hoping the window of time this shim will need to exist is less than a week!

scotts · 2026-05-08T14:27:00Z

The ROCm failures are pre-existing. See https://github.com/pytorch/kineto/actions/runs/25532405262/job/74941277250?pr=1391 on #1391.

meta-codesync · 2026-05-08T14:41:41Z

@scotts merged this pull request in 7739225.

Includes the following commits: - Replace LIBKINETO_NO* build flags with KINETO_BACKEND (pytorch/kineto#1388) 7739225 - Add git fetch <path_to_kineto_repo> main (pytorch/kineto#1384) 63cc35e - Daily `arc lint --take CLANGFORMAT` (pytorch/kineto#1386) b40959c - Introduce XPU scope profiler extending existing XPU profiler plugin (pytorch/kineto#1174) d636a94 - Refactor CI to be more fine-grain (pytorch/kineto#1385) f78048c Pull Request resolved: #182973 Approved by: https://github.com/divyanshk

…ND (#183388) **Problem** Building PyTorch against kineto requires three negative-form switches: LIBKINETO_NOCUPTI, LIBKINETO_NOROCTRACER, LIBKINETO_NOXPUPTI. A CPU-only build has to set all three, and the negation lives only in the build glue: kineto's C++ sources have always used the positive-form HAS_CUPTI / HAS_ROCTRACER / HAS_XPUPTI. PyTorch's CMake mirrors the awkwardness with a three-way flag derivation and a CXX_FLAGS pass-through of the negative macros into PyTorch's own translation units. **Why** In pytorch/kineto#1388, Kineto replaced the three NO-flags with a single mode-style KINETO_BACKEND flags. It can take on one of the values in {cpu, cuda, rocm, xpu} and included a compatibility shim that still honors the old flags. The shim is meant to be deleted once PyTorch migrates. This change does the PyTorch-side migration so the shim can go. **Fixes** - Dependencies.cmake derives KINETO_BACKEND directly from USE_CUDA / USE_ROCM / USE_XPU+XPU_ENABLE_KINETO and forwards it to Kineto. The global CXX_FLAGS append is kept -- torch_cpu links kineto PRIVATE, so kineto's own PUBLIC HAS_* compile defs don't reach torch_python TUs like init.cpp -- but it now emits the positive macros -DHAS_*. - init.cpp's preprocessor guard switches to those positive macros. - The cudart-link guard in caffe2/CMakeLists.txt switches from NOT LIBKINETO_NOCUPTI to KINETO_BACKEND STREQUAL "cuda". Authored by Claude. Pull Request resolved: #183388 Approved by: https://github.com/NicolasHug, https://github.com/jathu

Summary: The CMake refactor (#1388) replaced `LIBKINETO_NOCUPTI`, `LIBKINETO_NOROCTRACER`, and `LIBKINETO_NOXPUPTI` with a single `KINETO_BACKEND` variable, but kept a shim that translated the legacy flags during the cross-repo migration window. pytorch/pytorch#183388 migrated PyTorch's `cmake/Dependencies.cmake` and `torch/csrc/autograd/init.cpp` have now both been migrated to use `KINETO_BACKEND` / `HAS_*` directly. The shim has no remaining caller. **Approach** Delete the shim block and the cached-vs-new-legacy-flags conflict warning that existed only to ease the migration. Replace with a simpler guard that warns when `KINETO_BACKEND` wasn't set at all and the build defaulted to `cpu`. This catches stragglers passing legacy `LIBKINETO_NO*` flags as a side effect — they'll be silently ignored, `KINETO_BACKEND` will default to `cpu`, and the new warning will tell them how to pick a backend explicitly. The new code carries no knowledge of the legacy flag names, so the kineto repo is now free of all `LIBKINETO_NO*` references. The warning fires only on initial configure (subsequent re-runs find `KINETO_BACKEND` populated in the cache) and on a freshly-wiped build directory. Pull Request resolved: #1399 Reviewed By: NicolasHug Differential Revision: D104927633 Pulled By: scotts fbshipit-source-id: 71e5f4103d77e4550bf74c5bed22c9808c8a6f5b

Includes the following commits: - Replace LIBKINETO_NO* build flags with KINETO_BACKEND (pytorch/kineto#1388) 7739225 - Add git fetch <path_to_kineto_repo> main (pytorch/kineto#1384) 63cc35e - Daily `arc lint --take CLANGFORMAT` (pytorch/kineto#1386) b40959c - Introduce XPU scope profiler extending existing XPU profiler plugin (pytorch/kineto#1174) d636a94 - Refactor CI to be more fine-grain (pytorch/kineto#1385) f78048c Pull Request resolved: pytorch#182973 Approved by: https://github.com/divyanshk

…ND (pytorch#183388) **Problem** Building PyTorch against kineto requires three negative-form switches: LIBKINETO_NOCUPTI, LIBKINETO_NOROCTRACER, LIBKINETO_NOXPUPTI. A CPU-only build has to set all three, and the negation lives only in the build glue: kineto's C++ sources have always used the positive-form HAS_CUPTI / HAS_ROCTRACER / HAS_XPUPTI. PyTorch's CMake mirrors the awkwardness with a three-way flag derivation and a CXX_FLAGS pass-through of the negative macros into PyTorch's own translation units. **Why** In pytorch/kineto#1388, Kineto replaced the three NO-flags with a single mode-style KINETO_BACKEND flags. It can take on one of the values in {cpu, cuda, rocm, xpu} and included a compatibility shim that still honors the old flags. The shim is meant to be deleted once PyTorch migrates. This change does the PyTorch-side migration so the shim can go. **Fixes** - Dependencies.cmake derives KINETO_BACKEND directly from USE_CUDA / USE_ROCM / USE_XPU+XPU_ENABLE_KINETO and forwards it to Kineto. The global CXX_FLAGS append is kept -- torch_cpu links kineto PRIVATE, so kineto's own PUBLIC HAS_* compile defs don't reach torch_python TUs like init.cpp -- but it now emits the positive macros -DHAS_*. - init.cpp's preprocessor guard switches to those positive macros. - The cudart-link guard in caffe2/CMakeLists.txt switches from NOT LIBKINETO_NOCUPTI to KINETO_BACKEND STREQUAL "cuda". Authored by Claude. Pull Request resolved: pytorch#183388 Approved by: https://github.com/NicolasHug, https://github.com/jathu

Includes the following commits: - Replace LIBKINETO_NO* build flags with KINETO_BACKEND (pytorch/kineto#1388) 7739225 - Add git fetch <path_to_kineto_repo> main (pytorch/kineto#1384) 63cc35e - Daily `arc lint --take CLANGFORMAT` (pytorch/kineto#1386) b40959c - Introduce XPU scope profiler extending existing XPU profiler plugin (pytorch/kineto#1174) d636a94 - Refactor CI to be more fine-grain (pytorch/kineto#1385) f78048c Pull Request resolved: pytorch#182973 Approved by: https://github.com/divyanshk

…ND (pytorch#183388) **Problem** Building PyTorch against kineto requires three negative-form switches: LIBKINETO_NOCUPTI, LIBKINETO_NOROCTRACER, LIBKINETO_NOXPUPTI. A CPU-only build has to set all three, and the negation lives only in the build glue: kineto's C++ sources have always used the positive-form HAS_CUPTI / HAS_ROCTRACER / HAS_XPUPTI. PyTorch's CMake mirrors the awkwardness with a three-way flag derivation and a CXX_FLAGS pass-through of the negative macros into PyTorch's own translation units. **Why** In pytorch/kineto#1388, Kineto replaced the three NO-flags with a single mode-style KINETO_BACKEND flags. It can take on one of the values in {cpu, cuda, rocm, xpu} and included a compatibility shim that still honors the old flags. The shim is meant to be deleted once PyTorch migrates. This change does the PyTorch-side migration so the shim can go. **Fixes** - Dependencies.cmake derives KINETO_BACKEND directly from USE_CUDA / USE_ROCM / USE_XPU+XPU_ENABLE_KINETO and forwards it to Kineto. The global CXX_FLAGS append is kept -- torch_cpu links kineto PRIVATE, so kineto's own PUBLIC HAS_* compile defs don't reach torch_python TUs like init.cpp -- but it now emits the positive macros -DHAS_*. - init.cpp's preprocessor guard switches to those positive macros. - The cudart-link guard in caffe2/CMakeLists.txt switches from NOT LIBKINETO_NOCUPTI to KINETO_BACKEND STREQUAL "cuda". Authored by Claude. Pull Request resolved: pytorch#183388 Approved by: https://github.com/NicolasHug, https://github.com/jathu

Includes the following commits: - Replace LIBKINETO_NO* build flags with KINETO_BACKEND (pytorch/kineto#1388) 7739225 - Add git fetch <path_to_kineto_repo> main (pytorch/kineto#1384) 63cc35e - Daily `arc lint --take CLANGFORMAT` (pytorch/kineto#1386) b40959c - Introduce XPU scope profiler extending existing XPU profiler plugin (pytorch/kineto#1174) d636a94 - Refactor CI to be more fine-grain (pytorch/kineto#1385) f78048c Pull Request resolved: pytorch#182973 Approved by: https://github.com/divyanshk

…ND (pytorch#183388) **Problem** Building PyTorch against kineto requires three negative-form switches: LIBKINETO_NOCUPTI, LIBKINETO_NOROCTRACER, LIBKINETO_NOXPUPTI. A CPU-only build has to set all three, and the negation lives only in the build glue: kineto's C++ sources have always used the positive-form HAS_CUPTI / HAS_ROCTRACER / HAS_XPUPTI. PyTorch's CMake mirrors the awkwardness with a three-way flag derivation and a CXX_FLAGS pass-through of the negative macros into PyTorch's own translation units. **Why** In pytorch/kineto#1388, Kineto replaced the three NO-flags with a single mode-style KINETO_BACKEND flags. It can take on one of the values in {cpu, cuda, rocm, xpu} and included a compatibility shim that still honors the old flags. The shim is meant to be deleted once PyTorch migrates. This change does the PyTorch-side migration so the shim can go. **Fixes** - Dependencies.cmake derives KINETO_BACKEND directly from USE_CUDA / USE_ROCM / USE_XPU+XPU_ENABLE_KINETO and forwards it to Kineto. The global CXX_FLAGS append is kept -- torch_cpu links kineto PRIVATE, so kineto's own PUBLIC HAS_* compile defs don't reach torch_python TUs like init.cpp -- but it now emits the positive macros -DHAS_*. - init.cpp's preprocessor guard switches to those positive macros. - The cudart-link guard in caffe2/CMakeLists.txt switches from NOT LIBKINETO_NOCUPTI to KINETO_BACKEND STREQUAL "cuda". Authored by Claude. Pull Request resolved: pytorch#183388 Approved by: https://github.com/NicolasHug, https://github.com/jathu

meta-cla Bot added the cla signed label May 4, 2026

scotts added ciflow/rocm ciflow/xpu labels May 4, 2026

facebook-github-tools Bot added the module: rocm label May 4, 2026

scotts added 11 commits May 5, 2026 06:04

scotts marked this pull request as ready for review May 5, 2026 17:27

NicolasHug approved these changes May 8, 2026

View reviewed changes

meta-codesync Bot closed this in 7739225 May 8, 2026

facebook-github-tools Bot added the Merged label May 8, 2026

scotts mentioned this pull request May 8, 2026

Update third_party/kineto submodule to 7739225 pytorch/pytorch#182973

Closed

scotts mentioned this pull request May 12, 2026

Switch PyTorch's kineto build glue from LIBKINETO_NO* to KINETO_BACKEND pytorch/pytorch#183388

Closed

scotts mentioned this pull request May 13, 2026

Remove LIBKINETO_NO* compatibility shim #1399

Closed

This was referenced May 23, 2026

[review-only] PR1: fix(rocm): attribute per-stream GPU activities under rocprofiler-sdk ajassani/kineto#1

Draft

[review-only] PR3: feat(rocm): port sync-API metadata + inter-stream deps to roctracer backend ajassani/kineto#3

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Replace LIBKINETO_NO* build flags with KINETO_BACKEND - #1388

Replace LIBKINETO_NO* build flags with KINETO_BACKEND#1388
scotts wants to merge 13 commits into
pytorch:mainfrom
scotts:better_cmake

scotts commented May 4, 2026 •

edited

Loading

Uh oh!

meta-codesync Bot commented May 5, 2026

Uh oh!

NicolasHug May 8, 2026

Uh oh!

scotts May 8, 2026

Uh oh!

scotts commented May 8, 2026

Uh oh!

meta-codesync Bot commented May 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

scotts commented May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

meta-codesync Bot commented May 5, 2026

Uh oh!

NicolasHug May 8, 2026

Choose a reason for hiding this comment

Uh oh!

scotts May 8, 2026

Choose a reason for hiding this comment

Uh oh!

scotts commented May 8, 2026

Uh oh!

meta-codesync Bot commented May 8, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

scotts commented May 4, 2026 •

edited

Loading