ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Who is using ROS on Archlinux?

In point of fact, I think it’s fairer to say that the official distribution of ROS does not default to installing in the system wide paths but instead uses the FHS /opt path for Add-on application software packages. ros is even a registered provider name with the delightful to say aloud, LANANA.

why this design choice was made in the first place.

Installing distributions to /opt/ros/$ROS_DISTRO and using scripts or other methods to manipulate system paths and variables for selecting between them enables multiple distributions to be installed on the same host without colliding. It’s the choice made for the official distribution but other distributors can and have installed a specific ROS distribution to the system-wide paths.

1 Like

Ah thank you for explaining. That does make sense now that you point these things out to me. I just wish there was a way of using ROS without worrying about sourcing, but the only way to go about that with multiple distributions is for each command name to be specific to the distribution which sounds even worse. Thanks once again, @nuclearsandwich!

We could add the script in /etc/profile.d/, but I don’t believe this is a good idea. At least we can discuss.

Any idea where this requirement came from? Or what the consequences might be if it were relaxed? Installing ROS to normal Linux FHS and avoiding all the sourcing would make it easier to use, and would probably make the build tools a lot simpler too.

As a user, I like the ability to install/use multiple ROS versions on a single OS.

It’s also something used by a variety of robot hw mfgs, which install into their own prefix.

That would seem to be what @nuclearsandwich refers to when he writes that not installing into system locations directly …

Doesn’t seem too different from how virtualenv and Conda work to me.


Edit: tbh I don’t quite get why people immediately jump to conclusions:

“sucks”, really?

Quite a bit of work has gone into trying to avoid messing with users’ system, trying not to "take over someone’s main(..)", actually working towards FHS compliance (REP 122, REP 123 and REP 124 and the myriad of discussions about it on ros-users) and without even referring to that history you conclude it sucks and everything is non-FHS compliant.

2 Likes

I apologize for my language, I was ignorant and I didn’t do my reading/research. I know now better. Thank you for pointing me to these resources. @gavanderhoorn

i just found sourcing to be particularly annoying for me since I only care about one ROS distribution at a time, but other users need that functionality. Also I don’t particularly like virtualenvs and condas either (although I do understand the use of them, similar to how I understand the use of ROS distributions). Would like everyone to be on the latest releases of software at all times, a big reason why I use Arch. Again I would like to apologize for my language without understanding the reasoning behind the design choices.

I have no issues with the current setup and I also prefer /opt install. For running ROS on startup I recommend making a systemd service, this is supported on most distros including ArchLinux and is easy to do. I have posted my setup to Github Gist as a guide:

https://gist.github.com/guru-florida/024f72385aa13cd2beb104ebcfdbc926

I am running on an RPi which doesnt have a shutdown button! :frowning: So I added a little GPIO circuitry and my systemd service controls an RGB LED for status and a button for production/devel mode and long-hold for shutdown. At the moment it simply starts/kills processes, but I would like to switch to Node Lifecycle instead which is easily possible. No limits really on how to control ROS2 with some systemd/python ingenuity.

Colin

@gavanderhoorn I would like to point this out: https://wiki.ros.org/UpstreamPackages
I think this is great work by Jochen Sprickerhof and Leopold Avellaneda and would love to see the work they have done into mainstream ROS. Each distribution can just correspond to a major version number change for all the packages. I think the a good goal for ROS to have would be to try to get their work upstream to Debian so a myraid of other users/distributions can use it.

No problem. I’ve done a lot of “jumping to conclusions” myself.

I’m fully aware of the existence of those packages. And the problems they cause when they clash with the regular ROS releases (ROS Answers is full of reports about this).

That’s not to say there is no value in having those, but with the current approach, it looks like it’s an either/or situation.

So within 2 posts you’ve gone from:

to wanting to upstream ROS into Debian, which would result in almost the complete opposite of what you wrote earlier :wink: (try reading up on how difficult it was to get a “simple” patch to urdfdom into the Debian released version of that library).

But this is all off-topic for this thread. So I’ll shut up.

If your systems don’t need to support multiple rosdistros, you can source the environment setup scripts in your shell’s startup routines, e.g. in .bashrc / .bash_profile or ~/.config/fish/config.fish. That works on a per-user basis and depending on your system bringup methods you could either add sourcing the environment to default shell profiles in /etc/skel or find some other way to trigger them globally.

1 Like

I am having a similar issue. I’m following the installation instructions and I get the following error:

$ rosdep init
Traceback (most recent call last):
  File "/usr/bin/rosdep", line 3, in <module>
    from rosdep2.main import rosdep_main
  File "/usr/lib/python3.8/site-packages/rosdep2/__init__.py", line 40, in <module>
    from .installers import InstallerContext, Installer, \
  File "/usr/lib/python3.8/site-packages/rosdep2/installers.py", line 36, in <module>
    from rospkg.os_detect import OsDetect
  File "/usr/lib/python3.8/site-packages/rospkg/os_detect.py", line 42, in <module>
    import distro
ModuleNotFoundError: No module named 'distro'

I did source /opt/melodic/setup.bash. A similar error occurs when I run roscore:

