Package Details: gazebo 11.14.0-2

Git Clone URL: https://aur.archlinux.org/gazebo.git (read-only, click to copy)
Package Base: gazebo
Description: A multi-robot simulator for outdoor environments
Upstream URL: https://classic.gazebosim.org/
Licenses: Apache
Submitter: None
Maintainer: acxz
Last Packager: acxz
Votes: 35
Popularity: 0.000334
First Submitted: 2008-10-18 22:59 (UTC)
Last Updated: 2023-12-11 14:35 (UTC)

Pinned Comments

billypilgrim commented on 2022-05-09 16:04 (UTC)

Development is on Github: https://github.com/acxz/gazebo-arch Please open issues and PRs there instead of commenting.

Latest Comments

« First ‹ Previous 1 .. 9 10 11 12 13 14 15 16 17 18 19 .. 33 Next › Last »

MaEtUgR commented on 2019-10-17 09:43 (UTC)

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().
    Aborting...
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)[https://wiki.archlinux.org/index.php/Makepkg#Troubleshooting] 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 (UTC)

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

bobpaul commented on 2019-10-16 01:50 (UTC) (edited on 2019-10-16 01:52 (UTC) by bobpaul)

@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 (UTC)

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 (UTC) (edited on 2019-10-13 15:02 (UTC) by MaEtUgR)

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 https://bitbucket.org/ignitionrobotics/ign-cmake/issues/62/compilation-failing-when-performing
pushd ~/.cache/yay/ignition-cmake/
sed -i 's/-DENABLE_TESTS_COMPILATION:BOOL=False/-DBUILD_TESTING=OFF/g' PKGBUILD
makepkg -si --noconfirm
popd

# 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 (UTC)

@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. http://gazebosim.org/tutorials?tut=install_dependencies_from_source&cat=install 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 (UTC)

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.

acxz commented on 2019-10-05 06:15 (UTC)

@billypilgram If you could remove the unnecessary pkgver dependencies and add the necessary ones (see comments below) that would be much appreciated. I would be willing to co-maintain this package with you to fix these issues.

acxz commented on 2019-10-05 06:14 (UTC)

@lucasmazz Are you having trouble with the sdformat package? If so I recommend posting the issue there. The PKGBUILD for this package does not compile unit tests, unless they are happening with the default make command. In that case I would recommend opening an issue to gazebo upstream.

acxz commented on 2019-10-05 06:11 (UTC)

@zigas Here is the relevant bug: https://bugs.archlinux.org/task/61461?project=5&string=libpgm. As you can see the libpgm package is out of date on the official repos. Instead of manually editing files (not recommended), you can use the libpgm-git package instead, which is a newer version that does not have that issue.

« First ‹ Previous 1 .. 9 10 11 12 13 14 15 16 17 18 19 .. 33 Next › Last »