Package Details: grass 8.3.1-1

Git Clone URL: https://aur.archlinux.org/grass.git (read-only, click to copy)
Package Base: grass
Description: Geospatial data management and analysis, image processing, graphics/maps production, spatial modeling and visualization
Upstream URL: http://grass.osgeo.org/
Keywords: analysis GIS remote sensing spatial
Licenses: GPL
Submitter: Scimmia
Maintainer: kikislater
Last Packager: kikislater
Votes: 38
Popularity: 0.000003
First Submitted: 2015-09-06 15:10 (UTC)
Last Updated: 2023-11-11 13:04 (UTC)

Latest Comments

« First ‹ Previous 1 .. 11 12 13 14 15 16

czk commented on 2015-10-03 22:59 (UTC)

Please bring back the following: --with-nls enables interface translations, --with-cxx enables building some cool modules written in C++: r.terraflow, i.attcor, r.viewshed, --with-pthread enables parallel processing boost for r.mapcalc, the core GRASS raster module, --with-netcdf: required for r3.out.netcdf, and maybe for old NetCDF format support in r.out.bin (not sure about the latter), --with-liblas: I will ask you to bring it back when I upload liblas to new AUR. It is required for r.in.lidar and v.in.lidar. Please mind that some great GRASS addons depend on the missing modules, too.

Scimmia commented on 2015-10-03 22:25 (UTC) (edited on 2015-10-03 22:52 (UTC) by Scimmia)

Read the PKGBUILD again, I'm not dropping the user's CPPFLAGS. As for the advantage of using sed, it's an actual fix instead of a hack. Correct me if I'm wrong, but aren't those addons called with "$GRASS_PYTHON" instead of just run directly? If so, the shebang won't really matter.

czk commented on 2015-10-03 21:40 (UTC)

What is the advantage of: sed -i 's/\(env \|\/usr\/bin\/\)python$/&2/' $(find . -name "*.py") over: ln -sf "`which python2`" "${pkgdir}/opt/${pkgname}/bin/python" ? I thought that linking `python2' as `python' in GRASS $GISBASE is better, as it does not require each *future* python script (eg. addons installed with g.extension) to be patched. Or have you maybe identified some issues with my approach that you decided to drop it?

czk commented on 2015-10-03 21:25 (UTC) (edited on 2015-10-03 21:41 (UTC) by czk)

Doug, I think that dropping all user's CPPFLAGS is not right. A user can set his CPPFLAGS in /etc/makepkg.conf as he likes them, and will want them to be honored in a makepg build. GRASS 7 can't (or couldn't? I haven't tried building it for a while) cope with -D_FORTIFY_SOURCE=2, but that doesn't mean that all user's CPPFLAGS should be dropped.

« First ‹ Previous 1 .. 11 12 13 14 15 16