Hi all,
It's been a little while since our last discussion about ROS packaging. I know I got bogged down with real life and dropped the ball with respect to the f18 feature process work, but there has been some progress on that front. I've got the four ROS Utilities on the ROS_Packaging[1] wiki page done, and I'm currently working through the 12 ROS Core packages. I've been stashing them on my fedorapeople page [2]. I think we can get at least the core packages for ROS Fuerte done for f18 and then update them all to Groovy once it comes out.
There are a few issues I wanted to discuss: 1) ROS package naming and other packaging guidelines: Right now we're using the name ros-%{rosdistro}-packagename based on Tom's initial packaging efforts. Would it make sense to have a ros macro file that defines things like %{rosdistro} vs declaring it in each package? Additionally, since a lot of the ROS packages that come from github have very similar structure, perhaps we can create a ROS package template, and lay out guidelines for which virtual Provides to add to each package and document where we deviate from the core ROS stacks (for example, i've moved /usr/etc/langs to /etc/ros-langs for the message generation subsystem)
2) Packaging Fuerte vs. waiting for Groovy: Groovy is supposed to have significant changes to filesystem layout to make it more FHS friendly. Based on my work with Fuerte, it's not too hard to beat Fuerte's core packages into FHS compliance, so maybe we can focus on getting the core stacks done for Fuerte and then once Groovy is out we upgrade the core in f18+ and start reviewing additional well-known stacks for groovy.
3) EPEL Should we spend a lot of time targeting el6 (and even el5) as we are packaging? A lot of research institutions seem to be running redhat, though I don't know how many IT departments rely on EPEL vs. the RH supported repos. My inclination is that if it's not too difficult, we should try to at least support el6; el5 might be a bit harder due to the lack of CMake 2.8 in the repositories.
In the meantime, I will submit rosinstall, rosdep, and rospkg for review sometime this week since they're straightforward python packages which are required by the upstream source installation directions (I've already got vcstools reviewed and in Fedora).
Rich
[1] https://fedoraproject.org/wiki/SIGs/Robotics/ROS_Packaging [2] http://rmattes.fedorapeople.org/rospackages/
On 09/17/2012 09:33 AM, Rich Mattes wrote:
In the meantime, I will submit rosinstall, rosdep, and rospkg for review sometime this week since they're straightforward python packages which are required by the upstream source installation directions (I've already got vcstools reviewed and in Fedora).
I agree with all of your points, let me know how I can help. (I got buried with other tasks too, but I kept meaning to get back to working on ROS.)
~tom
== Fedora Project
On Mon, Sep 17, 2012 at 10:00 AM, Tom Callaway tcallawa@redhat.com wrote:
On 09/17/2012 09:33 AM, Rich Mattes wrote:
In the meantime, I will submit rosinstall, rosdep, and rospkg for review sometime this week since they're straightforward python packages which are required by the upstream source installation directions (I've already got vcstools reviewed and in Fedora).
I agree with all of your points, let me know how I can help. (I got buried with other tasks too, but I kept meaning to get back to working on ROS.)
I should stop estimating timeframes for things, real life is way too unpredictible.
I submitted rosdep, rospkg, rosinstall, and ros-release for review. Ankur has handled reviewing rosinstall and rospkg. rosdep and ros-release are still in progress.
My next step is going to be creating a python-catkin package, since it looks like catkin is more or less a standalone python package that doesn't really rely on ROS (just a folder from ros-release.) From there, I'll start fixing up and posting the ros-fuerte packages I am working on at [1].
Once some of the std_msgs and similar pacakges are in, I can patch PCL to build against them and we'll have ended the PCL standalone nightmare by growing a dependency on ROS.
My plan is to stick with Fuerte for f18 and put Groovy in f19 (maybe even as a feature), but we can re-evaluate that as time goes on.
I also have a gazebo package for the latest release (1.2.5), I'll update the review request[2] and submit packages for the new dependencies it's grown since 1.0.1. Unfortunately, Gazebo doesn't seem to render anything properly on my machine using nouveau or nvidia drivers. Still getting to the bottom of that one I'm afraid...there's an upstream bug report[3].
Hopefully I can get some of this done tonight before this hurricane destroys the world...
Rich
[1] http://rmattes.fedorapeople.org/rospackages/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=825409 [3] https://bitbucket.org/osrf/gazebo/issue/143/rendering-issues-blank-world-and...
On 10/29/2012 02:30 PM, Rich Mattes wrote:
I should stop estimating timeframes for things, real life is way too unpredictible.
I submitted rosdep, rospkg, rosinstall, and ros-release for review. Ankur has handled reviewing rosinstall and rospkg. rosdep and ros-release are still in progress.
My next step is going to be creating a python-catkin package, since it looks like catkin is more or less a standalone python package that doesn't really rely on ROS (just a folder from ros-release.) From there, I'll start fixing up and posting the ros-fuerte packages I am working on at [1].
Once some of the std_msgs and similar pacakges are in, I can patch PCL to build against them and we'll have ended the PCL standalone nightmare by growing a dependency on ROS.
My plan is to stick with Fuerte for f18 and put Groovy in f19 (maybe even as a feature), but we can re-evaluate that as time goes on.
I also have a gazebo package for the latest release (1.2.5), I'll update the review request[2] and submit packages for the new dependencies it's grown since 1.0.1. Unfortunately, Gazebo doesn't seem to render anything properly on my machine using nouveau or nvidia drivers. Still getting to the bottom of that one I'm afraid...there's an upstream bug report[3].
Hopefully I can get some of this done tonight before this hurricane destroys the world...
Rich
[1] http://rmattes.fedorapeople.org/rospackages/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=825409 [3] https://bitbucket.org/osrf/gazebo/issue/143/rendering-issues-blank-world-and...
It's been a while, I think it's probably a good time for a status update.
ros-release was recently reviewed, and python-rosdep is still pending (but can move forward now). I've also submitted python-catkin for review, but it still needs some attention as far as rpmlint output is concerned.
I think it's still a good plan to stick with Fuerte in f18 for now. I started to convert some of my fuerte packages to groovy, and a lot of the ROS core infrastructure has changed. It seems like it will be much more work to get groovy's catkin to use FHS paths for instance, I got halfway through the ROS underlay packages before I reached an impasse where catkin wouldn't detect all of the stacks it needed to build a package no matter what I tried. I'm going to focus on fuerte for now, and get back to groovy after the fuerte underlay is ready.
On the whole, I think it would be good to have one "supported" ROS release per Fedora release. This can be Fuerte for fedora <=18, groovy for f19, and maybe hydro for f20 if it's out. For users who want a different ros release, we may be able to provide RPMs that install in /opt via the copr repos once they're ready. It'd be similar to hosting a PPA on ubuntu, and creating specs for installing to /opt is much easier than worrying about the FHS. To allow for inteoperability, with our Fedora "supported" ROS release I was thinking that the Fedora versions of the ROS packages should be named like "ros-packagename", and the ROS distro is determined by whatever's in ros-release. For the copr repositories, the packages/srpms should be named ros-distro-packagename explicitly. This will allow multiple ros distros in /opt, and won't conflict the Fedora packages.
The gazebo rendering issue seems to have fixed itself around version 1.3 or so, which is good. There are still issues with bundled libraries though. It looks like gazebo changes to ode have been going upstream, so I'm hopeful a future release will provide compatibility and let us remove the bundled ode from gazebo.
Rich
On Mon, 2013-02-11 at 18:33 -0500, Rich Mattes wrote:
Rich
Hi Rich,
I'm to work on a project with ROS and therefore will have a lot more cycles to work on it in the coming future. Would you have a list of packages we need to get into fedora. I might just have to work with groovy though, depending on what the project team chooses to use. The project is to do with the PR2 robot. I could work on trying to package groovy and we could maybe host a fedora people repo for this version, while keeping feurte as the official f18 ros release? Would you have any ideas or a dep map that would tell me what order to go about packaging stuff? There seems to be quite a few changes between feurte and groovy and no real documentation on building packages really. I've been looking around all day.
For example, I can't quite understand if we need to package catkin at all, since it looks like a tool that just spews out debs for their repository.
On 03/16/2013 08:54 AM, Ankur Sinha wrote: Hi Ankur,
I'm to work on a project with ROS and therefore will have a lot more cycles to work on it in the coming future. Would you have a list of packages we need to get into fedora. I might just have to work with groovy though, depending on what the project team chooses to use. The project is to do with the PR2 robot. I could work on trying to package groovy and we could maybe host a fedora people repo for this version, while keeping feurte as the official f18 ros release? Would you have any ideas or a dep map that would tell me what order to go about packaging stuff? There seems to be quite a few changes between feurte and groovy and no real documentation on building packages really. I've been looking around all day.
I do have a build order list that I've been using for fuerte: you can find it at [1]. I did set up a copr repository for fuerte[2], it's kind of broken right now but I think I know how to fix it. It contains the ros-underlay packages and installs to /opt/ros/fuerte. The idea is that it can be parallel-installable with the packages in the core distribution in case the packages in your fedora distro aren't the same rosdistro as the one you want. It probably wouldn't be hard to get some ros-groovy packages together in a copr while the ros-fuerte packages get reviewed for mainline.
For example, I can't quite understand if we need to package catkin at all, since it looks like a tool that just spews out debs for their repository.
Catkin contains a bunch of cmake macros that the build systems for the packages seem to rely on. I think it's required for fuerte and higher.
Rich
[1] http://rmattes.fedorapeople.org/ros-fuerte/fuerte-repobuild.txt [2] http://copr-fe.cloud.fedoraproject.org/coprs/detail/rmattes/ros-fuerte/
robotics@lists.fedoraproject.org