8:54 a.m.
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
10:12 a.m.
On Tue, May 29, 2012 at 9:54 AM, Tom Callaway <tcallawa(a)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
10:33 a.m.
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
11:16 a.m.
On Tue, May 29, 2012 at 11:33 AM, Tom Callaway <tcallawa(a)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
[1] http://www.ros.org/wiki/fuerte/Installation/Fedora
11:23 a.m.
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
5:34 p.m.
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
10 p.m.
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
10:47 p.m.
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
2:11 a.m.
/*Rich Mattes <richmattes(a)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
> http://spot.fedorapeople.org/ros/
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/robotics
10:13 a.m.
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
1:07 p.m.
On Wed, May 30, 2012 at 11:13 AM, Tom Callaway <tcallawa(a)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
[1] http://ros.org/reps/rep-0122.html
1:16 p.m.
On 05/30/2012 02:07 PM, Rich Mattes wrote:
On Wed, May 30, 2012 at 11:13 AM, Tom Callaway
<tcallawa(a)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
12:28 p.m.
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
11:24 p.m.
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
10:11 p.m.
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
6:20 a.m.
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
8 a.m.
On Sat, Jun 9, 2012 at 7:20 AM, Tom Callaway <tcallawa(a)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
8:29 a.m.
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
8:53 p.m.
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
6:35 p.m.
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...
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
3:16 a.m.
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
5:32 a.m.
On 05/30/2012 04:16 AM, Simon Thompson wrote:
> http://spot.fedorapeople.org/ros/
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
6:13 a.m.
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
7:04 a.m.
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
8 a.m.
On Wed, May 30, 2012 at 6:32 AM, Tom Callaway <tcallawa(a)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
8:47 a.m.
On 05/30/2012 09:00 AM, Rich Mattes wrote:
On Wed, May 30, 2012 at 6:32 AM, Tom Callaway
<tcallawa(a)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.)
~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 <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
4323
days inactive
4343
days old
robotics@lists.fedoraproject.org
25 comments
5 participants
participants (5)
-
Hedayat Vatankhah -
Rich Mattes -
Simon Thompson -
Simon Thompson -
Tom Callaway