[GRASS-user] grass72 or higher on RHEL6

joerg_robl · February 1, 2017, 10:21am

Dear GRASS Gurus,

I’m using GRASS GIS for research and teaching on a server with a rather old Linux (RHEL6). We use GRASS GIS for processing satellite images (LANDSAT8) which is the main motivation to update to grass72.

I’ve compiled grass from source up to version 7.1 but unfortunately I get compilation errors compiling grass72 or higher (the configure script does not complain about any problems). It seems the compilation problems may be related to the rather old matplotlib (0.9x) while grass requires matplotlib > 1.2. As a result, the GRASS GUI crashes after the startup. Of course it may be possible to compile matplotlib from source, which however requires a higher version of numpy which in turn requires at least python2.7x instead of the installed python 2.6x. Not necessary to say that after compiling and installing python2.7x the wxPhyton libs would also require an update … ! At that point I ended up compiling grass72 on RHEL6.

I’m just wondering if there is a standalone version of GRASS GIS for Linux, similar to the Windows version, where all libs are statically linked and packed together.

Any ideas how to bring grass72 or the bleeding edge 7.3 up and running on RHEL6.

cheers Jörg

annakrat · February 1, 2017, 2:23pm

Hi,

On Wed, Feb 1, 2017 at 5:21 AM, joerg robl <joerg.robl@gmail.com> wrote:

Dear GRASS Gurus,

I’m using GRASS GIS for research and teaching on a server with a rather old
Linux (RHEL6). We use GRASS GIS for processing satellite images (LANDSAT8)
which is the main motivation to update to grass72.

I’ve compiled grass from source up to version 7.1 but unfortunately I get
compilation errors compiling grass72 or higher (the configure script does
not complain about any problems). It seems the compilation problems may be
related to the rather old matplotlib (0.9x) while grass requires matplotlib

1.2. As a result, the GRASS GUI crashes after the startup. Of course it

may be possible to compile matplotlib from source, which however requires a
higher version of numpy which in turn requires at least python2.7x instead
of the installed python 2.6x. Not necessary to say that after compiling and
installing python2.7x the wxPhyton libs would also require an update … ! At
that point I ended up compiling grass72 on RHEL6.

could you show us any errors you are getting during compilation or
startup? Matplotlib is not a core component, so this should be
solvable.

Anna

I’m just wondering if there is a standalone version of GRASS GIS for Linux,
similar to the Windows version, where all libs are statically linked and
packed together.

Any ideas how to bring grass72 or the bleeding edge 7.3 up and running on
RHEL6.

cheers Jörg

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

joerg_robl · February 2, 2017, 7:47am

Dear Anna, All,

Thank you for your response!

Here the results of the configure script that look correct. In this case grass7_trunk.

[jrobl@geo1 grass7_trunk]$ ./configure \

