Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

re-release gazebo11 to focal using ogre-1.12 #2726

Closed
simonschmeisser opened this issue May 6, 2020 · 5 comments
Closed

re-release gazebo11 to focal using ogre-1.12 #2726

simonschmeisser opened this issue May 6, 2020 · 5 comments

Comments

@simonschmeisser
Copy link

Ubuntu Focal contains a much updated version 1.12.4 of OGRE which can be used by installing/depending on libogre-1.12-dev instead of libogre-1.9-dev. Updating the rosdeps was rejected/postponed because gazebo11 was already released and build against libogre-1.9. See here for the discussion ros/rosdistro#24448

Is there anything I can do to help with a new release? I would like to avoid being stuck on ogre-1.9 from 2013 due to compatibility reasons once ROS Noetic is released ...

@traversaro
Copy link
Collaborator

I guess the first step is to try to compile Gazebo 11 against libogre-1.12-dev . I am compiling and usiing Gazebo 11 on Windows against the ogre1.12 provided by vcpkg, but in the past there were problem on using Gazebo 11 with Ogre 1.12 from conda-forge, see #2700 .

@j-rivero
Copy link
Contributor

j-rivero commented May 6, 2020

Hello Simon:

Is there anything I can do to help with a new release? I would like to avoid being stuck on ogre-1.9 from 2013 due to compatibility reasons once ROS Noetic is released ...

Thanks for all your efforts. I share your idea that would be really nice to update our ancient dependency on ogre-1.9. I'm afraid that the change is really complicated at this precise moment.

I've been in discussing with the rest of Gazebo/Ignition team and with the ROS developer in charge of Noetic and we have some considerations to execute the change at this moment:

  • We have used the REP3 as the guide to know which base dependencies are we using in Noetic. The ogre version until today has been 1.9 (although there has been a foot note I think that the intention was not to change it 3 weeks before releasing). Different projects use that value to prepare releases for Noetic.
  • Although some patches have landed in Gazebo11 for ogre 1.12 we doubt that it can even compile out of the box. That is speaking only about building, changing a core dependency outside of our development and testing cycle, without knowing the potential effects at runtime (note that Silvio provided with an example of rendering problems) we think is not a good idea.
  • Packages have been released for Focal using Ogre 1.9. The potential impact on the API/ABI that changing Ogre version can have in Gazebo makes the change really complicated.

I'm open to help with other options (custom packages using ogre-1.12 in a different repo or with a different name) but the changes and testing that ogre 1.12 would require to go officially into Gazebo11 seems almost impossible to me. Sorry for not bringing good news this time.

@traversaro
Copy link
Collaborator

note that Silvio provided with an example of rendering problems

The one I was referring to ( #2700 ) is probably solved (I guess) but there are indeed other regression related to the current support for Ogre 1.12 in Gazebo 11, in particular #2686 that is not trivial to fix.

@simonschmeisser
Copy link
Author

I'm not trying to push this idea further but just wanted to add that the ogre maintainer is very helpful and quick in responding. I could however not make much sense of those archived issues so I guess if someone where to ask him for help, a more detailed issue would be needed

@j-rivero
Copy link
Contributor

j-rivero commented May 8, 2020

. I could however not make much sense of those archived issues so I guess if someone where to ask him for help, a more detailed issue would be needed

Thanks Simon! I'm happy to see other people working in having upstream versions ready in Debian. Closing this, I hope we can find a solution/agreement in the rest of the issues that are open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants