Skip to content

Bump gz-cmake and others in jetty#2910

Merged
scpeters merged 12 commits into
mainfrom
ci_matching_branch/bump_jetty_gz-sim10
May 22, 2025
Merged

Bump gz-cmake and others in jetty#2910
scpeters merged 12 commits into
mainfrom
ci_matching_branch/bump_jetty_gz-sim10

Conversation

@scpeters

Copy link
Copy Markdown
Member

Bumping gz-cmake and others except gz-tools.

Signed-off-by: Steve Peters <scpeters@openrobotics.org>
scpeters added 2 commits May 18, 2025 03:14
* image_format -> pixel_format
* gps -> navsat

Signed-off-by: Steve Peters <scpeters@openrobotics.org>
This reverts commit 91cf5b8.

Signed-off-by: Steve Peters <scpeters@openrobotics.org>
@scpeters

Copy link
Copy Markdown
Member Author

I noticed some gz-msgs deprecation warnings and tried to naively fix them in 91cf5b8, but that didn't work, so I've reverted it for now

Signed-off-by: Steve Peters <scpeters@openrobotics.org>
@scpeters

Copy link
Copy Markdown
Member Author

I noticed some gz-msgs deprecation warnings and tried to naively fix them in 91cf5b8, but that didn't work, so I've reverted it for now

I've properly fixed the pixel_format warnings in ede686b, but I believe there was a typo in gazebosim/gz-msgs#476, so I opened gazebosim/gz-msgs#515 to fix it.

scpeters added 5 commits May 19, 2025 17:26
Signed-off-by: Steve Peters <scpeters@openrobotics.org>
Signed-off-by: Steve Peters <scpeters@openrobotics.org>
Signed-off-by: Steve Peters <scpeters@openrobotics.org>
Signed-off-by: Steve Peters <scpeters@openrobotics.org>
Signed-off-by: Steve Peters <scpeters@openrobotics.org>
@scpeters

Copy link
Copy Markdown
Member Author

I think the deprecation warnings and python tests are now fixed. I expect the homebrew CI to pass when it finished, but the ModelCommandAPI tests are currently failing on Ubuntu with protobuf errors (though they pass on homebrew)

libprotobuf ERROR google/protobuf/descriptor_database.cc:121] File already exists in database: gz/msgs/time.proto\n[libprotobuf

@j-rivero

Copy link
Copy Markdown
Contributor

libprotobuf ERROR google/protobuf/descriptor_database.cc:121] File already exists in database: gz/msgs/time.proto\n[libprotobuf

I've seen these kind of messages lately in my Gazebo runs but I think that they are not critical. Looking deeper:

83: +--pose requires --model
83: +Run with --help for more information.\n
83: 
83: [  FAILED  ] ModelCommandAPI.NoServerRunning (165 ms)

Seems to a me a message coming from new standalone execs complaining about a lack of a --model flag.

Signed-off-by: Steve Peters <scpeters@openrobotics.org>
@j-rivero

Copy link
Copy Markdown
Contributor

I've seen these kind of messages lately in my Gazebo runs but I think that they are not critical. Looking deeper:

Oh I see that the output of the command is critical for the test.

Following up on the libprotobuf ERROR google/protobuf/descriptor_database.cc:121] File already exists in database:

Lowest level minimal reproducible example I found by now is a simple run of /usr/libexec/gz/msgs12/gz-msgs. Only happens to me with the .deb gz-msgs12 nightlies. Can not reproduce it with the same code version than the nightlies in a colcon workspace. Can not find any big difference between the colcon log and the debbuilder log aside of compiler flags that being injected manually did not change the result. Something related to the nightly libgz-msgs.so.12 is making the error to appear.

@j-rivero

Copy link
Copy Markdown
Contributor

Lowest level minimal reproducible example I found by now is a simple run of /usr/libexec/gz/msgs12/gz-msgs. Only happens to me with the .deb gz-msgs12 nightlies. Can not reproduce it with the same code version than the nightlies in a colcon workspace. Can not find any big difference between the colcon log and the debbuilder log aside of compiler flags that being injected manually did not change the result. Something related to the nightly libgz-msgs.so.12 is making the error to appear.