–with-cxx
–with-gdal=/usr/bin/gdal-config
–with-proj --with-proj-share=/usr/share/proj
–with-python=/usr/bin/python-config
–with-geos
–with-sqlite
–with-nls
–with-wxwidgets=/usr/bin/wx-config
–with-fftw
–with-cairo --with-cairo-ldflags=-lfontconfig
–with-freetype --with-freetype-includes=/usr/include/freetype2
–enable-largefile
–without-odbc
checking host system type… x86_64-pc-linux-gnu
checking for gcc… gcc
checking whether the C compiler (gcc ) works… yes
checking whether the C compiler (gcc ) is a cross-compiler… no
checking whether we are using GNU C… yes
checking whether gcc accepts -g… yes
checking for Cygwin environment… no
checking for mingw32 environment… no
checking for executable suffix… no
checking for full floating-point support… yes
checking for pwd… /bin/pwd
checking for source directory… /usr/local/src/GRASS/grass7_trunk
checking for build directory… /usr/local/src/GRASS/grass7_trunk
checking for svnversion… /usr/bin/svnversion
checking for MacOSX App… no
checking for MacOSX architectures… no
checking for MacOSX SDK… no
checking how to build libraries… shared
checking for additional include dirs…
checking for additional library dirs…
checking for a BSD compatible install… /usr/bin/install -c
checking for flex… flex
checking for yywrap in -lfl… no
checking for bison… bison -y
checking for ranlib… ranlib
checking for ar… ar
checking for env… env
checking for perl… /usr/bin/perl
checking how to run the C preprocessor… gcc -E
checking for ANSI C header files… yes
checking for limits.h… yes
checking for termio.h… yes
checking for termios.h… yes
checking for unistd.h… yes
checking for values.h… yes
checking for f2c.h… no
checking for g2c.h… no
checking for sys/ioctl.h… yes
checking for sys/mtio.h… yes
checking for sys/resource.h… yes
checking for sys/time.h… yes
checking for sys/timeb.h… yes
checking for sys/types.h… yes
checking for sys/utsname.h… yes
checking for libintl.h… yes
checking for iconv.h… yes
checking for langinfo.h… yes
checking whether time.h and sys/time.h may both be included… yes
checking for off_t… yes
checking for uid_t in sys/types.h… yes
checking return type of signal handlers… void
checking for Cygwin environment… no
checking for ftime… yes
checking for gethostname… yes
checking for gettimeofday… yes
checking for lseek… yes
checking for nice… yes
checking for time… yes
checking for uname… yes
checking for seteuid… yes
checking for setpriority… yes
checking for setreuid… yes
checking for setruid… no
checking for drand48… yes
checking for putenv… yes
checking for setenv… yes
checking for nanosleep… yes
checking whether setpgrp takes no argument… yes
checking for long long int… yes
checking for W11… no
checking for X… libraries /usr/lib64, headers
checking for dnet_ntoa in -ldnet… no
checking for dnet_ntoa in -ldnet_stub… no
checking for gethostbyname… yes
checking for connect… yes
checking for remove… yes
checking for shmat… yes
checking for IceConnectionNumber in -lICE… yes
checking for library containing cuserid… none required
checking for asprintf… yes
checking for atan… no
checking for atan in -lm… yes
checking for dlsym… no
checking for dlsym in -ldl… yes
checking for iconv… yes
checking for socket… yes
checking for location of zlib includes…
checking for zlib.h… yes
checking for location of zlib library…
checking for deflate in -lz… yes
checking whether to use bzlib… no
checking for location of External PROJ.4 includes…
checking for proj_api.h… yes
checking External PROJ.4 version… 470
checking for location of External PROJ.4 library…
checking for pj_get_def in -lproj… yes
checking for location of External PROJ.4 data files… /usr/share/proj
checking for /usr/share/proj/epsg… yes
checking for nad2bin… /usr/bin/nad2bin
checking whether to use regex… yes
checking for location of regex includes…
checking for regex.h… yes
checking for location of regex library…
checking for regcomp… yes
checking whether to use Readline… no
checking whether to use GDAL… yes
checking for gdal-config… /usr/bin/gdal-config
checking whether to use libLAS… no
checking whether to use PDAL… no
checking whether to use NetCDF… no
checking whether to use GEOS… yes
checking for geos-config… /usr/bin/geos-config
checking for geos_c.h… yes
checking for initGEOS in -lgeos_c… yes
checking whether to use TIFF… yes
checking for location of TIFF includes…
checking for tiffio.h… yes
checking for location of TIFF library…
checking for TIFFOpen in -ltiff… yes
checking whether to use PNG… yes
checking for location of PNG includes…
checking for png.h… yes
checking for location of PNG library…
checking for png_read_image in -lpng… yes
checking whether to use PostgreSQL… no
checking whether to use MySQL… no
checking whether to use SQLite… yes
checking for location of SQLite includes…
checking for sqlite3.h… yes
checking for location of SQLite library…
checking for sqlite3_open in -lsqlite3… yes
checking whether to use OpenGL… yes
checking for location of OpenGL includes…
checking for GL/gl.h… yes
checking for GL/glu.h… yes
checking for location of OpenGL library…
checking for glBegin in -lGL… yes
checking for gluBeginCurve in -lGLU… yes
checking for glXCreatePbuffer… yes
checking for glXCreateGLXPixmap… yes
checking whether to use ODBC… no
checking whether to use FFTW… yes
checking for location of FFTW includes…
checking for fftw3.h… yes
checking for location of FFTW library…
checking for fftw_execute in -lfftw3… yes
checking whether to use BLAS… no
checking whether to use LAPACK… no
checking whether to use Cairo… yes
checking for location of cairo includes…
checking for cairo.h… yes
checking for location of cairo library…
checking for cairo linking flags… -lfontconfig
checking for cairo_create… yes
checking for cairo_xlib_surface_create_with_xrender_format… yes
checking for cairo_xlib_surface_get_xrender_format… yes
checking whether to use FreeType… yes
checking for location of FreeType includes… /usr/include/freetype2
checking for ft2build.h… yes
checking for location of FreeType library…
checking for FT_Init_FreeType in -lfreetype… yes
checking whether to use NLS… yes
checking for gettext… yes
checking whether to use C++… yes
checking for c++… c++
checking whether the C++ compiler (c++ -Wl,–export-dynamic) works… yes
checking whether the C++ compiler (c++ -Wl,–export-dynamic) is a cross-compiler… no
checking whether we are using GNU C++… yes
checking whether c++ accepts -g… yes
checking whether to use openDWG… no
checking whether to use POSIX threads… no
checking whether to use OpenMP… no
checking whether to use OpenCL… no
checking for special C compiler options needed for large files… no
checking for _FILE_OFFSET_BITS value needed for large files… no
checking for _LARGE_FILES value needed for large files… no
checking for _LARGEFILE_SOURCE value needed for large files… no
checking for _LARGEFILE_SOURCE value needed for large files… no
checking for fseeko… yes
checking if system supports Large Files at all… yes
creating ./config.status
creating include/Make/Platform.make
creating include/Make/Doxyfile_arch_html
creating include/Make/Doxyfile_arch_latex
creating include/version.h
creating grass.pc
creating include/config.h
include/config.h is unchanged
Copying config.status to config.status.x86_64-pc-linux-gnu

