Arch Linux User Repository

@GPereira, we really need a rollback.

While I am endlessly grateful for the work you have done to make ROS available on Arch, I'll have to switch to Ubuntu for my ROS work for the time being, simply because I do not have the time, experience, or let alone efficient workflow to manually patch dozens of packages, just because some patches were applied too hastily.

Before this upgrade to Python 3, I already had to compile RViz with OGRE 9 again because OGRE 11 RViz still has issues with RobotModels and Maps, see https://github.com/ros-visualization/rviz/issues/1277.

I understand that making ROS available on the AUR is a daunting task, and that perhaps deeming Arch a reliable workstation distro is much more of a gamble than I would like to admit, but going from something that worked really well for half a year with just some rebuilds and minor patching to an experimental playground of this scale is frustrating.

At this point, I would rather be at the mercy of prebuilt ROS binaries on Arch than dreading every single -Suy. If that would also be an option for others, I would happily join an effort to make this a reality.

I ended up replacing the prepare() section of almost all files with:

prepare() {
    cd ${srcdir}/${_dir}
    _pkgname=$(echo ${pkgname} | sed 's/ros-melodic-//' | sed 's/-/_/g')
    git checkout release/melodic/${_pkgname}
}

Some packages are fixed by only fixing the sed 's/ros-lunar-//' segment, but many are not (and these seem to have nothing to restrict them to melodic).

@GPereira, You can easily try to build ros-melodic-roscpp. it has a dependency with ros-melodic-cpp-common that does not contain the CMakeLists

At the end, there is no possibility to build the package.

I also tried to build this few days ago, encountering the same impingements. After reading the experience of miramur, for sure I am not going to follow that path. My opinion is that the rollback to python2 is necessary untill a working python3 packaging is found, otherwise several people (included me) will just give up using ROS on Arch.

I can roll back my edits. But that will mean python 2 will be used

Can you further explain what that does? Thanks for your input!

Well, apparently until now, there are some packages that still have the same problem of the CMake files, some packages points to the wrong directory for Cmake.

Do we have any contact with the maintainer ?? I need to install all the ros melodic. I am not imagining my self modifying each package manually

EDIT: Finally built and installed (no word yet on runtime)! Tips and Tricks:

• Build Ogre v1.10.12 manually, remove ogre-1.9 as a dependency of rviz and remove ogre as a dependency of gazebo
• A couple header files are out-of-date. Look for my comments in relevant packages when you hit that build error.
• You might get a python2 -> python3 error (e.g. a print() call without parentheses). Honestly, easiest fix for those for me was to just pause the build after cloning (^Z) and editing those errors out manually.

Best of luck! This literally took forever to install, since most PKGBUILDs required the changed cmake directory.

In the middle of a long, arduous journey to build this. It's been said before (making a note more for myself): many of the PKGBUILDS in the deps point to the wrong folder for cmake. Specifically, pointing to the root directory of the repo instead of the specific package sub-directory.

Example in ros-melodic-roscpp-serialization, line 64:

-        cmake ${srcdir}/${_dir} \
+        cmake ${srcdir}/${_dir}/roscpp_serialization \

In the meantime, if you encounter an error like:

CMake Error: The source directory "<path>/ros-melodic-cpp-common/src/ros-melodic-cpp-common" does not appear to contain CMakeLists.txt.

That's the issue. Note that many packages pull the exact same repo, some packages are in "core," some in "tools," etc.

I think what Timonegk meant was that the package isn't deterministic anymore. You could build it with the same PKGBUILD on different days and end up with different results because upstream isn't tracking a specific version (AFAIK), it's fluid.