Ok, I get it. It has to do with the installation at the same time of the nightlies libgz-msgs11-dev and libgz-msgs12-dev. They are probably shipping the same files (since we created 12 during the transition) and something put both set of files in the protobuf knowledge by some-mechanism-vooodo. We just need to check what is still pulling the msgs11 packages into our builds and solve that.

@scpeters

Copy link
Copy Markdown
Member Author

yeah I see that lots of Ionic packages are still being installed by our nightlies somehow

#19 6.254 The following packages will be upgraded:
#19 6.254   gz-msgs11-cli gz-msgs12-cli gz-plugin3-cli gz-tools2 gz-transport15-cli
#19 6.254   libgz-cmake4-dev libgz-common6 libgz-common6-core-dev libgz-common6-events
#19 6.254   libgz-common6-events-dev libgz-common6-geospatial
#19 6.254   libgz-common6-geospatial-dev libgz-common6-graphics
#19 6.254   libgz-common6-graphics-dev libgz-common6-profiler libgz-common6-profiler-dev
#19 6.254   libgz-gui10 libgz-gui10-dev libgz-math8 libgz-math8-dev
#19 6.254   libgz-math8-eigen3-dev libgz-msgs11 libgz-msgs11-dev libgz-msgs12
#19 6.254   libgz-msgs12-dev libgz-physics9 libgz-physics9-bullet
#19 6.254   libgz-physics9-bullet-dev libgz-physics9-core-dev libgz-physics9-dartsim
#19 6.254   libgz-physics9-dartsim-dev libgz-physics9-dev libgz-physics9-heightmap-dev
#19 6.254   libgz-physics9-mesh-dev libgz-physics9-sdf-dev libgz-physics9-tpe
#19 6.254   libgz-physics9-tpe-dev libgz-physics9-tpelib libgz-physics9-tpelib-dev
#19 6.254   libgz-plugin3 libgz-plugin3-dev libgz-rendering9 libgz-rendering9-core-dev
#19 6.254   libgz-rendering9-ogre1 libgz-rendering9-ogre1-dev libgz-rendering9-ogre2
#19 6.254   libgz-rendering9-ogre2-dev libgz-sensors10 libgz-sensors10-air-pressure
#19 6.254   libgz-sensors10-air-pressure-dev libgz-sensors10-air-speed
#19 6.254   libgz-sensors10-air-speed-dev libgz-sensors10-altimeter
#19 6.254   libgz-sensors10-altimeter-dev libgz-sensors10-boundingbox-camera
#19 6.254   libgz-sensors10-boundingbox-camera-dev libgz-sensors10-camera
#19 6.254   libgz-sensors10-camera-dev libgz-sensors10-core-dev
#19 6.254   libgz-sensors10-depth-camera libgz-sensors10-depth-camera-dev
#19 6.254   libgz-sensors10-dev libgz-sensors10-dvl libgz-sensors10-dvl-dev
#19 6.254   libgz-sensors10-force-torque libgz-sensors10-force-torque-dev
#19 6.254   libgz-sensors10-gpu-lidar libgz-sensors10-gpu-lidar-dev libgz-sensors10-imu
#19 6.254   libgz-sensors10-imu-dev libgz-sensors10-lidar libgz-sensors10-lidar-dev
#19 6.254   libgz-sensors10-logical-camera libgz-sensors10-logical-camera-dev
#19 6.254   libgz-sensors10-magnetometer libgz-sensors10-magnetometer-dev
#19 6.254   libgz-sensors10-navsat libgz-sensors10-navsat-dev libgz-sensors10-rendering
#19 6.254   libgz-sensors10-rendering-dev libgz-sensors10-rgbd-camera
#19 6.254   libgz-sensors10-rgbd-camera-dev libgz-sensors10-segmentation-camera
#19 6.254   libgz-sensors10-segmentation-camera-dev libgz-sensors10-thermal-camera
#19 6.254   libgz-sensors10-thermal-camera-dev libgz-sensors10-wide-angle-camera
#19 6.254   libgz-sensors10-wide-angle-camera-dev libgz-tools2-dev libgz-transport15
#19 6.254   libgz-transport15-core-dev libgz-transport15-dev libgz-transport15-log
#19 6.254   libgz-transport15-log-dev libgz-transport15-parameters
#19 6.254   libgz-transport15-parameters-dev libgz-utils3 libgz-utils3-cli-dev
#19 6.254   libgz-utils3-dev libgz-utils3-log libgz-utils3-log-dev libsdformat15
#19 6.255   libsdformat15-dev python3-gz-msgs11 python3-gz-msgs12 python3-gz-transport15
#19 6.255   sdformat15-cli sdformat15-sdf

