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
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