GRASS is now configured for: x86_64-pc-linux-gnu

Source directory: /usr/local/src/GRASS/grass7_trunk
Build directory: /usr/local/src/GRASS/grass7_trunk
Installation directory: ${prefix}/grass-7.3.svn
Startup script in directory:${exec_prefix}/bin
C compiler: gcc -g -O2
C++ compiler: c++ -g -O2
Building shared libraries: yes
OpenGL platform: X11

MacOSX application: no
MacOSX architectures:
MacOSX SDK:

BLAS support: no
BZIP2 support: no
C++ support: yes
Cairo support: yes
DWG support: no
FFTW support: yes
FreeType support: yes
GDAL support: yes
GEOS support: yes
LAPACK support: no
Large File support (LFS): yes
libLAS support: no
MySQL support: no
NetCDF support: no
NLS support: yes
ODBC support: no
OGR support: yes
OpenCL support: no
OpenGL support: yes
OpenMP support: no
PDAL support: no
PNG support: yes
POSIX thread support: no
PostgreSQL support: no
Readline support: no
Regex support: yes
SQLite support: yes
TIFF support: yes
X11 support: yes

(attachments)

···

2017-02-01 15:23 GMT+01:00 Anna Petrášová <kratochanna@gmail.com>:

Hi,

On Wed, Feb 1, 2017 at 5:21 AM, joerg robl <joerg.robl@gmail.com> wrote:

Dear GRASS Gurus,

I’m using GRASS GIS for research and teaching on a server with a rather old
Linux (RHEL6). We use GRASS GIS for processing satellite images (LANDSAT8)
which is the main motivation to update to grass72.

I’ve compiled grass from source up to version 7.1 but unfortunately I get
compilation errors compiling grass72 or higher (the configure script does
not complain about any problems). It seems the compilation problems may be
related to the rather old matplotlib (0.9x) while grass requires matplotlib

1.2. As a result, the GRASS GUI crashes after the startup. Of course it
may be possible to compile matplotlib from source, which however requires a
higher version of numpy which in turn requires at least python2.7x instead
of the installed python 2.6x. Not necessary to say that after compiling and
installing python2.7x the wxPhyton libs would also require an update … ! At
that point I ended up compiling grass72 on RHEL6.

could you show us any errors you are getting during compilation or
startup? Matplotlib is not a core component, so this should be
solvable.

Anna

I’m just wondering if there is a standalone version of GRASS GIS for Linux,
similar to the Windows version, where all libs are statically linked and
packed together.

Any ideas how to bring grass72 or the bleeding edge 7.3 up and running on
RHEL6.

cheers Jörg

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

martinl · February 2, 2017, 8:10am

Hi,

···

2017-02-02 8:47 GMT+01:00 joerg robl <joerg.robl@gmail.com>:

/usr/local/src/GRASS/grass7_trunk/display/d.linegraph

please go into this directory and run make. What is the result? Ma

–

Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

joerg_robl · February 2, 2017, 8:47am

Dear Martin,

Thank you for you help!

Below are the error messages.

cheers Jörg

···

2017-02-02 9:10 GMT+01:00 Martin Landa <landa.martin@gmail.com>:

Hi,

2017-02-02 8:47 GMT+01:00 joerg robl <joerg.robl@gmail.com>:

/usr/local/src/GRASS/grass7_trunk/display/d.linegraph

please go into this directory and run make. What is the result? Ma

–

Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa

neteler · February 2, 2017, 9:15am

Hi Joerg,

On Thu, Feb 2, 2017 at 9:47 AM, joerg robl <joerg.robl@gmail.com> wrote:

