[ros-users] ROS cturtle on openSuSE 11.2

[V C]

Hi.

First off, a big thanks to the community that has created and is maintaining
ROS ! You are doing a great job !

I am trying to get cturtle working on openSuSE 11.2. Per the instructions on
the wiki and earlier discussions on the mailing list, I understand that
support for openSuSE is a work in progress, and I would like to add my
experience and perhaps contribute a little here.

1. rosinstall: I am doing a "Base install"; we are behind an authenticating
proxy here, and while SVN was able to check out the necessary packages with
the addition of the necessary config variables in .subversion, the default
Mercurial on openSuSE 11.2 (1.3.1) was unable to handle the https check out;
I worked around it by manually installing the latest Mercurial release,
which was able to handle it correctly.

2. OS detection: cturtle by itself does not detect the OS; however by
looking at the latest builds where detection of openSuSE is supported, I
managed to include the necessary code in rosdep/{opensuse.py, core.py} and
rosbuild/os_detect.py to detect the OS. One doubt I had here was why the
lsb_* functions were not being used to detect the OS - on modifying the code
to use the lsb_* functions, I find that the OS and version are being
detected correctly. Am I missing something here ?

3. rosdep.yaml: I updated all the rosdep.yaml files to autoinstall
dependencies from RPMs as far as I could detect them. However, a few
dependencies require manual installs (wget <source>; configure-make-make
install). These scripts are however not being run with rosdep saying "rosdep
check could not check scripts"; I understood from my searches that script
installs were not supported under cturtle, but that they are now.
Unfortunately, never having used python myself, I am unable to back port the
the necessary changes as easily as I could for the OS detection; I will work
on it, but I just wanted to understand whether it is feasible and should be
attempted. Also, how would su privileges be handled if the build is started
as an unprivileged user ? In one case - the cg toolkit - a symbolic link
seems required, since the cg toolkit looks for *.so, but the Mesa library
installs it as *.so.1; how would this be handled in the rosdep.yaml ? Would
the following work, for eg. (mixing an RPM install and a script)

nvidia-cg:
  ubuntu: nvidia-cg-toolkit
  debian: nvidia-cg-toolkit
  fedora: Cg
  arch: |
    if ! pacman -Q nvidia-cg-toolkit ; then yaourt -S nvidia-cg-toolkit; fi
  gentoo: nvidia-cg-toolkit
  debian: nvidia-cg-toolkit
  opensuse:
    11.2: Mesa cg cg-devel |
      sudo ln -sf libGLU.so.1 /usr/lib/libGLU.so

4. OGRE, SWIG, etc: Trying a "rosmake rviz" caused the build to hang on OGRE
and SWIG; on terminating the build with a Ctrl+C and checking the output, it
seems that the OGRE and SWIG sources were being downloaded from WG by a
script "download_checkmd5.py". The script correctly detected the
authenticating proxy and was apparently waiting for user input for the
username and password, however the prompt never appeared on the command line
until the Ctrl+C was received. I manually downloaded the sources and put
them in the necessary directories and moved on; however I would like to
understand why the prompt never appeared and if possible add support for
that. Could somebody point me in the right direction ?

I am writing up a detailed note on the installation steps that I followed;
would it be ok to post it on the list or is there a preferred alternative ?
Also, what can I do to make it easier for anybody else to incorporate the
changes I have made to get it working with the checked-out cturtle code ? Is
there a separate branch being maintained for cturtle to which patches can be
added ? I apologize if some of the questions seem very basic, but I am
fairly new to the concept of contributing to open source code, hence the
desire to try to "do the right thing" !

Thanks again.

VC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/ros-users/attachments/20110828/4589ed50/attachment-0002.html>