Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-04 Thread Greg Troxel
Even Rouault writes: >> What I menat is that in the text of NEWS, you should not say that > the C >> ABI is unchanged. A "ABI has not changed" statement implies that > one >> can swap in the new binaries without rebuilding any depending > packages. > > That would be true: you could replace t

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Sebastiaan Couwenberg
On 5/3/20 10:05 PM, Even Rouault wrote: >> It's indeed not possible to make everybody happy, so the question is who >> you do mind the least to make unhappy. >> >> If nothing changes packagers like me will be unhappy because they need >> to reintroduce the virtual dependency for the unstable C++ AB

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Even Rouault
> What I menat is that in the text of NEWS, you should not say that the C > ABI is unchanged. A "ABI has not changed" statement implies that one > can swap in the new binaries without rebuilding any depending packages. That would be true: you could replace the .so of GDAL 3.0 by the one of 3

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Greg Troxel
Even Rouault writes: >> Not 100% sure I followed, but: If you change the shlib major > number, >> you have changed the ABI, even if the symbols are the same. > > Yes, but the reasoning is actually the reverse: the (C++) ABI has > changed, so given libgdal contains both a C and C++ API, we > h

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Even Rouault
> Not 100% sure I followed, but: If you change the shlib major number, > you have changed the ABI, even if the symbols are the same. Yes, but the reasoning is actually the reverse: the (C++) ABI has changed, so given libgdal contains both a C and C++ API, we have to bump th shlib major number.

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Greg Troxel
Even Rouault writes: >> It's indeed not possible to make everybody happy, so the question is who >> you do mind the least to make unhappy. >> >> If nothing changes packagers like me will be unhappy because they need >> to reintroduce the virtual dependency for the unstable C++ ABI. >> >> C-only

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Even Rouault
> It's indeed not possible to make everybody happy, so the question is who > you do mind the least to make unhappy. > > If nothing changes packagers like me will be unhappy because they need > to reintroduce the virtual dependency for the unstable C++ ABI. > > C-only users will be unhappy about h

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Greg Troxel
Sebastiaan Couwenberg writes: > It's indeed not possible to make everybody happy, so the question is who > you do mind the least to make unhappy. > > If nothing changes packagers like me will be unhappy because they need > to reintroduce the virtual dependency for the unstable C++ ABI. > > C-only

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Greg Troxel
Even Rouault writes: > Answering Bas' > >> If you don't want that, then two libraries need to be built with their >> own library versioning. > > and Gregs' > >> This doesn't make sense. The current/revision/age needs to be handled >> differently for the C library and the C++ library, because in

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Sebastiaan Couwenberg
On 5/3/20 9:15 PM, Even Rouault wrote: > Answering Bas' > >> If you don't want that, then two libraries need to be built with their >> own library versioning. > > and Gregs' > >> This doesn't make sense. The current/revision/age needs to be handled >> differently for the C library and the C++ l

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Even Rouault
Answering Bas' > If you don't want that, then two libraries need to be built with their > own library versioning. and Gregs' > This doesn't make sense. The current/revision/age needs to be handled > differently for the C library and the C++ library, because in feature > releases one of them doe

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Greg Troxel
Even Rouault writes: [I'm behind in dealing with gdal, but otherwise would be in the same boat as Bas] > There has been obviously a misunderstanding. The rule we follow is that: > - between GDAL X.Y.Z and X.Y.(Z+1), both C and C++ ABI are stable > - between GDAL X.Y and X.(Y+1), the C ABI is sta

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Sebastiaan Couwenberg
On 5/3/20 8:10 PM, Even Rouault wrote: >> Why wasn't the SONAME bumped to reflect the ABI breakage? > > For me, SONAME bump was meant for the C ABI. I don't think this was intended > for the C++ > one. They share the same library, so the SONAME covers both. If you don't want that, then two lib

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Even Rouault
> Why wasn't the SONAME bumped to reflect the ABI breakage? For me, SONAME bump was meant for the C ABI. I don't think this was intended for the C++ one. > We dropped the virtual dependency that required rebuilding for every > GDAL version change because you claimed that this wasn't required an

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Sebastiaan Couwenberg
On 5/3/20 7:47 PM, Even Rouault wrote: > Looking at what is presumably the native side of ogrListLayers(), > https://salsa.debian.org/r-pkg-team/r-cran-rgdal/-/blob/master/src/ogrsource.cpp#L1090 > > I see it use thes GDAL C++ API. Given that the C++ ABI can change between > GDAL feature > relea

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Sebastiaan Couwenberg
On 5/3/20 7:36 PM, Edzer Pebesma wrote: > 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). GDAL did not bump the SONAME, so it claims to be ABI comp

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Even Rouault
On dimanche 3 mai 2020 19:22:11 CEST 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/52035 > > 87/log.gz , there doesn't seem to be much detail about what fails > > exactly. > > From the

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Edzer Pebesma
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

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread Sebastiaan Couwenberg
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: [--- ..

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-03 Thread 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/

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-02 Thread Roger Bivand
Perhaps crucially, I see no problems with released rgdal 1.4-8 on R 4.0.0 and PROJ 7.0.1 with GDAL 3.1.0RC2, or with devel rgdal trunk SVN rev. 966 and PROJ 7.0.1 with GDAL 3.1.0RC2. The failing cases are with PROJ 7.0.0, and R 3.6.3. Further, I don't know whether that is running ASAN, valgrind, or

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-02 Thread Roger Bivand
Thanks. I've been testing on master, but last built a month ago. Installing RC2 now. Roger - Roger Bivand NHH Norwegian School of Economics, Bergen, Norway -- Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html ___ gdal-dev maili

Re: [gdal-dev] GDAL 3.1.0 RC2 available

2020-05-02 Thread Sebastiaan Couwenberg
Just for the record and in case the R authors are reading along, the test suite for r-cran-rgdal (1.4-8-1) [0] & r-cran-sf (0.9-2+dfsg-1) [1] fail with gdal (3.1.0~rc2+dfsg-1~exp1) from Debian experimental [2]. [0] https://ci.debian.net/data/autopkgtest/unstable/amd64/r/r-cran-rgdal/5203587/log.gz

[gdal-dev] GDAL 3.1.0 RC2 available

2020-04-28 Thread Even Rouault
Hi, I have prepared a second release candidate. The changes since RC1 are: - (reason for this RC2) fix a regression of ./configure regarding linking some dependencies such as GEOS, on older systems that don't support the -E switch of sed - typo fixes - addition of a LICENSE file for gdal_rtd do