Dear Martin,

Thank you for you help!
Below are the error messages.
cheers Jörg

-------------------------------------------------------------------------------------------------------
GRASS 7.3.svn (xy):/usr/local/src/GRASS/grass7_trunk/display/d.linegraph >
make
VERSION_NUMBER=7.3.svn
/usr/local/src/GRASS/grass7_trunk/dist.x86_64-pc-linux-gnu/tools/g.html2man.py
/usr/local/src/GRASS/grass7_trunk/dist.x86_64-pc-linux-gnu/docs/html/d.linegraph.html
/usr/local/src/GRASS/grass7_trunk/dist.x86_64-pc-linux-gnu/docs/man/man1/d.linegraph.1
Traceback (most recent call last):
  File
"/usr/local/src/GRASS/grass7_trunk/dist.x86_64-pc-linux-gnu/tools/g.html2man.py",
line 77, in <module>
    main()
  File
"/usr/local/src/GRASS/grass7_trunk/dist.x86_64-pc-linux-gnu/tools/g.html2man.py",
line 56, in main
    p.close()
  File "/usr/lib64/python2.6/HTMLParser.py", line 112, in close
    self.goahead(1)
  File "/usr/lib64/python2.6/HTMLParser.py", line 164, in goahead
    self.error("EOF in middle of construct")
  File "/usr/lib64/python2.6/HTMLParser.py", line 115, in error
    raise HTMLParseError(message, self.getpos())
HTMLParser.HTMLParseError: EOF in middle of construct, at line 69, column 8
make: ***
[/usr/local/src/GRASS/grass7_trunk/dist.x86_64-pc-linux-gnu/docs/man/man1/d.linegraph.1]
Error 1

The HTML was broken in the manual page. I have fixed that in trunk r70474.
Please update from SVN.

Can you then also check the other directories:
/usr/local/src/GRASS/grass7_trunk/display/d.barscale
/usr/local/src/GRASS/grass7_trunk/display/d.northarrow
/usr/local/src/GRASS/grass7_trunk/display/d.vect
/usr/local/src/GRASS/grass7_trunk/raster/r.colors
/usr/local/src/GRASS/grass7_trunk/vector/v.colors
/usr/local/src/GRASS/grass7_trunk/temporal/t.rast.colors
/usr/local/src/GRASS/grass7_trunk/man

with changing into then and run "make"?

thanks,
Markus

joerg_robl · February 2, 2017, 9:39am

Dear Markus

Thank you for your help!
Ok, I’ve update to 70474

[jrobl@geo1 grass7_trunk]$ svn up
At revision 70474.

I did make clean, configure and make to recompile grass73

The errors still remain

Errors in:
/usr/local/src/GRASS/grass7_trunk/display/d.barscale
/usr/local/src/GRASS/grass7_trunk/display/d.linegraph
/usr/local/src/GRASS/grass7_trunk/display/d.northarrow
/usr/local/src/GRASS/grass7_trunk/display/d.vect
/usr/local/src/GRASS/grass7_trunk/raster/r.colors
/usr/local/src/GRASS/grass7_trunk/vector/v.colors
/usr/local/src/GRASS/grass7_trunk/temporal/t.rast.colors
/usr/local/src/GRASS/grass7_trunk/man

I manually changed to the directories and did “make”. See below!

cheers Jörg

···

2017-02-02 10:15 GMT+01:00 Markus Neteler <neteler@osgeo.org>:

Hi Joerg,

On Thu, Feb 2, 2017 at 9:47 AM, joerg robl <joerg.robl@gmail.com> wrote:

Dear Martin,

Thank you for you help!
Below are the error messages.
cheers Jörg

GRASS 7.3.svn (xy):/usr/local/src/GRASS/grass7_trunk/display/d.linegraph >
make
VERSION_NUMBER=7.3.svn
/usr/local/src/GRASS/grass7_trunk/dist.x86_64-pc-linux-gnu/tools/g.html2man.py
/usr/local/src/GRASS/grass7_trunk/dist.x86_64-pc-linux-gnu/docs/html/d.linegraph.html
/usr/local/src/GRASS/grass7_trunk/dist.x86_64-pc-linux-gnu/docs/man/man1/d.linegraph.1
Traceback (most recent call last):
File
“/usr/local/src/GRASS/grass7_trunk/dist.x86_64-pc-linux-gnu/tools/g.html2man.py”,
line 77, in
main()
File
“/usr/local/src/GRASS/grass7_trunk/dist.x86_64-pc-linux-gnu/tools/g.html2man.py”,
line 56, in main
p.close()
File “/usr/lib64/python2.6/HTMLParser.py”, line 112, in close
self.goahead(1)
File “/usr/lib64/python2.6/HTMLParser.py”, line 164, in goahead
self.error(“EOF in middle of construct”)
File “/usr/lib64/python2.6/HTMLParser.py”, line 115, in error
raise HTMLParseError(message, self.getpos())
HTMLParser.HTMLParseError: EOF in middle of construct, at line 69, column 8
make: ***
[/usr/local/src/GRASS/grass7_trunk/dist.x86_64-pc-linux-gnu/docs/man/man1/d.linegraph.1]
Error 1