@scpeters

Copy link
Copy Markdown
Member Author

putting the incorrect dependency versions aside, there is a repeatable test failure in the GitHub workflow:

[ RUN      ] ModelCommandAPI.NoServerRunning
  Running command [/usr/bin/gz model --list ]
  /github/workspace/src/cmd/ModelCommandAPI_TEST.cc:85: Failure
  Expected equality of these values:
    expectedOutput
      Which is: "\nService call to [/gazebo/worlds] timed out\nCommand failed when trying to get the world name of the running simulation.\n"
    output
      Which is: "--pose requires --model\nRun with --help for more information.\n"

the error message is strange because the command executed is gz model --list; neither --pose nor --model were specified. Since it passes on brew with version 2.5.0 of cli11 but fails with version 2.4.1 on 24.04, I'm wondering if it's a cli11 version issue? I'm currently testing with the vendored version of cli11 on Linux to see if that has an effect

@scpeters

Copy link
Copy Markdown
Member Author

I'm currently testing with the vendored version of cli11 on Linux to see if that has an effect

ok, wow I just rebuilt gz-utils with -DGZ_UTILS_VENDOR_CLI11=ON, and I don't see the error message anymore

@scpeters

Copy link
Copy Markdown
Member Author

I'm currently testing with the vendored version of cli11 on Linux to see if that has an effect

ok, wow I just rebuilt gz-utils with -DGZ_UTILS_VENDOR_CLI11=ON, and I don't see the error message anymore

one short-term option is to revert gazebosim/gz-utils#167

@scpeters

Copy link
Copy Markdown
Member Author

I'm currently testing with the vendored version of cli11 on Linux to see if that has an effect

ok, wow I just rebuilt gz-utils with -DGZ_UTILS_VENDOR_CLI11=ON, and I don't see the error message anymore

one short-term option is to revert gazebosim/gz-utils#167

another option is to modify the debian build rules to configure with GZ_UTILS_VENDOR_CLI11=ON, which I have done in gazebo-release/gz-utils4-release#5

for testing purposes, I have built a new nightly with that branch and retriggered Ubuntu CI jobs

@scpeters

Copy link
Copy Markdown
Member Author

another option is to modify the debian build rules to configure with GZ_UTILS_VENDOR_CLI11=ON, which I have done in gazebo-release/gz-utils4-release#5

for testing purposes, I have built a new nightly with that branch and retriggered Ubuntu CI jobs

This fixed the Ubuntu workflows, though the Jenkins job is failing; I suspect that is due to a docker cache issue

Signed-off-by: Jose Luis Rivero <jrivero@honurobotics.com>
@j-rivero

j-rivero commented May 21, 2025

Copy link
Copy Markdown
Contributor

one short-term option is to revert gazebosim/gz-utils#167

I've committed a workaround for the problem of CLI11 in af0f309. I think that would be better than moving other pieces in releasing.

Detailed the problem in #2918

@j-rivero

Copy link
Copy Markdown
Contributor

Running a build using gazebo-tooling/release-tools#1319 in Build Status

@j-rivero

Copy link
Copy Markdown
Contributor

Running a build using gazebo-tooling/release-tools#1319 in Build Status

The failures related to the gz model are gone.

@scpeters scpeters left a comment

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one short-term option is to revert gazebosim/gz-utils#167

I've committed a workaround for the problem of CLI11 in af0f309. I think that would be better than moving other pieces in releasing.

Detailed the problem in #2918

