[gdal-dev] test failures on pkgsrc build of 3.3.2rc3

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

>> and now have a test run that shows:
>>
>>    = 312 failed, 6939 passed, 1489 skipped, 2 xfailed, 2 warnings in 746.96s (0:12:26) =
>>
>> which seems quite good overall.
>
> For a reasonably well setup environment, you should not get more than
> a handful of failures. 312 definitely indicates something
> wrong. Looking a bit at the logs you provide, they are explicit and

I meant that for a system where test issues were not yet debugged it
didn't seem too bad.  But we are rapidly reducing the count: now down to
20.

> implicit complaints about GDAL_DATA not being set. I'm not sure if
> you're running agains an installed GDAL lib (in which case, there's
> something wrong in your build if it can't find /usr/share/gdal/ or
> whatever similar dir in which GDAL data is installed), or if it a
> in-build GDAL (in which case GDAL_DATA env var must be explicitly set
> as done in setdevenv.sh)

I am running against installed gdal, which was built with configure
fairly normally.  There's a lot of stuff in /usr/pkg/share/gdal.  But,
from trying to look at the dev env setup, I had a bad GDAL_DATA
variable, and that was the problem.

> A number of PROJ related failures can be caused by some grids being
> missing. The 'conus' grid from
> http://download.osgeo.org/proj/proj-datumgrid-1.8.tar.gz (there might
> be others from that package. at least this is the one used for our CI)
> must in particular be installed in /usr/share/proj (or
> 'us_noaa_conus.tif' in PROJ 7 or later)

OK - I have the grids intalled, but it is interesting to note that proj
tests require them not to be installed while gdal tests require them to
be installed.

> It is possible to get a few PROJ related failures from time to time
> given which version you use. Our CI covers a number of versions, but
> not all obviously.

I would hope 6.3.2 is still on the ok list.  Lots of systems are a bit
behind.

> Hum, I suspect you might hit a similar issue as the one for FreeBSD in
> https://github.com/OSGeo/gdal/blob/a95e796f65b26379b0e5c699bacef29f7684f79f/gdal/gcore/gdalopeninfo.cpp#L216
> where fopen("/some/dir", "rb") succeeds.

Separate reply coming about this.  Thanks very much for the pointer,
which saved me a really long time looking into this.



New test log at

http://www.lexort.com/GDAL/

Looks like a lot of this the rtree module in sqlite3, which seems to
think telling you to go back and rebuild something with different
non-default options is a reasonable approach :-(  

I had not previously grasped that rtree was required, and configure
seems not to test for it.   Or perhaps it's not required and the tests
should skip?

But it looks like adjusting sqlite to have rtree will resolve more than
half the remaining errors.

(Thus, the test suite is being highly useful.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210901/1f742705/attachment.sig>