[GRASS-dev] GRASS 7: openSUSE RPMLint issues

Hi,

there is a new GRASS 7.svn package (thanks to Angelos Tzotsos) for openSUSE:

https://build.opensuse.org/package/show?package=grass7&project=Application%3AGeo

looking at the "Rpmlint Results" there I found some issues we should fix (how?):

grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_dbmidriver.7.0.svn.so exit@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_dbmidriver.7.0.svn.so exit@@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_linkm.7.0.svn.so exit@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_linkm.7.0.svn.so exit@@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_interpdata.7.0.svn.so exit@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_interpdata.7.0.svn.so exit@@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_g3d.7.0.svn.so exit@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_g3d.7.0.svn.so exit@@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_driver.7.0.svn.so exit@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_driver.7.0.svn.so exit@@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_sqlp.7.0.svn.so exit@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_sqlp.7.0.svn.so exit@@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_cdhc.7.0.svn.so exit@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_cdhc.7.0.svn.so exit@@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_dig2.7.0.svn.so exit@GLIBC_2.0
grass7.i586: W: shared-lib-calls-exit
/opt/grass/lib/libgrass_dig2.7.0.svn.so exit@@GLIBC_2.0
This library package calls exit() or _exit(), probably in a non-fork()
context. Doing so from a library is strongly discouraged - when a library
function calls exit(), it prevents the calling program from handling the
error, reporting it to the user, closing files properly, and cleaning up any
state that the program has. It is preferred for the library to return an
actual error code and let the calling program decide how to handle the
situation.

grass7.i586: W: script-without-shebang /opt/grass/tools/html.py
grass7.i586: W: script-without-shebang /opt/grass/tools/groff.py
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed. If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

grass7.i586: W: python-bytecode-inconsistent-mtime
/opt/grass/etc/gui/wxpython/mapdisp/mapwindow.pyc 2012-10-05T20:31:15
/opt/grass/etc/gui/wxpython/mapdisp/mapwindow.py 2012-10-05T20:31:14
The timestamp embedded in this python bytecode file isn't equal to the mtime
of the original source file, which will force the interpreter to recompile the
.py source every time, ignoring the saved bytecode.

grass7.i586: W: non-executable-script
/opt/grass/etc/gui/wxpython/swipe/main.py 0644L /usr/bin/env
This text file contains a shebang or is located in a path dedicated for
executables, but lacks the executable bits and cannot thus be executed. If
the file is meant to be an executable script, add the executable bits,
otherwise remove the shebang or move the file elsewhere.

grass7.i586: W: invalid-license GPL
grass7-devel.i586: W: invalid-license GPL
grass7-docs.i586: W: invalid-license GPL
grass7.src: W: invalid-license GPL
The specified license string is not recognized. Please refer to
http://license.opensuse.org/ for the list of known licences and their exact
spelling.

Here is the new License string lookup table (see also http://spdx.org/
- Software Package Data Exchange):
https://docs.google.com/spreadsheet/pub?key=0AqPp4y2wyQsbdGQ1V3pRRDg5NEpGVWpubzdRZ0tjUWc
--> It would be "GPL-2.0+"

If that's valid also for other distros, should we change that?

Markus

Markus Neteler wrote:

there is a new GRASS 7.svn package (thanks to Angelos Tzotsos) for openSUSE:

https://build.opensuse.org/package/show?package=grass7&project=Application%3AGeo

looking at the "Rpmlint Results" there I found some issues we should fix (how?):

grass7.i586: W: shared-lib-calls-exit

Some of these are correct, e.g. libgis and libdbmi_driver.

Some others are consequences of libraries providing their own "fatal
error" handling rather than using G_fatal_error(); those should be
fixed.

You can identify the object files in question using the database
generated by tools/sql.sh, with:

  SELECT * FROM obj_imp WHERE symbol = 'exit' AND object LIKE 'lib/%' ;

grass7.i586: W: script-without-shebang /opt/grass/tools/html.py
grass7.i586: W: script-without-shebang /opt/grass/tools/groff.py
This text file has executable bits set or is located in a path dedicated for
executables, but lacks a shebang and cannot thus be executed. If the file is
meant to be an executable script, add the shebang, otherwise remove the
executable bits or move the file elsewhere.

These shouldn't have executable bits, but they're installed using a
pattern rule for "%.py" which makes all .py files executable. Fixed in
r53328.

grass7.i586: W: python-bytecode-inconsistent-mtime
/opt/grass/etc/gui/wxpython/mapdisp/mapwindow.pyc 2012-10-05T20:31:15
/opt/grass/etc/gui/wxpython/mapdisp/mapwindow.py 2012-10-05T20:31:14
The timestamp embedded in this python bytecode file isn't equal to the mtime
of the original source file, which will force the interpreter to recompile the
.py source every time, ignoring the saved bytecode.

No idea about this, or why it would just be this file.

grass7.i586: W: non-executable-script
/opt/grass/etc/gui/wxpython/swipe/main.py 0644L /usr/bin/env
This text file contains a shebang or is located in a path dedicated for
executables, but lacks the executable bits and cannot thus be executed. If
the file is meant to be an executable script, add the executable bits,
otherwise remove the shebang or move the file elsewhere.

All of the wxPython scripts are installed as non-executable. The GUI
probably fudges the issue by executing them with "python script.py ...".

If these can reasonably be used from outside the GUI, they should have
execute permission and a shebang, otherwise they should have neither.

--
Glynn Clements <glynn@gclements.plus.com>