Package Details: gazebo 10.1.0-2

Git Clone URL: (read-only, click to copy)
Package Base: gazebo
Description: A multi-robot simulator for outdoor environments
Upstream URL:
Licenses: Apache
Submitter: None
Maintainer: billypilgrim
Last Packager: billypilgrim
Votes: 27
Popularity: 0.80
First Submitted: 2008-10-18 22:59
Last Updated: 2019-10-21 15:19

Dependencies (32)

Sources (1)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

leuko commented on 2019-11-30 08:35

graphviz is an additional dependency. Gazebo requires

MaEtUgR commented on 2019-10-25 03:05

The maintainer over at ignition-cmake @acxz reminded me in that ignition-cmake is not required for gazebo. Still in the PKGBUILD file of this AUR there's the line makedepends=('cmake' 'doxygen' 'ignition-cmake'). I just wanted to give a hint since this dependency might not be necessary (I didn't test it).

MaEtUgR commented on 2019-10-23 14:51

@acxz fixed the issue by some changes in the igntion-cmake AUR. Thanks again! More info see

MaEtUgR commented on 2019-10-17 09:43

Thanks for all the answers, the nproc one is a nice hint, I was used to grepping /proc/cpuinfo since it works even without that binary e.g. on Android CLI.

I still have the issue on latest Manjaro fresh install: yay -S gazebo --noconfirm fails with

[ 47%] Built target component_deps_RelWithDebInfo
[ 47%] Performing test step for 'component_deps_Release'
[ 47%] Completed 'component_deps_Release'
[ 47%] Built target component_deps_Release
make: *** [Makefile:141: all] Error 2
==> ERROR: A failure occurred in build().
Error making: ignition-cmake

I am totally aware that adjusting the PKGBUILD is a hack but I don't know any way of telling CMake to disable build testing for ignition-cmake (-DBUILD_TESTING=OFF) from the file /etc/makepkg.conf. Setting the environmental variable BUILD_TESTING=OFF in the configuration doesn't help. It doesn't belong into any of CFLAGS/CXXFLAGS/LDFLAGS according to my understanding and also in the linked (wiki)[] it says if -DCMAKE_BUILD_TYPE is defined for a certain package it will ignore the /etc/makepkg.conf CMake configuration.

Would be nice if the root cause could actually get fixed since the ignition-cmake PKGBUILD defines ENABLE_TESTS_COMPILATION:BOOL=False and then CMake out put tells you that parameter doesn't exist but you need to disable testing (which ENABLE_TESTS_COMPILATION:BOOL=False previously probably did) to make the build work on Arch.

I'll also comment on the ignition-cmake AUR.

billypilgrim commented on 2019-10-16 15:40

...but you should put your makeflags in /etc/makepkg.conf rather than hacking the PKGBUILD.

bobpaul commented on 2019-10-16 01:50

@MaEtUgR, instead of grepping /proc/cpuinfo you can just use the nproc command (ex MAKEFLAGS="-j$(nproc)"). See the wiki.

billypilgrim commented on 2019-10-14 12:33

Hmm I haven't run into the issue you seem to have with building the tests but I'll investigate it later.

In terms of the make flags, you can just set those in /etc/makepkg.conf instead.

MaEtUgR commented on 2019-10-13 15:01

Hi, first of all thanks a lot for providing this AUR. I did quite some tests on latest Manjaro and got it working within a reasonable compilation timeframe using:

# enable multicore gazebo compilation
sudo sed -i '/MAKEFLAGS=/c\MAKEFLAGS="-j'$(($(grep -c processor /proc/cpuinfo)+2))'"' /etc/makepkg.conf

# install gazebo from AUR
yay -S gazebo --noconfirm

# fix incompatible compile flag to disable default testing that leads to build error
# see
pushd ~/.cache/yay/ignition-cmake/
makepkg -si --noconfirm

# continue installing gezebo
yay -S gazebo --noconfirm

Is it possible to automate especially the ignition-cmake fix but also the multicore compilation such that the next user doesn't need to spend as much time as me? Am I doing something wrong such that these manual modifications are necessary? Can I contribute other than writing a comment here? Can I submit a patch?

acxz commented on 2019-10-06 00:14

@billypilgram: I apologize for my eagerness during the past. I understand your point on versioned dependencies, I concede. But for ignition-common/fuel-tools/msgs/cmake the version deps do matter. Users are prone to installing 4 extra packages that are not needed for this package.

However, I will stop bothering you on this issue. Thank you for taking the time to respond.

billypilgrim commented on 2019-10-05 13:42

I don't really see the point tbh. As an AUR maintainer all I care about is: a) Does it build for all real (not hypothetical) users? b) Is it up to date?

And I try to deal with the above in a relatively timely manner. You're asking me to tailor the PKGBUILD to your tastes in a way which will have no impact on any users.

I don't want to co-maintain this package with you because you don't seem to understand what is required of AUR maintainers and what the requirements for a PKGBUILD are: 1) You seem to think packages should be orphaned if the maintainer does not respond within 24 hours (they don't, as per the wiki) 2) The versioned dependencies are not unnecessary as presumably older versions of these packages won't work and, moreover, removing the version dependency will have no effect whatsoever on any users

You can maintain your packages however you like, but I only care about a) and b), as seemingly do all the other users I've encountered on the AUR. Caring about anything else is really just a waste of everyone's time, especially non-functional changes to PKGBUILDs.