Package Details: grass 7.0.4-1

Git Clone URL: https://aur.archlinux.org/grass.git (read-only)
Package Base: grass
Description: Geospatial data management and analysis, image processing, graphics/maps production, spatial modeling and visualization
Upstream URL: http://grass.osgeo.org/
Licenses: GPL
Submitter: Scimmia
Maintainer: Scimmia
Last Packager: Scimmia
Votes: 15
Popularity: 2.014081
First Submitted: 2015-09-06 15:10
Last Updated: 2016-05-16 00:41

Latest Comments

Scimmia commented on 2016-08-17 13:21

@scummos, no. Read the AUR wiki page.

scummos commented on 2016-08-17 09:17

This needs to additionally depend on
core/flex
community/byacc
or the build will fail.

kikislater commented on 2016-06-04 09:08

Another PKGBUILD here (from official grass gis website) :
https://gitlab.com/tutturu/grass7_pkgbuild

Better options according to common GIS usage with Grass

SmokeyD commented on 2016-05-20 01:48

I had the build problems as well like all previous commenters with GCC6. I also tried using GCC5 and GCC4.something from AUR, but it didn't want to build. Today I just tried installing again form AUR without any modifications and it just built and installed fine without trouble. I assume @Scimmia did something in the PKGBUILD to make it compile correctly with GCC6. If so, it worked like a charm for me. Thanks a lot!

Scimmia commented on 2016-05-16 00:43

Got it. GCC6 defaults to C++14 now, and GRASS can't handle that. Forcing it back to C++98 lets everything build fine again. I didn't bump the pkgrel, as there's no need to rebuilt it if you already successfully built it earlier.

Having different compilers in core and testing set us back a bit on this. Thanks for your patience.

Scimmia commented on 2016-05-16 00:28

Alright, I can reproduce it now. I think these are GCC6 issues.

beej commented on 2016-05-15 23:00

Detail on the iostream build error. Looks like it might be an upstream issue.

http://pastebin.com/NnjN4n07

kikislater commented on 2016-05-12 20:02

On my second setup, I successfull built it with make -j8 on 4790k cpu

Scimmia commented on 2016-05-12 13:36

@Humu_2013, @zottelef, from kikislater's comment, this could be a race condition. Try adding "-j1" to the "make" command in the build function. If that works, I can add it to the PKGBUILD.

zottelef commented on 2016-05-12 08:37

@HuMu_2013 & @Scimmia:
I am playing around with the compilation error in the iostream:

In file included from /home/fabio/sources/grass-7.0.4/dist.x86_64-pc-linux-gnu/include/grass/vect/digit.h:3:0,
from /home/fabio/sources/grass-7.0.4/dist.x86_64-pc-linux-gnu/include/grass/vector.h:4,
from do_copy.c:20:
/home/fabio/sources/grass-7.0.4/dist.x86_64-pc-linux-gnu/include/grass/vect/dig_structs.h:20:23: fatal error: grass/dgl.h: No such file or directory
#include <grass/dgl.h>
^
compilation terminated.


Could this help?

HuMu_2013 commented on 2016-05-11 07:02

Got the errors as @zottelef:

Errors in:
/home/huub/abs/grass/src/grass-7.0.4/lib/iostream
/home/huub/abs/grass/src/grass-7.0.4/raster/r.terraflow
/home/huub/abs/grass/src/grass-7.0.4/raster/r.viewshed
--
In case of errors please change into the directory with error and run 'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Wed May 11 06:50:04 GMT 2016
Makefile:57: recipe for target 'default' failed
make: *** [default] Error 1
==> ERROR: A failure occurred in build().
Aborting...

kikislater commented on 2016-05-04 09:50

I forgot that I made, before building, a ton of update.
After rebooting and building without make -jx (where x is my number of cores cpu unit) it's building like a charm on 2 installations. Sorry for the message ...

zottelef commented on 2016-05-04 09:22

As for kikislater I have Errors in:
/tmp/yaourt-tmp-fabio/aur-grass/src/grass-7.0.4/lib/iostream
/tmp/yaourt-tmp-fabio/aur-grass/src/grass-7.0.4/raster/r.terraflow
/tmp/yaourt-tmp-fabio/aur-grass/src/grass-7.0.4/raster/r.viewshed
--
In case of errors please change into the directory with error and run 'make'.
If you get multiple errors, you need to deal with them in the order they
appear in the error log. If you get an error building a library, you will
also get errors from anything which uses the library.
--
Finished compilation: Wed May 4 09:53:45 CEST 2016
Makefile:57: recipe for target 'default' failed
make: *** [default] Error 1

