Hi,
in past days [1] several tests related to t.connect were failing with the following error message [2]:
Process ended with non-zero return code g.mapset(mapset=‘test1’, flags=u’c’). See the following errors:
ERROR: There appears to be an active GRASS session in selected mapset
The tests are unique because they are creating custom Mapsets and switching into them. I committed a fix for the tests [r64641] which should be applied anyway and documented what is needed in these cases [r64642]. However, the tests were happily running for quite some time and I’m not sure what caused the Mapsets to contain the lock.
It seems as a local problem, I was not able to reproduce it on other machine, but I don’t have an idea what would be the problem on the testing server. I’m just little bit worried if there might be some unexpected change between r64535 (day before the potential problem), r64546 (day before failed tests) and r64581 (first day with failed tests) [3]. It’s probably nothing but I just wanted to let everybody know if somebody would have some doubts too.
Vaclav
[1] http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/index.html
[2] http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-02-12-08-00/report_for_nc_spm_08_grass7_nc/temporal/t.connect/test_distr_tgis_db_raster/index.html
[3] https://trac.osgeo.org/grass/log/grass/trunk?rev=64581&stop_rev=64535
https://trac.osgeo.org/grass/changeset/64641
https://trac.osgeo.org/grass/changeset/64642
BTW, I did also some PEP8 and Pylint cleaning in the files. Please, use these tools to check the Python files. Please check wiki, doc, and tools directory for more info:
http://grasswiki.osgeo.org/wiki/Tools_for_Python_programming
http://grass.osgeo.org/grass71/manuals/libpython/gunittest_testing.html#analyzing-quality-of-source-code
https://trac.osgeo.org/grass/browser/grass/trunk/tools
