| ROS Resources: ROS Homepage | Media and Trademarks | Documentation | ROS Index | How to Get Help | Q&A Help Site | Discussion Forum | Service Status |
Trusty does not provide a Ceres package. Xenial provides one, but it’s broken:
It looks like this may be resolved in Yakkety.
Starting with 1.12, Ceres ships with a package.xml so it can be built from source in a Catkin workspace easily.
However, perhaps ROS should start distributing a working Ceres package?
Damon
There is already a Ceres package available from packages.ros.org. I’m on Trusty, and the packages libceres and libceres-dev have version number 1.8.0. I think it’s this one: https://launchpad.net/~mikeferguson/+archive/ubuntu/ceres-solver . Did you try it? Is it too old?
Right. I was aware of that and since forgot. We don’t use it because it’s too old. We depend upon features introduced in 1.11.
Might be nice to ping Mike to get his PPA updated?
I have a Xenial PPA of 1.11 as well if you’re interested:
https://launchpad.net/~mikepurvis/+archive/ubuntu/ceres
The CMake module is in a separate package, so add the PPA and then:
apt-get install libceres-cmakeI’d suggest that we keep the 1.8 version of ceres for Indigo, and we work to get 1.11 working for Kinetic.
It looks like there’s the cmake fix upstream in Yakkety in the version log http://changelogs.ubuntu.com/changelogs/pool/universe/c/ceres-solver/ceres-solver_1.11.0~dfsg0-5/changelog
Would backporting that version to Xenial and Wily work for peoples’ use cases?
@damonkohler This would solve releasing into Kinetic. I’m hesitant to backport 1.11 all the way into the indigo targets as that’s a large version jump and I’m guessing that it’s not entirely compatible. I think that one of the approaches we talked about offline might be best for releasing into indigo. This would involve embedding a version of ceres into a ROS package in a way that hides the symbols and include directory so they don’t override/conflict with the system installation. (Possibly a static library and header files installed into a custom subdirectory.)
Also I see that 1.12 is now in stretch: https://packages.debian.org/stretch/libceres-dev
An additional aspect of releasing an updated libceres into Indigo is that I’m not entirely sure what packages are dependent on the libceres released into Indigo. I know our robot_calibration package is (and is released to debs), I think SWRI also has a package under ros-industrial, but I don’t think it is released into debs. It seems pretty late in the game to upgrade Indigo to 1.11 (there are at least 10 backwards incompatibility notes for 1.09, 1.10) (as an added difficulty, we no longer have support to build PPAs on Saucy, so we would end up with two different libceres, although AFAIK the saucy deb was not actually building for robot_calibration anyways due to a difference in the underlying packages).
I would be all in favor of pulling a working version of libceres into Kinetic, since it appears that Ubuntu folks have no interest in actually fixing their version of libceres in Xenial. This is currently a blocker for us getting actual robots onto Xenial/Kinetic
Releasing to Kinetic sounds good. We are already considering targeting Kinetic instead of Indigo for our 1.0 release. Thanks!
Would it be an idea to release a version of 1.11 (1.12?) that is namespaced? Something like libceres-1.12, with headers in include/ceres-1.12/ceres and libs accordingly? And add a rosdep key for it (libceres12-dev)?
That would leave the current deb untouched, packages depending on libceres-dev would still get 1.08 (in Trusty at least), but would make it possible to release packages (like the one in ROS-Industrial that @mikeferguson referred to) by explicitly depending on the newer version.
Difficulty would be getting that setup for the other distros that have a libceres-dev key in base.yaml (Fedora, Gentoo).
Sounds like a plan that we’ll backport 1.11 to Wily and Xenial so that we can support releases in Kinetic.
@jrivero would you have time to make those backports?
The other target platforms of Debian is ok, since Stretch has 1.12 already.
We may end up missing Fedora though. I’ll see if Scott or RIch are aware of any targeting of Ceres for Fedora.
Apparently my searching is not up to snuff. Scott replied:
It looks like Rich updated to Ceres 1.11 in Fedora 23, so all current versions of Fedora have already been updated. RHEL 7 is also using version 1.11.
Fedora package: https://admin.fedoraproject.org/pkgdb/package/rpms/ceres-solver/
Fedora updates: Fedora Updates System
So with the Ubuntu backport we’ll be good to go.
@jrivero @tfoote Did this backport ever occur? There doesn’t seem to be anything for Xenial in the main repo:
http://packages.ros.org/ros/ubuntu/pool/main/c/ceres-solver/
I don’t know about the backport, but in the meantime ceres-solver has become a Catkin package (perhaps because Google is using it in cartographer?): ceres-solver.
Oh sorry, I totally miss this warning. @tfoote just remember it to me and we launched our backport job to get the ceres-solver packages into Xenial. The first run was to port the 1.12 version into Xenial altough we can easily try to get the 1.11 version working if that fits better the plan.
I’ve been trying to work on this in the background, but it’s slow going. Xenial worked without patches. I ran into issues targeting the other platforms.
In particular Jessie has libsuitesparse 4.2.1-3 but the yakkety version requires 4.4.3 or higher.
And wily has the same version as jessie.
Mike, thanks for the PPA.
After trying it I found that it is still missing /usr/include/ceres/internal/config.h, as described here: https://bugs.launchpad.net/ubuntu/+source/ceres-solver/+bug/1595692
Seeing as how you are already patching the cmake problem in your PPA, maybe add config.h as well? Or comment on another way to make it work?
Has there been any progress on this one?
Current status of released packages of ceres:
Ubuntu: libceres-dev is now 1.11 on xenial and yakkety 1.12 in zesty and 1.13 artful
Debian: libceres-dev 1.12 on stretch and buster
Fedora: ceres-solver-devel 1.11 on 24 and 25, 1.12 on 26
ROS Lunar: all platforms have a recent enough version.
ROS Kinetic: now that Wily is EOL and Xenial has 1.11, the only blocker is the fact that ceres-solver is not avaiiable on Jessie
Erratum:
Looking a bit more into it it looks like every released version of 1.11 still have problems on Ubuntu (Xenial and Yakkety), either some files are not installed (including the cmake module) or cmake cannot find the ceres headers…
https://bugs.launchpad.net/ubuntu/+source/ceres-solver/+bug/1596296
https://bugs.launchpad.net/ubuntu/+source/ceres-solver/+bug/1678043
Starting with 1.12 the package starts to be close to valid.
On debian Stretch: the package in fine: all the files are installed and you can find package it and link against it without issue
On ubuntu Zesty: They ceres has not been rebuilt after a new build of eigen so cmake fails throwing:
Failed to find Ceres - Found Eigen dependency, but the version of Eigen
found (3.3.2) does not exactly match the version of Eigen Ceres was
compiled with (3.3.0).
Bug report filed here
We now host ceres-solver 1.12.0 debs on packages.ros.org for the following platform/arches:
Debian Stretch has a valid ceres-solver 1.12.0 upstream.
This allows users to release packages in ROS Lunar depending on ceres-solver.
Regarding Kinetic: Debian Jessie still doesn’t have a ceres-solver back-port and contributions in that direction are very welcomed.
This would be great to have. Attempting to backport onto Jessie runs into unresolved dependencies. If someone has time to look into these dependency versions as see which ones can be relaxed to support a backport to Jessie that would be great. But it’s quite possible that the requirements don’t match on Jessie for either 1.11 or 1.12 which would explain why it’s not already bundled.
As an example here’s where the backporting stops when attempting to run for Jessie.
dpkg-deb: building package `ceres-solver-build-deps' in `../ceres-solver-build-deps_1.12.0+dfsg0-1_all.deb'.
The package has been created.
Attention, the package has been created in the current directory,
not in ".." as indicated by the message above!
Selecting previously unselected package ceres-solver-build-deps.
(Reading database ... 24600 files and directories currently installed.)
Preparing to unpack ceres-solver-build-deps_1.12.0+dfsg0-1_all.deb ...
Unpacking ceres-solver-build-deps (1.12.0+dfsg0-1) ...
(Reading database ... 24604 files and directories currently installed.)
Removing ceres-solver-build-deps (1.12.0+dfsg0-1) ...
Done installing deps
Building package
gbp:info: ceres-solver_1.12.0+dfsg0.orig.tar.gz does not exist, creating from 'upstream/1.12.0+dfsg0'
dpkg-buildpackage -rfakeroot -D -us -uc -i -I
dpkg-buildpackage: warning: using a gain-root-command while being root
dpkg-buildpackage: source package ceres-solver
dpkg-buildpackage: source version 1.12.0+dfsg0-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Philipp Huebner <debalance@debian.org>
dpkg-source -i -I --before-build backports
dpkg-buildpackage: host architecture amd64
dpkg-checkbuilddeps: Unmet build dependencies: cmake libatlas-base-dev libgoogle-glog-dev libgflags-dev libeigen3-dev (>= 3.2.1) libsuitesparse-dev (>= 1:4.4.3) python-sphinx python-sphinx-rtd-theme libjs-mathjax
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)
debuild: fatal error at line 1376:
dpkg-buildpackage -rfakeroot -D -us -uc -i -I failed
gbp:error: 'debuild -i -I -uc -us' failed: it exited with 29