I cannot catch, however which kind of error is, because GRASS compilation produces a ton of output. And the content of error.log is exactly what I am writing above. Any hints to help?

Scimmia commented on 2016-04-28 16:15

Builds just fine in a clean chroot, nothing to update.

If you want help, we'll need an english error message at the very least.

kikislater commented on 2016-04-28 15:49

Error in building since the update of 27/04. Please update

Finished compilation: jeu. avril 28 17:47:10 CEST 2016
Makefile:57 : la recette pour la cible « default » a échouée
make: *** [default] Erreur 1

kikislater commented on 2016-02-02 12:34

@HuMu_2013 : It works for me ! I use v.generalize with chaiken algorithm aka smooth and I have no problem.
I don't use grass under qgis

HuMu_2013 commented on 2016-02-01 10:24

I went back to 7.0.2.
Some modules were not fonctionning correctly like "smooth or simplify" under "Topology maintenance". Moreover the GRASS layers were not visible and importable any more in Qgis.

kikislater commented on 2016-01-29 09:03

@Scimmia : Thanks for the update, it works well now !
I can install and use addon written in python more easyly :D

Scimmia commented on 2016-01-25 16:17

"There is a lot of addons using python with grass, I don't want to re-write them in another language like C or C++. Grass GIS does not support python 3, so it's important to use python 2 instead of 3 until they fully support it !
If you don't have python 2 in Grass GIS at this moment, this package should be useless ..."

Which is why GRASS should be calling the script with $GRASS_PYTHON, and script authors should be using #!/usr/bin/env python2. Calling "python" specifically means that you don't care which version you get.

We have to be pragmatic, though, and work around upstream lunacy.

kikislater commented on 2016-01-21 10:58

There is a lot of addons using python with grass, I don't want to re-write them in another language like C or C++. Grass GIS does not support python 3, so it's important to use python 2 instead of 3 until they fully support it !
If you don't have python 2 in Grass GIS at this moment, this package should be useless ...

Watch :
Note: Python 3 support is still in development
Source : https://grass.osgeo.org/grass70/source/snapshot/REQUIREMENTS.html
And : https://trac.osgeo.org/grass/ticket/2708
#2708 new defect
Run GRASS with Python3
Jalon modifié de 7.0.2 à 7.0.3
Ticket retargeted after milestone closed

Also you have this in your build :
# Enabling only those features which are not enabled by default. Out of the
# usefull ones, only DWG, MySQL, FFMPEG and Motif are left disabled. LAPACK
# and BLAS are not used for anything in GRASS anyway.
But what about v.kriging ... It needs BLAS and LAPACK package. You forgot addons which is an important part of GRASS GIS. We have a limited GRASS GIS build !

Scimmia commented on 2016-01-21 10:25

kikislater, really, you shouldn't be using "python" if you specifically want python2. See http://legacy.python.org/dev/peps/pep-0394/

kikislater commented on 2016-01-18 22:51

Ok Thank you
I made a test and I saw that :

Big problem with the build. Not the good python version

GRASS 7.0.2 (DATA):~ > which python
/usr/sbin/python
[MASK raster présent]
GRASS 7.0.2 (DATA):~ > /usr/sbin/python --version
Python 3.5.1
[MASK raster présent]

cat /usr/bin/grass70 | more
#!/usr/bin/env python2
#############################################################################

Scimmia commented on 2016-01-18 22:44

Yeah, I figure I'll put the python symlink hack back in on the next release, which will be any time.

And please, figure out what "out-of-date" means.

kikislater commented on 2016-01-18 22:39

Package is buggy
If I want to launch grass addons, I have to put at the beginning of python script this :
#!/usr/bin/env python2

For example, I use v.surf.nnbathy I have to edit v.surf.nnbathy.py and nnbathy.py and add this #!/usr/bin/env python2 at the beginning of the *.py files. Same problem as described below by kuszi

Please correct the package Scimmia

kikislater commented on 2016-01-17 14:30

It should concern wxpython package. Edit the file yourself found in /usr/lib/python2.7/site-packages/wx-3.0-gtk2/wx/lib/plot.py
And flag package wxpython out of date