$ roscore
Traceback (most recent call last):
  File "/opt/ros/melodic/bin/roscore", line 72, in <module>
    import roslaunch
  File "/opt/ros/melodic/lib/python3.8/site-packages/roslaunch/__init__.py", line 62, in <module>
    from .scriptapi import ROSLaunch
  File "/opt/ros/melodic/lib/python3.8/site-packages/roslaunch/scriptapi.py", line 42, in <module>
    import roslaunch.parent
  File "/opt/ros/melodic/lib/python3.8/site-packages/roslaunch/parent.py", line 54, in <module>
    import roslaunch.server
  File "/opt/ros/melodic/lib/python3.8/site-packages/roslaunch/server.py", line 79, in <module>
    from rosgraph_msgs.msg import Log
  File "/opt/ros/melodic/lib/python3.8/site-packages/rosgraph_msgs/msg/__init__.py", line 2, in <module>
    from ._Log import *
  File "/opt/ros/melodic/lib/python3.8/site-packages/rosgraph_msgs/msg/_Log.py", line 8, in <module>
    import std_msgs.msg
ModuleNotFoundError: No module named 'std_msgs'

I am guessing this error is somehow related to python, it seems to me that it is trying to use python3 deps. When I install ROS from the AUR packages does it install ROS for python2? Maybe it does not install the dependencies required for python3? Is it possible to force it to use python2?

@Rezenders The place to post these questions is at the respective package’s github page at https://github.com/ros-melodic-arch

Ok. Sorry about posting it here.

1 Like

Hi,
I’ve heard there is a “official” ROS-ArchLinux Community.
I like to be part of, what have I to do?

I’m package maintainer of some ros-melodic packages (https://aur.archlinux.org/packages/?K=majorx234&SeB=m)

and work on improvement of automatically PKGBUILD Creation
(https://github.com/majorx234/ros-build-tools-py3

Hey @majorx234 glad to see you being active!
There is a small number of us, so its nice if we stick together haha.

In terms of the ROS ArchLinux Community we have 3 main points of contact.

The first is this discourse thread, which is a p high level thread of just ROS on Arch Linux in general.
The second one is of course where we host the packages, the AUR.
However, since discussion and development is a bit hard to do via the AUR comments, we have moved over to the following Github organization: https://github.com/ros-melodic-arch

The way our current pipeline is works is as follows:
(bionade24) in charge of syncing changes from the github repo to the AUR. bionade24 also maintains oscloud(https://wiki.archlinux.org/index.php/Unofficial_user_repositories#oscloud) which has the binary packages for ros-melodic-*
(jwhendy, acxz) along with bionade24 we help maintain the github organization and are in charge of reviewing community submitted PRs

Some of us are also working on getting the ros-noetic-* packages set up here: https://github.com/ros-noetic-arch

If you could transfer the ownership of your existing ros-melodic-* packages to bionade24 and create a package request issue with your packages at https://github.com/ros-melodic-arch/ros-melodic-desktop-full we can create the associated repos and have them part of the ros-melodic=* stack that stays in sync.

As for utilities check out: https://github.com/bionade24/aur-ci

Hi, as I also recently switched to Archlinux on my work machine, I am finally facing all the ROS installation stuff, as well. Is there any process to add / propose new packages to ros-melodic-arch?

Also, what is the process of syncing between the GH versions and the AUR packages? For example, for the moveit packages I noticed, that they are on version 1.0.3 on GH, but in the AUR most of them are on 1.0.2.

And finally: What are the ways to contribute? I don’t have that much time to put into this, but as I already started creating own PKKBUILDs locally for packages I use often, but are not in the AUR, it might be better to merge my efforts upstream somehow.

Hey @fmauch happy to see more users on Arch!

As for adding and proposing new packages, the process is as follows:

  1. Create a package request issue including the name and source repo of the associated package to be added.
  2. We will create the associated repo on GH
  3. Submit a PR to the associated repo
  4. After merging the PR, it will be synced to the AUR (can be installed with AUR helper at this point)
  5. After syncing to the AUR, it will later be added to the binary repo oscloud (for melodic) and arch4edu (for noetic) (can be installed with pacman at this point)
  6. After getting the package to a binary repo, we submit a rosdep request for the package (can be installed with rosdep at this point)

As for syncing, we have an automatic pipeline for syncing the packages from GH to the AUR. However, the sync only occurs when the PKGBUILD is build in a clean root. There might be a hiccup on the moveit packages. In this case, it is appropriate to create an issue labelled Need to sync on the respective the package and we will take a closer look at it. Or you can try to build the package in a clean chroot and report your findings.

Objectives that we have right now are the follows:

  1. Get noetic (up to ros-noetic-desktop-full) packages out on the AUR
  2. Get noetic (up to ros-noetic-desktop-full) packages on arch4edu
  3. Get noetic (up to ros-noetic-desktop-full) packages on rosdep
  4. Similar three objectives for foxy as well
  5. Flesh out the rest of the noetic packages that are not under ros-noetic-desktop-full but are still under the noetic distribution

Take a look at the issues and projects for the corresponding GH organizations as well. There may be some build errors and PKGBUILDs that need some cleaning up.

1 Like

The first point isn’t totally clear to me. I opened a package request thread but that seems not to be the right place.

@eschwartz seems to have pointed you to the right direction.
Create an issue at https://github.com/ros-melodic-arch/ros-melodic-desktop-full

See some closed issues as a template: https://github.com/ros-melodic-arch/ros-melodic-desktop-full/issues?q=is%3Aissue+is%3Aclosed+Package+Request

Hello all,

I know I have been pretty active in maintaining and helping users on Arch Linux out for ROS Melodic. However, with the release of ROS Noetic today, I will stop help in maintaining ROS Melodic packages on Arch Linux. With 2-3 three people it is hard to maintain so many ROS packages and dealing with two distributions will be even harder.

As such, I will be focusing my efforts concerning ROS on Arch Linux solely on ROS Noetic. Feel free in helping out with the ROS Noetic packages by offering PKGBUILDs and submitting bug reports. See you guys over at https://github.com/ros-noetic-arch from now!