The HTML was broken in the manual page. I have fixed that in trunk r70474.
Please update from SVN.

Can you then also check the other directories:
/usr/local/src/GRASS/grass7_trunk/display/d.barscale
/usr/local/src/GRASS/grass7_trunk/display/d.northarrow
/usr/local/src/GRASS/grass7_trunk/display/d.vect
/usr/local/src/GRASS/grass7_trunk/raster/r.colors
/usr/local/src/GRASS/grass7_trunk/vector/v.colors
/usr/local/src/GRASS/grass7_trunk/temporal/t.rast.colors
/usr/local/src/GRASS/grass7_trunk/man

with changing into then and run “make”?

thanks,
Markus

neteler · February 2, 2017, 2:40pm

Hi Anna,

On Wed, Feb 1, 2017 at 3:23 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Wed, Feb 1, 2017 at 5:21 AM, joerg robl <joerg.robl@gmail.com> wrote:

...

I’ve compiled grass from source up to version 7.1 but unfortunately I get
compilation errors compiling grass72 or higher (the configure script does
not complain about any problems). It seems the compilation problems may be
related to the rather old matplotlib (0.9x) while grass requires matplotlib

1.2. As a result, the GRASS GUI crashes after the startup. Of course it

may be possible to compile matplotlib from source, which however requires a
higher version of numpy which in turn requires at least python2.7x instead
of the installed python 2.6x. Not necessary to say that after compiling and
installing python2.7x the wxPhyton libs would also require an update … ! At
that point I ended up compiling grass72 on RHEL6.

could you show us any errors you are getting during compilation or
startup? Matplotlib is not a core component, so this should be
solvable.

I am currently trying to compile 7.2 on EPEL6 using Fedora's COPR platform.

At time I struggle here:
DEBUG util.py:435: Error: No Package found for python-matplotlib-wx
see
https://copr-be.cloud.fedoraproject.org/results/neteler/grass72_epel6/epel-6-x86_64/00502967-grass/root.log.gz

with which configure flag can I disable this part since
python-matplotlib-wx will not be there (I tried for a while to compile
that but no way it seems)?

thanks
Markus

wenzeslaus · February 2, 2017, 2:40pm

On Thu, Feb 2, 2017 at 2:47 AM, joerg robl <joerg.robl@gmail.com> wrote:

ret.append('name={}'.format(tnode.get('name').strip()))
ValueError: zero length field name in format

This is Python 2.6 versus 2.7. I'll look into that.

annakrat · February 2, 2017, 2:55pm

On Thu, Feb 2, 2017 at 9:40 AM, Markus Neteler <neteler@osgeo.org> wrote:

Hi Anna,

On Wed, Feb 1, 2017 at 3:23 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Wed, Feb 1, 2017 at 5:21 AM, joerg robl <joerg.robl@gmail.com> wrote:

...

I’ve compiled grass from source up to version 7.1 but unfortunately I get
compilation errors compiling grass72 or higher (the configure script does
not complain about any problems). It seems the compilation problems may be
related to the rather old matplotlib (0.9x) while grass requires matplotlib

1.2. As a result, the GRASS GUI crashes after the startup. Of course it

may be possible to compile matplotlib from source, which however requires a
higher version of numpy which in turn requires at least python2.7x instead
of the installed python 2.6x. Not necessary to say that after compiling and
installing python2.7x the wxPhyton libs would also require an update … ! At
that point I ended up compiling grass72 on RHEL6.

could you show us any errors you are getting during compilation or
startup? Matplotlib is not a core component, so this should be
solvable.

I am currently trying to compile 7.2 on EPEL6 using Fedora's COPR platform.

At time I struggle here:
DEBUG util.py:435: Error: No Package found for python-matplotlib-wx
see
https://copr-be.cloud.fedoraproject.org/results/neteler/grass72_epel6/epel-6-x86_64/00502967-grass/root.log.gz

I don't understand what I am looking at...
GRASS doesn't need matplotlib for compilation, and there is no
configure flag. I don't know where that error comes from.