HuMu_2013 commented on 2016-01-17 13:49

Any chance to apply this patch?
http://trac.wxwidgets.org/attachment/ticket/16767/wxPython-3.0.2.0-plot.patch
Since for some time the "analyze map" & "profile surface map" functions don't work.

kuszi commented on 2016-01-03 13:32


Addon: when script begins with:

#!/usr/bin/python2

it starts to work. So, it seems that in the call chain somewhere grass python environment is "lost". It could be special to g.parser ...

kuszi commented on 2016-01-03 10:20

Hello!

I have a GRASS - python, maybe environment problem. I've created a small test module in python. I tried to use g.parser to check it for its gui.
It seems that there are python module loading problems..

--------------GRASS specific env - from inside GRASS
GRASS 7.0.2 (HUNUTMWgs84):~/grassdata/scripts > env | grep GRASS
GRASS_PYTHON=python2
GRASS_GNUPLOT=gnuplot -persist
GRASS_PAGER=more
GRASS_ADDON_PATH=/home/kuszi/.grass7/addons
GRASS_PROJSHARE=/usr/share/proj
GRASS_VERSION=7.0.2
GRASS_HTML_BROWSER=xdg-open
GRASS_ADDON_BASE=/home/kuszi/.grass7/addons
GRASS 7.0.2 (HUNUTMWgs84):~/grassdata/scripts >

------------ g.parser invocation:

GRASS 7.0.2 (HUNUTMWgs84):~/grassdata/scripts > g.parser g.sample

----------------------ERROR:

Unable to fetch interface description for command 'g.sample'.
Details: Traceback (most recent call last):
File "/home/kuszi/grassdata/scripts/g.sample", line 18, in <module>
import grass.script as grass
File "/opt/grass/etc/python/grass/script/__init__.py", line 5, in <module>
from db import *
ImportError: No module named 'db'

Try to set up GRASS_ADDON_PATH or GRASS_ADDON_BASE variable.

------------------- g.sample
#!/usr/bin/env python

#%module
#% description: minimal.
#% keyword: testing
#%end
#%option
#% key: table
#% type: string
#% required: yes
#% multiple: no
#% key_desc: name
#% description: Input table name
#% gisprompt: old,dbtable,dbtable
#%end
import sys

import grass.script as grass

def main():
# put code here
return 0

if __name__ == "__main__":
options, flags = grass.parser()
sys.exit(main())

------------------ PATH for my user (outside the grass session)
[kuszi@kuszidell ~]$ echo $PATH
/home/kuszi/grassdata/scripts:/home/kuszi/scripts:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

------------------ PATH inside the GRASS session:
GRASS 7.0.2 (HUNUTMWgs84):~/grassdata/scripts > echo $PATH
/opt/grass/bin:/opt/grass/scripts:/home/kuszi/.grass7/addons/bin:/home/kuszi/.grass7/addons/scripts:/home/kuszi/grassdata/scripts:/home/kuszi/scripts:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

------------------ YTHON environment vars
GRASS 7.0.2 (HUNUTMWgs84):~/grassdata/scripts > env | grep YTHO
GRASS_PYTHON=python2
PYTHONPATH=/opt/grass/etc/python:/opt/grass/gui/wxpython

I've tested many scripts, simpler, more complicated, etc. It seems to be universal to python scripts. bash script dialogs appear well.

What else to test?

Thanks for any ideas
Robert

Scimmia commented on 2015-11-20 16:24

It's not, but bison is. It seems to do the job for me.

bilthekid commented on 2015-11-20 15:52

I see. Although, the flex is part of base-devel package group, does it also stand for byacc? Because I dont see it in the list: pacman -Ss base-devel|grep -i yacc.

Scimmia commented on 2015-11-20 14:00

@bilthekid, nope. See https://wiki.archlinux.org/index.php/Arch_User_Repository#Prerequisites

bilthekid commented on 2015-11-20 13:02

@Scimmia, could you add as dependencies **flex** and **byacc** because otherwise you will get errors in building?

Thanks

PetoP commented on 2015-10-27 07:27

@Scimmia, it works pefect!

Thank you very much :)

Scimmia commented on 2015-10-27 02:54

@PetoP, try it now

PetoP commented on 2015-10-26 17:10

Hi guys!

