[gdal-dev] GDAL 3.1.0 RC2 available

[Even Rouault]

Roger,

For my understanding, are the failing tests mentioned by Bas maintained by the rgdal project 
?
I assume they must be run by
https://salsa.debian.org/r-pkg-team/r-cran-rgdal/-/blob/master/debian/tests/run-unit-test
and the actual tests are:
https://salsa.debian.org/r-pkg-team/r-cran-rgdal/-/tree/master/tests

Looking at
https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-rgdal/5203587/log.gz  , 
there doesn't seem to be much detail about what fails exactly.

Seeing
https://salsa.debian.org/r-pkg-team/r-cran-rgdal/-/blob/master/tests/
srs_rendering.Rout.save
and explicit mentions to PROJ and GDAL versions (6.0.0 and 2.4.0), if this .Rout.save file is 
compared to the output of tests against newer versions, that would be a likely explanation 
for at least a few failures.

The following message in the log is also a bit strange:
"""
 Loaded GDAL runtime: GDAL 3.1.0, released 2020/04/28
   but rgdal build and GDAL runtime not in sync:
   ... consider re-installing rgdal!!
"""
I'd assume everything to match perfectly in a Debian build env.

> Further, I don't know whether that is running ASAN, valgrind,
> or other CI variants. My feeling is often that CI is strewn with lots of
> false positives and negatives, and that manual testing (the old way) is
> actually effective.

I'm not sure to understand the message about CI. Some tests may be brittle and need to be 
adjusted/removed if needed, but that's considered a good practice to have automated tests. 
And running them under ASAN or valgrind is quite useful, I'd say even almost a requirement 
when you deal with native code that is very prone to a number of errors.

Anyway, I'll trust your judgment that things seem to be good on the rgdal side.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200503/b2863138/attachment-0001.html>