[gdal-dev] GDAL 3.1.0 RC2 available

Edzer Pebesma edzer.pebesma at uni-muenster.de
Sun May 3 10:36:55 PDT 2020


Hi Bas and Even,

I'm the author/maintainer of the sf package; Roger and I both follow
this list actively. Neither Roger nor me have been involved (nor
consulted, at least I wasn't) in the creation of the r-cran-sf or
r-cran-rgdal packages. I'd be happy to check out what is wrong, but have
no clue where to start.

In the r-cran-sf logs, I find:

autopkgtest [09:48:59]: build not needed

But if a new version of GDAL was just installed, a build would have been
needed (assuming we use dynamic linking).

The message you see from rgdal points to the same problem: rgdal seems
be built to GDAL version a, then GDAL version b is installed, then rgdal
is run: this shouldn't happen.

Could it be that the maintainer of both debian packages overlooked this?

I have tested sf earlier against GDAL 3.1.0RC1, and found no problems.

On 5/3/20 7:22 PM, Sebastiaan Couwenberg wrote:
> On 5/3/20 7:09 PM, Even Rouault wrote:
>> 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.
> 
> From the log:
> 
>  autopkgtest [09:49:06]: test run-unit-test: [-----------------------
>  ...
>  BEGIN TEST srs_rendering.R
> 
>  R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
>  Copyright (C) 2020 The R Foundation for Statistical Computing
>  Platform: x86_64-pc-linux-gnu (64-bit)
> 
>  R is free software and comes with ABSOLUTELY NO WARRANTY.
>  You are welcome to redistribute it under certain conditions.
>  Type 'license()' or 'licence()' for distribution details.
> 
>  R is a collaborative project with many contributors.
>  Type 'contributors()' for more information and
>  'citation()' on how to cite R or R packages in publications.
> 
>  Type 'demo()' for some demos, 'help()' for on-line help, or
>  'help.start()' for an HTML browser interface to help.
>  Type 'q()' to quit R.
> 
>  > suppressPackageStartupMessages(library(rgdal))
>  > getPROJ4VersionInfo()
>  [1] "Rel. 7.0.0, March 1st, 2020, [PJ_VERSION: 700]"
>  > getGDALVersionInfo()
>  [1] "GDAL 3.1.0, released 2020/04/28"
>  > d <- system.file("vectors", package="rgdal")
>  > shps <- ogrListLayers(d)
>  terminate called after throwing an instance of 'std::bad_alloc'
>    what():  std::bad_alloc
>  Aborted
>  autopkgtest [09:49:07]: test run-unit-test: -----------------------]
>  autopkgtest [09:49:07]: test run-unit-test:  - - - - - - - - - -
> results - - - - - - - - - -
>  run-unit-test        FAIL non-zero exit status 134
> 
>> 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.
> 
> Nothing has been (re)built with GDAL 3.1.0 yet.
> 
> When packages are uploaded to experimental, autopkgtest is triggered for
> the rdeps in unstable to test for any regressions.
> 
> The same is done when packages are uploaded to unstable, then the
> autopkgtest for the rdeps in testing are triggered. Any regressions
> block the migration of package.
> 
> Kind Regards,
> 
> Bas
> 

-- 
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48149 Muenster, Germany
Phone: +49 251 8333081
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3110 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20200503/67e8ca93/attachment.key>


More information about the gdal-dev mailing list