I can't resolve issues with g.extension. I tried to install r.stream.* addons, but allways i get compilation error:

In file included from local_proto.h:1:0,
from stream_vector.c:1:
io.h:8:27: fatal error: grass/glocale.h: File does not exists
compilation terminated.
make: *** [OBJ.x86_64-unknown-linux-gnu/stream_vector.o] Error 1

With r.traveltime I get similar error, but gis.h is missing.

Both files are in /opt/grass/include/grass/ and GRASS was build with unmodified PKGBUILD. Both extensions works well with GRASS 6.4.5.

Excuse me, if I am just silly.

Thank you
Peter

Scimmia commented on 2015-10-09 13:25

@kuszi, added, thanks!

kuszi commented on 2015-10-09 09:08

Hello!

I've successfully installed this package through pamac under Antergos (BTW: against arch official repositories, Antergos has no business with it).

Thanks for the Grass version 7!

When I started the GUI it exited with error. It seems that svn was not installed but it is necessary for the grass extension manager (g.extension)

Is there a way to add svn as a prerequisite package (Dependencies)? Or could I do it here? I'm new to Arch, old to grass GIS :)

thanks
Robert

czk commented on 2015-10-04 16:53

You can't admit an error, your problem.

Scimmia commented on 2015-10-04 16:49

Yep, congratulations, you badgered and pestered your way into getting the response you wanted all along.

czk commented on 2015-10-04 16:22

Now this is the kind of response I expected given your attitue so far. Get off your high horse, mister :D. Your build script has issues. Fix it or I'll fork it.

Scimmia commented on 2015-10-04 14:49

I'm done arguing about theoretical issues here. You abandoned the package, deal with it.

czk commented on 2015-10-04 11:59

And going back to $GRASS_PYTHON - even if indeed addons use it, you would need to make sure it's set to python2 by default in your GRASS package.

Really, a symlink is just as safe, simple and reliable as it gets. No error-prone shebang patching needed, no need to bother about $GRASS_PYTHON. It just works.

See more from GRASS devs on that issue: https://lists.osgeo.org/pipermail/grass-dev/2013-January/061356.html, https://lists.osgeo.org/pipermail/grass-dev/2013-January/061367.html.

czk commented on 2015-10-04 11:04

> For CPPFLAGS, look at the two lines above that. That's really what CPPFLAGS does anyway.

Why are you mixing CPPFLAGS into CXXFLAGS and CFLAGS and then drop CPPFLAGS? What if the build recognizes CPPFLAGS, like GRASS build does? See configure, lib/python/ctypes/Makefile, aclocal.m4. I believe you must have had a good reson to do it this way, but I don't understand it yet.

> --with-nls doesn't have any extra deps, but balloons the package pretty good.

Why are you concerned about few MBs?

> I'm thinking --with-liblas will be left out,

Why disable LIDAR support in GRASS 7?

Scimmia commented on 2015-10-04 00:05

For CPPFLAGS, look at the two lines above that. That's really what CPPFLAGS does anyway.

I'm not saying everything left out was of limited value; as I said, the point was to get this going with the defaults. It appears that --with-pthread and --with-netcdf are both useful without pulling in any extra deps, so I'll enable those. --with-nls doesn't have any extra deps, but balloons the package pretty good. Probably still worth it. I'm thinking --with-liblas will be left out, though.

I looked into how things were called when I was redoing things, I'm pretty sure things are specifically called with $GRASS_PYTHON. It is possible I misunderstood something, though.

czk commented on 2015-10-03 23:56

> I'm not dropping the user's CPPFLAGS.

I'm missing something then. What does the `unset CPPFLAGS' do?

> --with-cxx is the default

I missed --with-cxx being enabled by default in G7 these days.

> for things of limited value

Parallel r.mapcalc is not something to give up on too easily.

> aren't those addons called with "$GRASS_PYTHON" instead of just run directly?

Hmm, I don't know, yet. Are you sure that it works this way?

Scimmia commented on 2015-10-03 23:18

--with-cxx is the default, so I'm not touching that. I had thought about --with-pthread but hadn't looked into it.

As for the others, I'm reluctant to pull in too many deps, especially from the AUR, for things of limited value. I'll look into netcdf and nls more.

The main goal here was to get this all working again with default settings. We can look into things from there.

czk commented on 2015-10-03 22:59

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

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

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

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.