with which configure flag can I disable this part since
python-matplotlib-wx will not be there (I tried for a while to compile
that but no way it seems)?

thanks
Markus

neteler · February 2, 2017, 3:20pm

On Thu, Feb 2, 2017 at 3:55 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Thu, Feb 2, 2017 at 9:40 AM, Markus Neteler <neteler@osgeo.org> wrote:

...

https://copr-be.cloud.fedoraproject.org/results/neteler/grass72_epel6/epel-6-x86_64/00502967-grass/root.log.gz

I don't understand what I am looking at...
GRASS doesn't need matplotlib for compilation, and there is no
configure flag. I don't know where that error comes from.

Thanks, this was the hint
python-matplotlib must not go into "BuildRequires:" in the SPEC file
but at most into the "Requires:" section.

I updated accordingly and try again to create a EPEL6 RPM.

Markus

joerg_robl · February 2, 2017, 3:30pm

Dear all,

Thank you for all the effort!

cheers Jörg

···

2017-02-02 16:20 GMT+01:00 Markus Neteler <neteler@osgeo.org>:

On Thu, Feb 2, 2017 at 3:55 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Thu, Feb 2, 2017 at 9:40 AM, Markus Neteler <neteler@osgeo.org> wrote:
…

https://copr-be.cloud.fedoraproject.org/results/neteler/grass72_epel6/epel-6-x86_64/00502967-grass/root.log.gz

I don’t understand what I am looking at…
GRASS doesn’t need matplotlib for compilation, and there is no
configure flag. I don’t know where that error comes from.

Thanks, this was the hint
python-matplotlib must not go into “BuildRequires:” in the SPEC file
but at most into the “Requires:” section.

I updated accordingly and try again to create a EPEL6 RPM.

Markus

wenzeslaus · February 2, 2017, 3:46pm

On Thu, Feb 2, 2017 at 9:40 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Thu, Feb 2, 2017 at 2:47 AM, joerg robl <joerg.robl@gmail.com> wrote:

ret.append('name={}'.format(tnode.get('name').strip()))
ValueError: zero length field name in format

This is Python 2.6 versus 2.7. I'll look into that.

Please (thoroughly) test r70476.

https://trac.osgeo.org/grass/changeset/70476

I did the basic changes using the following command:

for F in `grep --exclude-dir={.svn,.git,OBJ.*,locale,dist.*,html,latex,build}
-IrnE "\{\}.*format" | grep -Ev "\s#" | sed -e "s+$[^:]*$.*+\1+g" | grep
-E "\.py$" | uniq`; do sed -ie "s+${}$$[^{}]*\.format$+{0}\2+g" $F;
done;

and then reviewed the rest using:

grep --exclude-dir={.svn,.git,OBJ.*,locale,dist.*,html,latex,build} -IrnE
"\{\}"

Vaclav

joerg_robl · February 2, 2017, 6:24pm

Dear Vaclav,

I tried r70477 but the errors did not disappear . I also tried your “cryptic” grep command and recompiled the code. However, the errors are still there.

To rule out that this is an issue of our server I tried to compile r70477 on a CentOS6.8 Notebook. The compilation ended with the same errors, which means that this problem will occur on all old Redhat, Fedora and CentOS installations.

Thank you for your help!

cheers

Jörg

···

2017-02-02 16:46 GMT+01:00 Vaclav Petras <wenzeslaus@gmail.com>:

On Thu, Feb 2, 2017 at 9:40 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Thu, Feb 2, 2017 at 2:47 AM, joerg robl <joerg.robl@gmail.com> wrote:

ret.append(‘name={}’.format(tnode.get(‘name’).strip()))
ValueError: zero length field name in format

This is Python 2.6 versus 2.7. I’ll look into that.
Please (thoroughly) test r70476.

https://trac.osgeo.org/grass/changeset/70476

I did the basic changes using the following command:

for F in grep --exclude-dir={.svn,.git,OBJ.*,locale,dist.*,html,latex,build} -IrnE "\{\}.*format" | grep -Ev "\s#" | sed -e "s+$[^:]*$.*+\1+g" | grep -E "\.py$" | uniq; do sed -ie “s+({})([^{}]*.format)+{0}\2+g” $F; done;

and then reviewed the rest using:

grep --exclude-dir={.svn,.git,OBJ.,locale,dist.,html,latex,build} -IrnE “{}”

Vaclav

wenzeslaus · February 2, 2017, 8:05pm

On Thu, Feb 2, 2017 at 1:24 PM, joerg robl <joerg.robl@gmail.com> wrote:

