Just as an FYI, I'm in the process of attempting to package up the ROS Fuerte stack in a way that I hope could be acceptable for inclusion in Fedora, and making some reasonable progress.
I'll probably end up needing a lot of reviews if/when I am successful. At the moment, I'm running into an issue where the ROS component "perception_pcl" depends on a forked version of PCL that ROS only makes available in a binary Ubuntu dpkg. I have opened a bug with ROS asking for the corresponding source code, but so far, they haven't responded. (If anyone knows where I can find that magic ROS PCL source code fork, please let me know.)
~tom
== Fedora Project
On Tue, May 29, 2012 at 9:54 AM, Tom Callaway tcallawa@redhat.com wrote:
Just as an FYI, I'm in the process of attempting to package up the ROS Fuerte stack in a way that I hope could be acceptable for inclusion in Fedora, and making some reasonable progress.
I'll probably end up needing a lot of reviews if/when I am successful. At the moment, I'm running into an issue where the ROS component "perception_pcl" depends on a forked version of PCL that ROS only makes available in a binary Ubuntu dpkg. I have opened a bug with ROS asking for the corresponding source code, but so far, they haven't responded. (If anyone knows where I can find that magic ROS PCL source code fork, please let me know.)
~tom
Hi Tom,
That's great to hear! Before you get too far, I've already started by packaging some of the helper utilities[1]. I think they're about ready to post for review, which I can do tonight if you don't see any issues. If you would like to coordinate efforts, we also have a wiki page[2] started to track progress, we can convert it into a table with package names, versions, packaging status, and review status, then we can branch out and get all the specfiles written.
It looks like the version of PCL that fuerte is including is marked as 1.5.2[2]. Given the date in the package name, it looks like they probably took an svn snapshot[3] on that date and bumped the version from the latest release(1.5.1). I agree it would be nice if they posted source packages with the binary packages in their ubuntu repositories.
Are you having trouble getting things to build with the PCL packages we have in Fedora right now?
Rich
[1] http://rmattes.fedorapeople.org/rospackages/ [2] http://fedoraproject.org/wiki/SIGs/Robotics/ROS_Packaging [3] http://packages.ros.org/ros/ubuntu/pool/main/r/ros-fuerte-pcl/ [4] http://dev.pointclouds.org/projects/pcl/repository
On 05/29/2012 11:12 AM, Rich Mattes wrote:
That's great to hear! Before you get too far, I've already started by packaging some of the helper utilities[1]. I think they're about ready to post for review, which I can do tonight if you don't see any issues. If you would like to coordinate efforts, we also have a wiki page[2] started to track progress, we can convert it into a table with package names, versions, packaging status, and review status, then we can branch out and get all the specfiles written.
Cool. Here's what I have packaged right now, we should definitely be on the same page with any overlap.
catkin-0.3.29-1.fc17.noarch ros-fuerte-actionlib-1.8.4-1.fc17.x86_64 ros-fuerte-base-1.8.7-1.fc17.x86_64 ros-fuerte-bond-core-1.6.3-1.fc17.x86_64 ros-fuerte-bullet-2.79-1.fc17.x86_64 ros-fuerte-common-msgs-1.8.5-1.fc17.x86_64 ros-fuerte-dynamic-reconfigure-1.4.0-1.fc17.x86_64 ros-fuerte-filters-1.6.0-1.fc17.x86_64 ros-fuerte-gencpp-0.3.0-1.fc17.x86_64 ros-fuerte-genlisp-0.3.0-1.fc17.x86_64 ros-fuerte-genmsg-0.3.5-1.fc17.x86_64 ros-fuerte-genpy-0.3.3-1.fc17.x86_64 ros-fuerte-geometry-1.8.0-1.fc17.x86_64 ros-fuerte-image-common-1.8.0-1.fc17.x86_64 ros-fuerte-nodelet-core-1.6.5-1.fc17.x86_64 ros-fuerte-orocos-kinematics-dynamics-0.2.3-1.fc17.x86_64 ros-fuerte-pluginlib-1.8.0-2.fc17.x86_64 ros-fuerte-ros-1.8.7-1.fc17.x86_64 ros-fuerte-ros-comm-1.8.9-1.fc17.x86_64 ros-fuerte-roscpp-core-0.2.3-1.fc17.x86_64 ros-fuerte-rospack-2.0.12-1.fc17.x86_64 ros-fuerte-std-msgs-0.4.6-1.fc17.x86_64
Are your helper utilities still relevant in the fuerte universe? I'm still wrapping my head around it. I know catkin is needed, but I seem to recall that the others may be obsolete.
It looks like the version of PCL that fuerte is including is marked as 1.5.2[2]. Given the date in the package name, it looks like they probably took an svn snapshot[3] on that date and bumped the version from the latest release(1.5.1). I agree it would be nice if they posted source packages with the binary packages in their ubuntu repositories.
Are you having trouble getting things to build with the PCL packages we have in Fedora right now?
Yes, sadly. It seems like the default PCL headers in 1.5.1 conflict with the ROS headers in some pretty nasty ways. You should be able to reproduce this pretty easily by just trying to build perception_pcl (if you need my package set to resolve deps, I can toss them up somewhere).
Haven't tried PCL trunk yet, but I will do so shortly.
~tom
== Fedora Project
On Tue, May 29, 2012 at 11:33 AM, Tom Callaway tcallawa@redhat.com wrote:
Cool. Here's what I have packaged right now, we should definitely be on the same page with any overlap.
catkin-0.3.29-1.fc17.noarch ros-fuerte-actionlib-1.8.4-1.fc17.x86_64 ros-fuerte-base-1.8.7-1.fc17.x86_64 ros-fuerte-bond-core-1.6.3-1.fc17.x86_64 ros-fuerte-bullet-2.79-1.fc17.x86_64 ros-fuerte-common-msgs-1.8.5-1.fc17.x86_64 ros-fuerte-dynamic-reconfigure-1.4.0-1.fc17.x86_64 ros-fuerte-filters-1.6.0-1.fc17.x86_64 ros-fuerte-gencpp-0.3.0-1.fc17.x86_64 ros-fuerte-genlisp-0.3.0-1.fc17.x86_64 ros-fuerte-genmsg-0.3.5-1.fc17.x86_64 ros-fuerte-genpy-0.3.3-1.fc17.x86_64 ros-fuerte-geometry-1.8.0-1.fc17.x86_64 ros-fuerte-image-common-1.8.0-1.fc17.x86_64 ros-fuerte-nodelet-core-1.6.5-1.fc17.x86_64 ros-fuerte-orocos-kinematics-dynamics-0.2.3-1.fc17.x86_64 ros-fuerte-pluginlib-1.8.0-2.fc17.x86_64 ros-fuerte-ros-1.8.7-1.fc17.x86_64 ros-fuerte-ros-comm-1.8.9-1.fc17.x86_64 ros-fuerte-roscpp-core-0.2.3-1.fc17.x86_64 ros-fuerte-rospack-2.0.12-1.fc17.x86_64 ros-fuerte-std-msgs-0.4.6-1.fc17.x86_64
Great! Are you just making copies of their ubuntu packages at the moment?
Are you shooting to replace packages like "fuerte-bullet" with distro versions of packages at some point? Using fuerte in all the package names will also force a mass re-review each time another release is done, unless these are just targeted for a fedorapeople repo.
Are your helper utilities still relevant in the fuerte universe? I'm still wrapping my head around it. I know catkin is needed, but I seem to recall that the others may be obsolete.
The official install instructions[1] still use them, and they still may be helpful for package generation and for developing or downloading and building third-party stacks that aren't packaged in Fedora. I think that the rospkg package might overlap with your ros-fuerte-rospack for instance.
Yes, sadly. It seems like the default PCL headers in 1.5.1 conflict with the ROS headers in some pretty nasty ways. You should be able to reproduce this pretty easily by just trying to build perception_pcl (if you need my package set to resolve deps, I can toss them up somewhere).
It would be great if you tossed them up on fedorapeople as you go, I'd be interested in helping you test and debug them in my spare time.
Haven't tried PCL trunk yet, but I will do so shortly.
If it works, we can probably update our package to an SVN snapshot.
Rich
On 05/29/2012 12:16 PM, Rich Mattes wrote:
Great! Are you just making copies of their ubuntu packages at the moment? Are you shooting to replace packages like "fuerte-bullet" with distro versions of packages at some point? Using fuerte in all the package names will also force a mass re-review each time another release is done, unless these are just targeted for a fedorapeople repo.
These are distro versions built from source. I'm trying to be a bit sneaky/clever here. Let's take ros-fuerte-image-common as an example. The spec file is named "ros-image-common.spec", and this is what the beginning looks like:
%global codename fuerte %global shortname image_common
Name: ros-%{codename}-image-common Version: 1.8.0 Release: 1%{?dist} Summary: Common ROS code for working with images
Thus, the Fedora git component name is "ros-image-common", and as upstream bumps to "ginormous", we just change the value for codename and rebuild. rpmlint notes that the .spec file name doesn't match the SRPM, but this method is a lot simpler in the long run and it better matches the experience that the upstream is providing on Ubuntu.
The official install instructions[1] still use them, and they still may be helpful for package generation and for developing or downloading and building third-party stacks that aren't packaged in Fedora. I think that the rospkg package might overlap with your ros-fuerte-rospack for instance.
We should check that, but I don't think so.
It would be great if you tossed them up on fedorapeople as you go, I'd be interested in helping you test and debug them in my spare time.
Okay. I'll upload them and post again when they're up.
Haven't tried PCL trunk yet, but I will do so shortly.If it works, we can probably update our package to an SVN snapshot.
I think we're going to need to do more than that. Is Tim (the PCL maintainer) on this list? I still haven't found a working combination yet.
~tom
== Fedora Project
On 05/29/2012 12:23 PM, Tom Callaway wrote:
These are distro versions built from source. I'm trying to be a bit sneaky/clever here. Let's take ros-fuerte-image-common as an example. The spec file is named "ros-image-common.spec", and this is what the beginning looks like:
%global codename fuerte %global shortname image_common
Name: ros-%{codename}-image-common Version: 1.8.0 Release: 1%{?dist} Summary: Common ROS code for working with images
Thus, the Fedora git component name is "ros-image-common", and as upstream bumps to "ginormous", we just change the value for codename and rebuild. rpmlint notes that the .spec file name doesn't match the SRPM, but this method is a lot simpler in the long run and it better matches the experience that the upstream is providing on Ubuntu.
That's an interesting approach, it should help keep things more consistent across distributions. Are the packages also doing a Provides: without the codename, so rpm can handle upgrades properly?
We should check that, but I don't think so.
You're right, rospkg only provides /usr/bin/rosversion and a rospkg python egg.
Okay. I'll upload them and post again when they're up.
Great! Looking forward to it.
I think we're going to need to do more than that. Is Tim (the PCL maintainer) on this list? I still haven't found a working combination yet.
Tim is indeed on this list, I've CC'd him on this message in case he has missed this thread.
~tom
== Fedora Project
On 05/29/2012 06:34 PM, Rich Mattes wrote:
That's an interesting approach, it should help keep things more consistent across distributions. Are the packages also doing a Provides: without the codename, so rpm can handle upgrades properly?
They are, but the Requires have the %{codename} macro in them (where appropriate), because we'll want people to not update half of a ros deployment.
We should check that, but I don't think so.
You're right, rospkg only provides /usr/bin/rosversion and a rospkg python egg.
Okay. I'll upload them and post again when they're up.
Great! Looking forward to it.
http://spot.fedorapeople.org/ros/
I think we're going to need to do more than that. Is Tim (the PCL maintainer) on this list? I still haven't found a working combination yet.
Tim is indeed on this list, I've CC'd him on this message in case he has missed this thread.
I didn't get as much time as I'd have liked to try PCL today. I did pull the source from trunk and make a test package with it, the results are as follows:
A normal build of PCL from trunk has the same ROS perception_pcl compilation issues as the stock 1.5.1 build of PCL. When I built PCL from trunk with -DUSE_ROS=ON, it has the same issues as when I do the -DUSE_ROS=ON build of PCL 1.5.1 (specifically, it can't find headers).
The Ubuntu dpkg has custom ROS headers which replace the missing PCL headers, but I'm reluctant to just chunk them in place, because I don't know if there is other non-header ROS specific codechanges that I'd need. Tim, do you know how to build the magic "ROS" PCL? :)
~tom
== Fedora Project
On 05/29/2012 11:00 PM, Tom Callaway wrote:
On 05/29/2012 06:34 PM, Rich Mattes wrote: They are, but the Requires have the %{codename} macro in them (where appropriate), because we'll want people to not update half of a ros deployment.
That's true. I guess locking dependencies to rosdistro name is a lot easier than doing package versions.
Great!
I didn't get as much time as I'd have liked to try PCL today. I did pull the source from trunk and make a test package with it, the results are as follows:
A normal build of PCL from trunk has the same ROS perception_pcl compilation issues as the stock 1.5.1 build of PCL. When I built PCL from trunk with -DUSE_ROS=ON, it has the same issues as when I do the -DUSE_ROS=ON build of PCL 1.5.1 (specifically, it can't find headers).
The Ubuntu dpkg has custom ROS headers which replace the missing PCL headers, but I'm reluctant to just chunk them in place, because I don't know if there is other non-header ROS specific codechanges that I'd need. Tim, do you know how to build the magic "ROS" PCL? :)
I believe I found the repository for the "ROS" pcl:
https://github.com/wg-debs/pcl
This tree includes the ModelCoefficients and friends that are missing from upstream pcl.
Rich
/*Rich Mattes richmattes@gmail.com*/ wrote on Tue, 29 May 2012 23:47:19 -0400:
On 05/29/2012 11:00 PM, Tom Callaway wrote:
On 05/29/2012 06:34 PM, Rich Mattes wrote: They are, but the Requires have the %{codename} macro in them (where appropriate), because we'll want people to not update half of a ros deployment.
That's true. I guess locking dependencies to rosdistro name is a lot easier than doing package versions.
Sorry to just jump in the discussion, but if we keep this naming scheme we will need to review all ROS packages when a new release (with a new codename) is available. Isn't it better to move codename to the release tag and use version dependent Requires to prevent half deployment updates?
Regards, Hedayat
Great!
I didn't get as much time as I'd have liked to try PCL today. I did pull the source from trunk and make a test package with it, the results are as follows:
A normal build of PCL from trunk has the same ROS perception_pcl compilation issues as the stock 1.5.1 build of PCL. When I built PCL from trunk with -DUSE_ROS=ON, it has the same issues as when I do the -DUSE_ROS=ON build of PCL 1.5.1 (specifically, it can't find headers).
The Ubuntu dpkg has custom ROS headers which replace the missing PCL headers, but I'm reluctant to just chunk them in place, because I don't know if there is other non-header ROS specific codechanges that I'd need. Tim, do you know how to build the magic "ROS" PCL? :)
I believe I found the repository for the "ROS" pcl:
https://github.com/wg-debs/pcl
This tree includes the ModelCoefficients and friends that are missing from upstream pcl.
Rich
robotics mailing list robotics@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/robotics
On 05/29/2012 11:47 PM, Rich Mattes wrote:
I believe I found the repository for the "ROS" pcl:
https://github.com/wg-debs/pcl
This tree includes the ModelCoefficients and friends that are missing from upstream pcl.
This looks promising! I'm going to have to rename the namespacing for this package (and patch all dependent ROS bits to use it) to avoid conflicting with the "normal" pcl, but at least it should get me moving again.
~tom
== Fedora Project
On Wed, May 30, 2012 at 11:13 AM, Tom Callaway tcallawa@redhat.com wrote:
This looks promising! I'm going to have to rename the namespacing for this package (and patch all dependent ROS bits to use it) to avoid conflicting with the "normal" pcl, but at least it should get me moving again.
Is the goal to eventually get ros to play nice with system-wide libraries and apps? We already have a lot of ros dependencies packaged or on the way (bullet, pcl, ompl, openni, gazebo, etc). The motivations section of REP 122[1] indicates that upstream is interested in building ROS against standalone versions of system libraries, we may want to keep an eye on that as ros packages are submitted for review.
Rich
On 05/30/2012 02:07 PM, Rich Mattes wrote:
On Wed, May 30, 2012 at 11:13 AM, Tom Callaway <tcallawa@redhat.com mailto:tcallawa@redhat.com> wrote:
This looks promising! I'm going to have to rename the namespacing for this package (and patch all dependent ROS bits to use it) to avoid conflicting with the "normal" pcl, but at least it should get me moving again.Is the goal to eventually get ros to play nice with system-wide libraries and apps? We already have a lot of ros dependencies packaged or on the way (bullet, pcl, ompl, openni, gazebo, etc). The motivations section of REP 122[1] indicates that upstream is interested in building ROS against standalone versions of system libraries, we may want to keep an eye on that as ros packages are submitted for review.
Yes. Wherever possible, I'm using system libraries (e.g. in my ros-bullet package that is basically just a ROS wrapper for the existing bullet bits). PCL just wouldn't work because they're dependent upon a forked version of PCL. I'm not sure _why_ that is, since Willow Garage is upstream for both PCL and ROS.
~tom
== Fedora Project
I'm making progress again now that I have the ROS fork of PCL packaged up. My initial pass is to build all the deps necessary for the NXT stack (as that is my first test platform).
I'm hanging out in #fedora-robotics if you want to talk about stuff there. :)
~tom
== Fedora Project
On 06/01/2012 01:28 PM, Tom Callaway wrote:
I'm making progress again now that I have the ROS fork of PCL packaged up. My initial pass is to build all the deps necessary for the NXT stack (as that is my first test platform).
I'm hanging out in #fedora-robotics if you want to talk about stuff there. :)
~tom
I've been playing with packaging stacks based off of your example, and I got three more or less done. I've edited the wiki with which packages are completed and posted thus far[1], we can add stacks to it as we go so we don't duplicate effort.
Rich
[1] https://fedoraproject.org/wiki/SIGs/Robotics/ROS_Packaging
On 06/02/2012 12:24 AM, Rich Mattes wrote:
On 06/01/2012 01:28 PM, Tom Callaway wrote:
I'm making progress again now that I have the ROS fork of PCL packaged up. My initial pass is to build all the deps necessary for the NXT stack (as that is my first test platform).
I'm hanging out in #fedora-robotics if you want to talk about stuff there. :)
~tom
I've been playing with packaging stacks based off of your example, and I got three more or less done. I've edited the wiki with which packages are completed and posted thus far[1], we can add stacks to it as we go so we don't duplicate effort.
Rich
[1] https://fedoraproject.org/wiki/SIGs/Robotics/ROS_Packaging
I've been following up with a few of the problem stacks over the past week or so. It looks like the next release of PCL will have the bits that the wg-pcl repository includes and the main source distribution doesn't[1]. According to the gazebo mailing list, the next release of gazebo should follow suit and the ROS stack should depend on the source distribution of gazebo and not a special patched version that is only available from rosinstall or the wg ubuntu repositories[2].
ROS groovy is due out around October[3], which is after the f18 feature freeze, but I think we should make ROS an f18 feature and shoot for getting fuerte included for the f18 release. I'm willing to handle the feature page and contribute to package submission, patching, and reviewing this summer if everyone thinks this is a workable goal.
Rich
[1] http://dev.pointclouds.org/issues/699 [2] http://kforge.ros.org/pipermail/gazebo-list/2012-June/004011.html [3] http://www.ros.org/wiki/groovy/Planning
On 06/07/2012 11:11 PM, Rich Mattes wrote:
On 06/02/2012 12:24 AM, Rich Mattes wrote:
On 06/01/2012 01:28 PM, Tom Callaway wrote:
I'm making progress again now that I have the ROS fork of PCL packaged up. My initial pass is to build all the deps necessary for the NXT stack (as that is my first test platform).
I'm hanging out in #fedora-robotics if you want to talk about stuff there. :)
~tom
I've been playing with packaging stacks based off of your example, and I got three more or less done. I've edited the wiki with which packages are completed and posted thus far[1], we can add stacks to it as we go so we don't duplicate effort.
Rich
[1] https://fedoraproject.org/wiki/SIGs/Robotics/ROS_Packaging
I've been following up with a few of the problem stacks over the past week or so. It looks like the next release of PCL will have the bits that the wg-pcl repository includes and the main source distribution doesn't[1]. According to the gazebo mailing list, the next release of gazebo should follow suit and the ROS stack should depend on the source distribution of gazebo and not a special patched version that is only available from rosinstall or the wg ubuntu repositories[2].
Great news! I saw the PCL emails, thank you so much for doing that. Will we still need to build two versions of PCL once this happens (admittedly, we could do this from within the same source package, I suppose), or will the Fedora system PCL be built against ROS?
ROS groovy is due out around October[3], which is after the f18 feature freeze, but I think we should make ROS an f18 feature and shoot for getting fuerte included for the f18 release. I'm willing to handle the feature page and contribute to package submission, patching, and reviewing this summer if everyone thinks this is a workable goal.
Sure. I'm committed to this as well. I've gotten some more stacks working since last I checked in.
So far, the biggest block has been the fact that rviz uses a Ogre module that Fedora doesn't have (because that module depends on NVIDIA's non-free cg toolkit). I patched out the place where rviz uses the module, and things _seem_ to work fine without it, but I'm not really sure how rviz works so I can't be sure.
Aside from that, I finished all the deps needed for the nxt stack, then patched up the nxt stack to actually work against fuerte. Right now, I'm out at Southeast Linux Fest on an internet connection that is not much more than wet string and tin cans, but next week, I'll upload my current ROS packages.
Thanks,
~tom
== Fedora Project
On Sat, Jun 9, 2012 at 7:20 AM, Tom Callaway tcallawa@redhat.com wrote:
On 06/07/2012 11:11 PM, Rich Mattes wrote:
I've been following up with a few of the problem stacks over the past week or so. It looks like the next release of PCL will have the bits that the wg-pcl repository includes and the main source distribution doesn't[1]. According to the gazebo mailing list, the next release of gazebo should follow suit and the ROS stack should depend on the source distribution of gazebo and not a special patched version that is only available from rosinstall or the wg ubuntu repositories[2].
Great news! I saw the PCL emails, thank you so much for doing that. Will we still need to build two versions of PCL once this happens (admittedly, we could do this from within the same source package, I suppose), or will the Fedora system PCL be built against ROS?
No problem. I think we will be able to patch PCL with the missing pieces
once we want to build against ROS. I made a diff last week, I think the changes are only a few header files and some extra ROS-specific files (manifest, message definitions, etc.) If PCL-1.6 comes out with the fixes before then, we'll be able to get those into f18
ROS groovy is due out around October[3], which is after the f18 feature freeze, but I think we should make ROS an f18 feature and shoot for getting fuerte included for the f18 release. I'm willing to handle the feature page and contribute to package submission, patching, and reviewing this summer if everyone thinks this is a workable goal.
Sure. I'm committed to this as well. I've gotten some more stacks working since last I checked in.
Great! I will get the feature page started this week
So far, the biggest block has been the fact that rviz uses a Ogre module that Fedora doesn't have (because that module depends on NVIDIA's non-free cg toolkit). I patched out the place where rviz uses the module, and things _seem_ to work fine without it, but I'm not really sure how rviz works so I can't be sure.
Gazebo has the same issue. OGRE complains when it can't find the plugin, but things seem to keep running (I can't tell if they're working or not, as gazebo has some graphics issues on fedora.) I can ping on them and ask if/how they're using it, and whether or not we can get away with it.
Aside from that, I finished all the deps needed for the nxt stack, then patched up the nxt stack to actually work against fuerte. Right now, I'm out at Southeast Linux Fest on an internet connection that is not much more than wet string and tin cans, but next week, I'll upload my current ROS packages.
Alright great. I did run across a couple of little issues we should look at while playing with the current ros packages:
* The build underlay we check out with rosinstall seems to change every so often. I checked it out on june 6, and it had been updated since you made the first package. We should figure out a way to monitor these changes.
* Some of the stacks are installing themselves under /usr/share. Programs like rosstack and rosmsg will find the messages and stacks when /usr/share is on the ROS_PACKAGE_PATH, but I'm not sure if letting them traverse the whole /usr/share tree as the ROS_PACKAGE_PATH is a great idea. I think we could maybe install everything in /usr/share/ros-fuerte instead of /usr/share, and set the ROS_PACKAGE_PATH to that path out of the box. But then we run into issues when packages like PCL install themselves to /usr/share and identify themselves as stacks, so maybe we just live with it.
* Are all of the symlinks to /usr/bin/* and /usr/lib{,64}/* ok? Do we need them since PATH and ld already know where to find things? I went over the guidelines and didn't see anything that said they weren't, but boy does it seem clumsy.
I think we're making good progress, I'll try to reach out to the ROS community and let them know what we're up to and if they have any advice/feedback.
Rich
On 06/11/2012 09:00 AM, Rich Mattes wrote:
- The build underlay we check out with rosinstall seems to change every
so often. I checked it out on june 6, and it had been updated since you made the first package. We should figure out a way to monitor these changes.
*sigh* Okay. Maybe we can ask the ROS community to stop doing that, or at the very least, to consider releasing versioned source tarballs for the build underlay? (e.g. fuerte-base-underlay-src-3.tar.gz).
- Some of the stacks are installing themselves under /usr/share.
Programs like rosstack and rosmsg will find the messages and stacks when /usr/share is on the ROS_PACKAGE_PATH, but I'm not sure if letting them traverse the whole /usr/share tree as the ROS_PACKAGE_PATH is a great idea. I think we could maybe install everything in /usr/share/ros-fuerte instead of /usr/share, and set the ROS_PACKAGE_PATH to that path out of the box. But then we run into issues when packages like PCL install themselves to /usr/share and identify themselves as stacks, so maybe we just live with it.
Yeah. I thought about this too, but it seems to be something we can live with.
- Are all of the symlinks to /usr/bin/* and /usr/lib{,64}/* ok? Do we
need them since PATH and ld already know where to find things? I went over the guidelines and didn't see anything that said they weren't, but boy does it seem clumsy.
Well, I wasn't sure. I do know that a lot of the ROS tooling calls binaries on the assumption that they're in the stack dir, so I don't think we can drop those symlinks, and I wasn't sure initially if some of the libs were being dlopened at any point, so I just kept making those symlinks. I'm also trying to comply with the letter of the FHS on those items.
It's clumsy, but that's because the ROS stack model is so... clumsy. I'm still not thrilled that the shared libraries aren't versioned.
I think we're making good progress, I'll try to reach out to the ROS community and let them know what we're up to and if they have any advice/feedback.
Hopefully you will have better luck reaching them than I did before. :)
~tom
== Fedora Project
On 06/11/2012 09:29 AM, Tom Callaway wrote:
On 06/11/2012 09:00 AM, Rich Mattes wrote:
- The build underlay we check out with rosinstall seems to change every
so often. I checked it out on june 6, and it had been updated since you made the first package. We should figure out a way to monitor these changes.
*sigh* Okay. Maybe we can ask the ROS community to stop doing that, or at the very least, to consider releasing versioned source tarballs for the build underlay? (e.g. fuerte-base-underlay-src-3.tar.gz).
It looks like rosinstall is pulling all of the stacks directly from their corresponding *-release repositories at [1]. So they can more or less be updated at any time it seems.
- Some of the stacks are installing themselves under /usr/share. Programs like rosstack and rosmsg will find the messages and stacks
when /usr/share is on the ROS_PACKAGE_PATH, but I'm not sure if letting them traverse the whole /usr/share tree as the ROS_PACKAGE_PATH is a great idea. I think we could maybe install everything in /usr/share/ros-fuerte instead of /usr/share, and set the ROS_PACKAGE_PATH to that path out of the box. But then we run into issues when packages like PCL install themselves to /usr/share and identify themselves as stacks, so maybe we just live with it.
Yeah. I thought about this too, but it seems to be something we can live with.
Yeah the more I think about it the more I lean towards using /usr/share and dealing with it as well. It doesn't seem to be slowing things down all that much.
- Are all of the symlinks to /usr/bin/* and /usr/lib{,64}/* ok? Do we
need them since PATH and ld already know where to find things? I went over the guidelines and didn't see anything that said they weren't, but boy does it seem clumsy.
Well, I wasn't sure. I do know that a lot of the ROS tooling calls binaries on the assumption that they're in the stack dir, so I don't think we can drop those symlinks, and I wasn't sure initially if some of the libs were being dlopened at any point, so I just kept making those symlinks. I'm also trying to comply with the letter of the FHS on those items.
It's clumsy, but that's because the ROS stack model is so... clumsy. I'm still not thrilled that the shared libraries aren't versioned.
REP 122 seems to indicate that this will be changing in the future, so maybe the ugliness of the stacks/ directory is only a temporary woe.
I think we're making good progress, I'll try to reach out to the ROS community and let them know what we're up to and if they have any advice/feedback.
Hopefully you will have better luck reaching them than I did before. :)
I sent a message with a bunch of questions off to the ros-users list[3], I'm hoping to get some feedback on some of these questions.
Rich
[1] https://github.com/wg-debs/ [2] http://ros.org/reps/rep-0122.html [3] http://code.ros.org/lurker/message/20120616.014609.b2d729f5.en.html
On 06/15/2012 09:53 PM, Rich Mattes wrote:
I think we're making good progress, I'll try to reach out to the ROS community and let them know what we're up to and if they have any advice/feedback.
Hopefully you will have better luck reaching them than I did before. :)
I sent a message with a bunch of questions off to the ros-users list[3], I'm hoping to get some feedback on some of these questions.
Just following up: I've managed to start a couple of discussions in the ROS community. One about the general packaging effort at: https://groups.google.com/forum/?fromgroups#!topic/ros-sig-buildsystem/ey-br...
and another about PCL and ROS integration at: http://code.ros.org/lurker/message/20120616.020117.92c8a898.en.html
Feel free to chime in, I'm going to be on vacation for the next couple of days and probably won't be checking in much til the weekend.
Rich
Is there a catkin-ros SRPM somewhere as well?
mock -v rebuild ros-fuerte-ros-1.8.7-1.fc17.src.rpm ... Getting requirements for ros-fuerte-ros-1.8.7-1.el6.src Error: No Package found for catkin-ros
Thanks
Simon
On 05/30/2012 04:16 AM, Simon Thompson wrote:
Is there a catkin-ros SRPM somewhere as well?
mock -v rebuild ros-fuerte-ros-1.8.7-1.fc17.src.rpm ... Getting requirements for ros-fuerte-ros-1.8.7-1.el6.src Error: No Package found for catkin-ros
Sorry. Uploaded the wrong package. ros-fuerte-1.8.7-1.fc17.src.rpm is what you want. Nuke that ros-fuerte-ros SRPM.
(Also, keep in mind that these packages are still a bit rough around the edges. I haven't done any testing outside of my F17 environment.)
~tom
== Fedora Project
Sorry. Uploaded the wrong package. ros-fuerte-1.8.7-1.fc17.src.rpm is what you want. Nuke that ros-fuerte-ros SRPM.
Thanks ...
(Also, keep in mind that these packages are still a bit rough around the edges. I haven't done any testing outside of my F17 environment.)
Looks like it won't build on EL6 (SL) ...
DEBUG: CMake Error at CMakeLists.txt:4 (cmake_minimum_required): DEBUG: CMake 2.8 or higher is required. You are running version 2.6.4
I've attached a patch to get it a bit further in mock (actually, log4cxx isn't in epel, but I have a local build of the koji package).
The build starts but then falls over with
DEBUG: /usr/bin/cmake28 -E cmake_progress_report /builddir/build/BUILD/fuerte-ros-base/build/CMakeFiles DEBUG: make[2]: *** No rule to make target `/usr/lib64/lib64/libboost_date_time-mt.so.5', needed by `lib/librostime.so'. Stop.
Not sure why lib64/lib64 got in there ...?
Simon
On 05/30/2012 07:13 AM, Simon Thompson wrote:
The build starts but then falls over with
DEBUG: /usr/bin/cmake28 -E cmake_progress_report /builddir/build/BUILD/fuerte-ros-base/build/CMakeFiles DEBUG: make[2]: *** No rule to make target `/usr/lib64/lib64/libboost_date_time-mt.so.5', needed by `lib/librostime.so'. Stop.
Not sure why lib64/lib64 got in there ...?
Weird. I'll try to look into that.
~tom
== Fedora Project
On Wed, May 30, 2012 at 6:32 AM, Tom Callaway tcallawa@redhat.com wrote:
Sorry. Uploaded the wrong package. ros-fuerte-1.8.7-1.fc17.src.rpm is what you want. Nuke that ros-fuerte-ros SRPM.
(Also, keep in mind that these packages are still a bit rough around the edges. I haven't done any testing outside of my F17 environment.)
~tom
This package is the full "ros-underlay" as described in ROS' fedora installation instructions. I read the comments in the spec about wanting the stacks available as separate tarballs; it looks like at least some of them are available as tarballs at https://code.ros.org/svn/release/download/stacks/, and are mirrored at https://github.com/wg-debs/ with some debfile stuff added.
It looks like when you run rosinstall it pulls tarballs from the code.ros.org site, I think that is a good target to start pulling stacks from to package once the core stuff is sorted out.
Rich
On 05/30/2012 09:00 AM, Rich Mattes wrote:
On Wed, May 30, 2012 at 6:32 AM, Tom Callaway <tcallawa@redhat.com mailto:tcallawa@redhat.com> wrote:
Sorry. Uploaded the wrong package. ros-fuerte-1.8.7-1.fc17.src.rpm is what you want. Nuke that ros-fuerte-ros SRPM. (Also, keep in mind that these packages are still a bit rough around the edges. I haven't done any testing outside of my F17 environment.) ~tomThis package is the full "ros-underlay" as described in ROS' fedora installation instructions. I read the comments in the spec about wanting the stacks available as separate tarballs; it looks like at least some of them are available as tarballs at https://code.ros.org/svn/release/download/stacks/, and are mirrored at https://github.com/wg-debs/ with some debfile stuff added.
It looks like when you run rosinstall it pulls tarballs from the code.ros.org http://code.ros.org site, I think that is a good target to start pulling stacks from to package once the core stuff is sorted out.
My first attempt was to package them up separately, but what I discovered is that the items in the underlay really seem to want to be built together, thus the single SRPM with multiple separately versioned subpackages.
~tom
== Fedora Project
robotics@lists.fedoraproject.org
-
Hedayat Vatankhah -
Rich Mattes -
Simon Thompson -
Simon Thompson -
Tom Callaway