I commented on #2918. Since gz-sim-model has been working with the vendored 1.9.1 and works with 2.5.0, this seems more like a problem with 2.4.2 to me. As I said above, I prefer restoring vendoring in gz-utils as a short-term workaround until we can merge this PR, then open a separate PR to modify gz-sim-model with af0f309. Otherwise that change to gz-sim-model will be buried in this large pull request

Comment thread src/cmd/model_main.cc Outdated
@scpeters

Copy link
Copy Markdown
Member Author

I prefer restoring vendoring in gz-utils as a short-term workaround until we can merge this PR

gazebosim/gz-utils#178

@scpeters

Copy link
Copy Markdown
Member Author

I prefer restoring vendoring in gz-utils as a short-term workaround until we can merge this PR

gazebosim/gz-utils#178

vendoring has been restored, now building a new gz-utils4 nightly deb

@scpeters

Copy link
Copy Markdown
Member Author

@osrf-jenkins run tests please

@scpeters

scpeters commented May 21, 2025

Copy link
Copy Markdown
Member Author

gazebo-tooling/release-tools#1319 is merged, but it didn't seem to fix the Ubuntu jenkins build

https://build.osrfoundation.org/job/gz_sim-ci-pr_any-noble-amd64/765/

@scpeters

Copy link
Copy Markdown
Member Author

gazebo-tooling/release-tools#1319 is merged, but it didn't seem to fix the Ubuntu jenkins build

there seems to be just one CI machine that is failing, so I've restarted the build on a different machine that I think will pass

@iche033 iche033 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me!

@github-project-automation github-project-automation Bot moved this from Inbox to In review in Core development May 22, 2025
@scpeters scpeters merged commit edcbf86 into main May 22, 2025
11 checks passed
@scpeters scpeters deleted the ci_matching_branch/bump_jetty_gz-sim10 branch May 22, 2025 00:35
@github-project-automation github-project-automation Bot moved this from In review to Done in Core development May 22, 2025
@scpeters

Copy link
Copy Markdown
Member Author

building new nightly deb:

@j-rivero

Copy link
Copy Markdown
Contributor

gazebo-tooling/release-tools#1319 is merged, but it didn't seem to fix the Ubuntu jenkins build

https://build.osrfoundation.org/job/gz_sim-ci-pr_any-noble-amd64/765/

Log is:

#19 5.713 0 upgraded, 0 newly installed, 0 to remove and 153 not upgraded.
#19 5.720 Reading package lists...
#19 6.659 Building dependency tree...
#19 6.863 Reading state information...
#19 6.920 Calculating upgrade...
#19 7.228 The following packages were automatically installed and are no longer required:
#19 7.228   gz-msgs11-cli gz-plugin3-cli libgz-common6 libgz-common6-core-dev
#19 7.228   libgz-common6-events libgz-common6-events-dev libgz-common6-geospatial
#19 7.228   libgz-common6-geospatial-dev libgz-common6-graphics
#19 7.228   libgz-common6-graphics-dev libgz-common6-profiler libgz-common6-profiler-dev
#19 7.228   libgz-math8 libgz-math8-dev libgz-math8-eigen3-dev libgz-msgs11
#19 7.228   libgz-msgs11-dev libgz-plugin3 libgz-plugin3-dev libgz-rendering9
#19 7.228   libgz-rendering9-core-dev libgz-rendering9-ogre1 libgz-rendering9-ogre1-dev
#19 7.228   libgz-rendering9-ogre2 libgz-rendering9-ogre2-dev libgz-utils3
#19 7.229   libgz-utils3-cli-dev libgz-utils3-dev libgz-utils3-log libgz-utils3-log-dev
#19 7.229   libsdformat15 libsdformat15-dev python3-gz-msgs11 sdformat15-cli
#19 7.229   sdformat15-sdf
#19 7.229 Use 'apt autoremove' to remove them.

I tried to optimize running the apt-get upgrade command by running first the autoremove but it does seem to find packages to remove until apt-get upgrade is executed. Need to invert the commands gazebo-tooling/release-tools#1320

@scpeters scpeters mentioned this pull request May 23, 2025
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🪵 jetty Gazebo Jetty

Projects

Archived in project

Development

Successfully merging this pull request may close these issues.

4 participants