I tried r70477 but the errors did not disappear . I also tried your
"cryptic" grep command and recompiled the code. However, the errors are
still there.

Did you try trunk (7.3)? Since the lines changed the errors can't be
exactly the same (the line is a part of the error message). There might be
some other errors. If that's the case, please post them.

neteler · February 2, 2017, 9:16pm

Hi,

in order to compile GRASS 7.2.0 on EPEL6 I have created backport patches of

https://trac.osgeo.org/grass/changeset/70235 (needed to be able to
apply the next patch)

https://trac.osgeo.org/grass/changeset/70476

This reduces the errors on EPEL6 to:

Errors in:
/builddir/build/BUILD/grass-7.2.0/display/d.barscale
/builddir/build/BUILD/grass-7.2.0/display/d.northarrow
/builddir/build/BUILD/grass-7.2.0/display/d.vect
/builddir/build/BUILD/grass-7.2.0/raster/r.colors
/builddir/build/BUILD/grass-7.2.0/vector/v.colors
/builddir/build/BUILD/grass-7.2.0/temporal/t.rast.colors
/builddir/build/BUILD/grass-7.2.0/man

Still the parser... (and one wx missing - perhaps that could be
changed to lazy import?).

The compile errors can be easily spotted by searching for "Error 1" in the log:
https://copr-be.cloud.fedoraproject.org/results/neteler/grass72_epel6/epel-6-x86_64/00506696-grass/build.log.gz

Markus

wenzeslaus · February 2, 2017, 10:39pm

On Thu, Feb 2, 2017 at 4:16 PM, Markus Neteler <neteler@osgeo.org> wrote:

Hi,

in order to compile GRASS 7.2.0 on EPEL6 I have created backport patches of

https://trac.osgeo.org/grass/changeset/70235 (needed to be able to
apply the next patch)

https://trac.osgeo.org/grass/changeset/70476

This reduces the errors on EPEL6 to:

Errors in:
/builddir/build/BUILD/grass-7.2.0/display/d.barscale
/builddir/build/BUILD/grass-7.2.0/display/d.northarrow
/builddir/build/BUILD/grass-7.2.0/display/d.vect
/builddir/build/BUILD/grass-7.2.0/raster/r.colors
/builddir/build/BUILD/grass-7.2.0/vector/v.colors
/builddir/build/BUILD/grass-7.2.0/temporal/t.rast.colors
/builddir/build/BUILD/grass-7.2.0/man

Still the parser… (and one wx missing - perhaps that could be
changed to lazy import?).

The compile errors can be easily spotted by searching for “Error 1” in the log:
https://copr-be.cloud.fedoraproject.org/results/neteler/grass72_epel6/epel-6-x86_64/00506696-grass/build.log.gz

Markus

This looks like that the 2.6 HTMLParser is more picky about the HTML:

…barscale.html /builddir/build/BUILD/grass-7.2.0/dist.x86_64-redhat-linux-gnu/docs/man/man1/d.barscale.1
Traceback (most recent call last):
File “/builddir/build/BUILD/grass-7.2.0/dist.x86_64-redhat-linux-gnu/tools/g.html2man.py”, line 71, in
main()
File “/builddir/build/BUILD/grass-7.2.0/dist.x86_64-redhat-linux-gnu/tools/g.html2man.py”, line 50, in main
p.close()
File “/usr/lib64/python2.6/HTMLParser.py”, line 112, in close
self.goahead(1)
File “/usr/lib64/python2.6/HTMLParser.py”, line 164, in goahead
self.error(“EOF in middle of construct”)
File “/usr/lib64/python2.6/HTMLParser.py”, line 115, in error
raise HTMLParseError(message, self.getpos())
HTMLParser.HTMLParseError: EOF in middle of construct, at line 54, column 8

The following one will be tricky to fix. It is already a workaround because of some cross dependencies and all GUI depends on wx if not for other reason it is because all depends on globalvar module which needs wx and testing wx is its main purpose. It is a reasonable request not to require wx for build, but if the case is just building in non-GUI requirement there are two other options: make the process ignore all errors (not ideal) or have a switch to build without GUI (that would be advantageous also for the speed).

