[Tobias-Fischer]

Follow-up to #208, as @traversaro suggested there (#208 (comment)): pin every Gazebo vendor, not just the four that drifted.

Which Gazebo each distribution uses, read from the vendor tags in each rosdistro_snapshot.yaml (the LIB_VER_MAJOR in each vendor's CMakeLists.txt):

distro	Gazebo	state
humble	Fortress	libignition-*6, the major is in the name
jazzy	Harmonic	already pinned with versioned names (gz-sim8, gz-transport13, sdformat14, ...)
lyrical	Jetty	4 of 15 pinned by #208, now all
rolling	next Gazebo (prereleases: gz-sim 11, gz-transport 16, sdformat 17)	not on conda-forge, so it builds against Jetty, unpinned until now; now pinned to Jetty like lyrical

Jetty majors: gz-cmake 5, gz-common 7, gz-fuel-tools 11, gz-gui 10, gz-launch 9, gz-math 9, gz-msgs 12, gz-physics 9, gz-plugin 4, gz-rendering 10, gz-sensors 10, libgz-sim 10, gz-tools 2, libgz-transport 15, gz-utils 4, sdformat 16 (also for sdformat_urdf, which has to match sdformat_vendor).

Checks:

• The full Jetty set solves together on osx-arm64 for python 3.12 and 3.14, with libabseil 20260526 (the combination that drifted to Ionic in lyrical: pin the Jetty majors of the gz vendors that drifted to Ionic on osx-arm64 #208).
• rs <distro> check-deps on all 5 platforms for lyrical and rolling: no gz or sdformat conflicts. The conflicts it does report (qt-main, libcamera, opencv, pcl, magic_enum, proxsuite, visp) are already there on main.
• The newest published vendor builds in robostack-lyrical and robostack-rolling are already Jetty on every platform. The pins only change future solves, so no build_number bump and nothing is rebuilt. I labelled this build:none for that reason.

🤖 Generated with Claude Code