Pin qt6-main and pyqt6 to 6.11; rebuild packages built against qt6-main 6.12

[Tobias-Fischer]

Summary

• conda-forge released qt6-main 6.12, but its newest pyqt6 (6.11.0) still requires qt6-main <6.12. Rolling only pinned qt6_main to '6', so packages in the current full rebuild picked up 6.12, and anything needing both them and python_qt_binding (→ pyqt6) became unsolvable, e.g. ros2-rqt-topic on linux-aarch64 and osx-arm64.
• Pin qt6_main and pyqt6 to 6.11 in vinca_pinning.yaml (rendered into conda_build_config.yaml with vinca-pinning-render). The render also moves the existing lua: 5.4 into the overrides block (same value) and reshuffles some override comments.
• Bump the build number (29 → 30) of the six packages that robostack-rolling already has for the current mutex (0.22) with a qt6-main >=6.12 dependency, found by scanning the channel's repodata:

Package	Published with qt6-main 6.12 on
gz_gui_vendor	linux-aarch64, osx-arm64
gz_sim_vendor	linux-aarch64, osx-arm64
rqt_plot	linux-aarch64, osx-arm64, win-64
rqt_py_common	linux-aarch64, osx-arm64
rviz_rendering	linux-aarch64, osx-arm64
rviz_rendering_tests	linux-aarch64, osx-arm64

No package is published against 6.12 on linux-64 or osx-64.

• Also fixes testpr.yml to use the prefix.dev channel URLs again (-c https://prefix.dev/conda-forge -c https://prefix.dev/robostack-rolling). The bare -c robostack-rolling resolves to anaconda.org, which has no ros2-* packages, so any PR that doesn't rebuild everything failed with No candidates were found for ros2-ament-cmake. This restores b01f36c, which 8a967e9 accidentally reverted.

Test plan

• pixi run sort --check passes
• Recipes regenerate; exactly these six (plus their ros-rolling-* compatibility packages) get build number 30
• pyqt6=6.11 + qt6-main=6.11 + python=3.14 solve on all five platforms
• check_dependency_compat.py (osx-arm64) reports the same set of unrelated, pre-existing conflicts with and without the Qt pin, so the pin adds none
• Next staged build rebuilds the six packages against qt6-main 6.11, and ros2-rqt-topic solves

Follow-ups (not in this PR)

• The old build-29 files built against 6.12 stay on the channel; build 30 takes precedence, but they could be removed.
• Unpin once conda-forge publishes a pyqt6 built for qt6-main 6.12.

🤖 Generated with Claude Code

[mini-1235]

This seems to be breaking Lyrical's CI as well: https://github.com/RoboStack/ros-lyrical/actions/runs/36726682221. I did some searching, and unfortunately this looks like the only viable option we have :(

• Qt 6.12 LTS was released on 2026-09-30, only yesterday (Qt blog, Phoronix, Qt 6.12 release wiki). That's why qt6-main 6.12 just showed up on conda-forge and our builds split between the two versions.
• PyQt6 6.12: there's nothing yet on Riverbank news (per search) or PyPI. PyQt releases usually follow a new Qt minor release within a few weeks, but that's a pattern, not a commitment.
• conda-forge: the pyqt-feedstock PRs have nothing for 6.12 yet, and qt6-multimedia, qt6-positioning and qt6-serialport are still at 6.11.2.

[traversaro]

Ok for me, ut do you have any idea about the CI failures?

[mini-1235]

Unfortunately I think we need to bump more package's build number:

The pin works for packages being built now; it fails because PR #55's list of rebuilds is incomplete.

Root cause

The PR bumps six packages, which matches what's broken on linux-aarch64 and osx-arm64. The failing job is linux-64, and there a different set of packages was built against 6.12. Here are the _29 packages in robostack-rolling that require qt6-main >=6.12, per platform:

| Platform | Packages requiring qt6-main ≥6.12 | Covered by PR? |
|---|---|---|
| linux-64 | rviz2, rviz_default_plugins, rviz_imu_plugin, rviz_satellite, rviz_visual_testing_framework | ❌ none |
| linux-aarch64 | gz_gui_vendor, gz_sim_vendor, rqt_plot, rqt_py_common, rviz_rendering, rviz_rendering_tests | ✅ |
| osx-arm64 | same as linux-aarch64 | ✅ |
| win-64 | rqt_plot, rviz_common, rviz_default_plugins, rviz_imu_plugin, rviz_visual_testing_framework, rviz2, turtlesim | partly (only rqt_plot) |
| osx-64 | none | – |

The failure itself: pilz_industrial_motion_planner needs rviz2 (channel copy needs qt6-main ≥6.12) alongside joint_state_publisher_gui → python_qt_binding → pyqt6 6.11 (needs qt6-main <6.12). These can't be installed together.

Proposed fix

Add build_number: 30 for the union across platforms. That means these seven, on top of the six already in the PR:

• rviz2
• rviz_common
• rviz_default_plugins
• rviz_imu_plugin
• rviz_satellite
• rviz_visual_testing_framework
• turtlesim

build_number applies to every platform, so some packages get rebuilt where they didn't strictly need it. That's harmless and simpler than per-platform handling.

[mini-1235]

I will also do a manual backport for ros-lyrical.

I wonder if there is a way to prevent something like this from happening in the future. For example, if we are doing a full rebuild and the Qt6 version gets updated in the meantime, it seems possible that some packages could be built against the old version while others are built against the new one

[traversaro]

I will also do a manual backport for ros-lyrical.

I wonder if there is a way to prevent something like this from happening in the future. For example, if we are doing a full rebuild and the Qt6 version gets updated in the meantime, it seems possible that some packages could be built against the old version while others are built against the new one

The regular pinning mechanism should help on this. Qt is a bit strange for several reasons, see conda-forge/conda-forge-pinning-feedstock#8746 . In theory, I think pyqt6.11 should work fine with pyqt6.12 , but probably there are some leftover with the strict pinning of qt6 . For the time being, just overridng qt6 pinning to 6.11 in our vinca_pinning.yaml is a sensible strategy.