…python core/menutree.py “manager” >> menustrings.py
Traceback (most recent call last):
File “core/menutree.py”, line 44, in
import wx
ImportError: No module named wx
make[4]: Leaving directory `/builddir/build/BUILD/grass-7.2.0/gui/wxpython’
make[4]: *** [menustrings.py] Error 1

The last one is documentation related. argparse is available only in >2.7 and >3.2, needs some rewrite:

Traceback (most recent call last):
File “./parser_standard_options.py”, line 8, in
import argparse
ImportError: No module named argparse
make[3]: *** [/builddir/build/BUILD/grass-7.2.0/dist.x86_64-redhat-linux-gnu/docs/html/parser_standard_options.html] Error 1

joerg_robl · February 3, 2017, 7:25am

Dear Vaclav,Anna, Markus, Martin,

Sorry for not being concise and thank you again for your help.
Yes I’ve compiled the code of grass7_trunk. In the meantime it is r70474. As I’ve written in my last email, the errors remain.

As I’m not a GRASS developer I’m not very good in explaining the occurring problems. I’ve created a grass test account on our server (RHEL6).

Would such a testing environment be helpful to solve the compilation problems of grass7.2 or higher on RHEL6? In case of “Yes”, I will send login and pw directly.

Thanx Jörg

···

2017-02-02 21:05 GMT+01:00 Vaclav Petras <wenzeslaus@gmail.com>:

On Thu, Feb 2, 2017 at 1:24 PM, joerg robl <joerg.robl@gmail.com> wrote:

I tried r70477 but the errors did not disappear . I also tried your “cryptic” grep command and recompiled the code. However, the errors are still there.

Did you try trunk (7.3)? Since the lines changed the errors can’t be exactly the same (the line is a part of the error message). There might be some other errors. If that’s the case, please post them.

neteler · February 3, 2017, 10:22pm

On Thu, Feb 2, 2017 at 11:39 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Thu, Feb 2, 2017 at 4:16 PM, Markus Neteler <neteler@osgeo.org> wrote:

...

This looks like that the 2.6 HTMLParser is more picky about the HTML:

Apparently yes. I wonder if there is any trick to make it less strict?

I have locally tried to simplify the HTML code of d.barscale,
d.northarrow, d.vect, r.colors, v.colors, t.rast.colors but no
improvement.

Maybe it is not the manual pages of these modules but something in the
parameter/flag part?

It would quite help to know which line is failing, could this be printed?

From the traceback it is not obvious.

The following one will be tricky to fix. It is already a workaround because
of some cross dependencies and all GUI depends on wx if not for other reason
it is because all depends on globalvar module which needs wx and testing wx
is its main purpose. It is a reasonable request not to require wx for build,
but if the case is just building in non-GUI requirement there are two other
options: make the process ignore all errors (not ideal) or have a switch to
build without GUI (that would be advantageous also for the speed).

Yes, probably.

...python core/menutree.py "manager" >> menustrings.py
Traceback (most recent call last):
File "core/menutree.py", line 44, in <module>
import wx
ImportError: No module named wx
make[4]: Leaving directory `/builddir/build/BUILD/grass-7.2.0/gui/wxpython'
make[4]: *** [menustrings.py] Error 1

The last one is documentation related. argparse is available only in >2.7
and >3.2, needs some rewrite:

ok

Traceback (most recent call last):
File "./parser_standard_options.py", line 8, in <module>
import argparse
ImportError: No module named argparse
make[3]: ***
[/builddir/build/BUILD/grass-7.2.0/dist.x86_64-redhat-linux-gnu/docs/html/parser_standard_options.html]
Error 1

thanks,
Markus

neteler · February 7, 2017, 1:49pm

On Thu, Feb 2, 2017 at 4:46 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Thu, Feb 2, 2017 at 9:40 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Thu, Feb 2, 2017 at 2:47 AM, joerg robl <joerg.robl@gmail.com> wrote:

ret.append('name={}'.format(tnode.get('name').strip()))
ValueError: zero length field name in format

This is Python 2.6 versus 2.7. I'll look into that.

Please (thoroughly) test r70476.

https://trac.osgeo.org/grass/changeset/70476

I have locally backported that and created a GRASS GIS 7.2.0 RPM for
EPEL6 from it:
https://copr.fedorainfracloud.org/coprs/neteler/grass72_epel6/

Any objections that I submit the backport? (it requires also r70235).

Markus

PS: remaining Errors in:
/builddir/build/BUILD/grass-7.2.0/display/d.barscale
/builddir/build/BUILD/grass-7.2.0/display/d.northarrow
/builddir/build/BUILD/grass-7.2.0/display/d.vect
/builddir/build/BUILD/grass-7.2.0/raster/r.colors
/builddir/build/BUILD/grass-7.2.0/vector/v.colors
/builddir/build/BUILD/grass-7.2.0/temporal/t.rast.colors
/builddir/build/BUILD/grass-7.2.0/man

The HTML is ok, must be an issue in Python 2.6 versus 2.7 in the HTML parser.