Bug#1023846: transition: gdal
On 11/23/22 19:22, Paul Gevers wrote:
On 23-11-2022 05:28, Sebastiaan Couwenberg wrote:
The libgdal-grass autopkgtest in testing is failing because it
requires gdal, grass, and libgdal-grass from unstable.
https://qa.debian.org/excuses.php?package=gdal
This combination needs to be tested to fix the regressions shown and
unblock testing migration of gdal and the related rebuilt packages.
I'll schedule the set, but I have the feeling that a proper versioned
relation (maybe an upper limit??) is missing somewhere. As there are
quite a few versioned binaries involved already, it's obvious that
there's a design. But if there's a runtime check for a version, ideally
that should be expressed in dependencies too. Unless I'm missing
something of course. (If that dependency would be there, britney would
ask apt to pin packages from the source providing it from unstable if
they are not fulfilled in testing).
"""
ERROR: Module built against version 2022-11-20T19:27:33+00:00 but trying
to use version 2022-10-25T05:34:10+00:00. You need to rebuild GRASS GIS
or untangle multiple installations.
"""
This is not reflected in the dependencies, only the ABI dependency
provided by grass-core is set:
grass820
The dependency is set with a dh_gencontrol override.
This version check in grass is much stricter than it should be, the
builds from the upstream git repo use the commit hash of include
directory to check whether the code using grass is still compatible.
Because this requirement to rebuild libgdal-grass everytime grass is
rebuilt annoyed me, I dug into this issue and had it changed upstream to
use the full GRASS version (e.g. 8.2.0) like the virtual ABI dependency
provided by grass-core for tarball builds.
GRASS 8.2.1 will contain this change, with their release process slower
than expected, it's not sure whether it will be released before the
bookworm freeze.
For future gdal transitions pulling in only the new gdal from unstable
may suffice, although grass from testing still using the old gdal may
cause different problems than just this version check. Like the crssync
segfaults tend that happen with qgis when its dependencies are linked to
different libproj versions.
"""
ERROR 1: OGR/GRASS driver was compiled against GDAL 3.5, but the current
library version is 3.6
ERROR 1: GDAL/GRASS driver was compiled against GDAL 3.5, but the
current library version is 3.6
"""
This is reflected in the libgdal-grass (1:1.0.2-2) dependencies:
libgdal32 (>= 3.6.0)
Those are the normal ${shlibs:Depends} set via symbols files.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023846: transition: gdal
Hi Bas, On 23-11-2022 05:28, Sebastiaan Couwenberg wrote: The libgdal-grass autopkgtest in testing is failing because it requires gdal, grass, and libgdal-grass from unstable. https://qa.debian.org/excuses.php?package=gdal This combination needs to be tested to fix the regressions shown and unblock testing migration of gdal and the related rebuilt packages. I'll schedule the set, but I have the feeling that a proper versioned relation (maybe an upper limit??) is missing somewhere. As there are quite a few versioned binaries involved already, it's obvious that there's a design. But if there's a runtime check for a version, ideally that should be expressed in dependencies too. Unless I'm missing something of course. (If that dependency would be there, britney would ask apt to pin packages from the source providing it from unstable if they are not fulfilled in testing). """ ERROR: Module built against version 2022-11-20T19:27:33+00:00 but trying to use version 2022-10-25T05:34:10+00:00. You need to rebuild GRASS GIS or untangle multiple installations. """ """ ERROR 1: OGR/GRASS driver was compiled against GDAL 3.5, but the current library version is 3.6 ERROR 1: GDAL/GRASS driver was compiled against GDAL 3.5, but the current library version is 3.6 """ Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1023846: transition: gdal
On 11/22/22 21:56, Paul Gevers wrote: On 22-11-2022 11:26, Sebastiaan Couwenberg wrote: How can we schedule autopkgtest runs for testing with gdal & libgdal-grass from unstable? Most of the time britney and autopkgtest handle it automatically if dependencies are rightly versioned (although not ideally during transitions). If you see issues more than a day after a binNMU, please be specific and let us know, then we can check and if needed schedule manually. The libgdal-grass autopkgtest in testing is failing because it requires gdal, grass, and libgdal-grass from unstable. https://qa.debian.org/excuses.php?package=gdal This combination needs to be tested to fix the regressions shown and unblock testing migration of gdal and the related rebuilt packages. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023846: transition: gdal
Hi Bas, On 22-11-2022 11:26, Sebastiaan Couwenberg wrote: How can we schedule autopkgtest runs for testing with gdal & libgdal-grass from unstable? Most of the time britney and autopkgtest handle it automatically if dependencies are rightly versioned (although not ideally during transitions). If you see issues more than a day after a binNMU, please be specific and let us know, then we can check and if needed schedule manually. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1023846: transition: gdal
How can we schedule autopkgtest runs for testing with gdal & libgdal-grass from unstable? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023846: transition: gdal
On 11/20/22 20:19, Sebastiaan Couwenberg wrote: On 11/19/22 20:18, Sebastian Ramacher wrote: On 2022-11-11 11:55:45 +0100, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Control: block -1 by 1023480 1023506 1004795 998833 984398 1023520 1012950 For the Debian GIS team I'd like to transition to GDAL 3.6.0. Please go ahead > Thanks. gdal (3.6.0+dfsg-2) has been uploaded to unstable and took a while to get built on s390x, but is not built & installed on all release architectures. grass is built & installed on all release architectures, libgdal-grass can be binNMUed. qgis had a source upload to fix the FTBFS with python3.11 and cmake 3.25. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1023846: transition: gdal
On 11/19/22 20:18, Sebastian Ramacher wrote: On 2022-11-11 11:55:45 +0100, Bas Couwenberg wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Control: block -1 by 1023480 1023506 1004795 998833 984398 1023520 1012950 For the Debian GIS team I'd like to transition to GDAL 3.6.0. Please go ahead Thanks. gdal (3.6.0+dfsg-2) has been uploaded to unstable and took a while to get built on s390x, but is not built & installed on all release architectures. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Processed: Re: Bug#1023846: transition: gdal
Processing control commands: > tags -1 confirmed Bug #1023846 [release.debian.org] transition: gdal Added tag(s) confirmed. > forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Bug #1023846 [release.debian.org] transition: gdal Ignoring request to change the forwarded-to-address of bug#1023846 to the same value -- 1023846: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023846 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1023846: transition: gdal
Control: tags -1 confirmed Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Hi Bas, On 2022-11-11 11:55:45 +0100, Bas Couwenberg wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-gdal.html > Control: block -1 by 1023480 1023506 1004795 998833 984398 1023520 1012950 > > For the Debian GIS team I'd like to transition to GDAL 3.6.0. Please go ahead Cheers > > Most reverse dependencies rebuilt successfully with GDAL 3.6.0 from > experimental as summarized below. > > > rasterio (1.3.3-1) FTBFS due to test failures (#1023480), this is fixed in > rasterio (1.3.3-2). > > libgdal-grass (1:1.0.1-1) FTBFS due to compile errors (#1023506), this is > fixed in libgdal-grass (1:1.0.1-2). > > gazebo (11.10.1+dfsg-2) FTBFS due to unrelated issues (#1004795). > > mysql-workbench (8.0.26+dfsg-1) FTBFS due to unrelated issues (#998833). > > vtk6 (6.3.0+dfsg2-8.1) FTBFS due to unrelated issues (#984398). > > sumo (1.12.0+dfsg1-1) FTBFS due to unrelated issues (#1023520). > > otb (8.0.1+dfsg-1) FTBFS due to unrelated issues (#1012950). > > > The bugreports can be found via the gdal-3.6 usertag: > > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org=gdal-3.6 > > > Transition: gdal > > libgdal31 (3.5.3+dfsg-1) -> libgdal32 (3.6.0~rc1+dfsg-1~exp1) > > The status of the most recent rebuilds is as follows. > > cloudcompare(2.11.3-7) OK > fiona (1.8.22-1) OK > gazebo (11.10.1+dfsg-2)FTBFS (#1004795) > gmt (6.4.0+dfsg-1) OK > grass (8.2.0-2) OK > libcitygml (2.4.3-1) OK > libosmium (2.18.0-1) OK > mapcache(1.12.1-1) OK > mapnik (3.1.0+ds-2)OK > mapproxy(1.15.1-1) OK > mapserver (8.0.0-2) OK > merkaartor (0.19.0+ds-3) OK > mysql-workbench (8.0.26+dfsg-1) FTBFS (#998833) > ncl (6.6.2-12) OK > octave-mapping (1.4.2-2) OK > openorienteering-mapper (0.9.5-3) OK > openscenegraph (3.6.5+dfsg1-8) OK > paraview(5.11.0~rc1+dfsg-1) OK > pgsql-ogr-fdw (1.1.3-1) OK > pktools (2.6.7.6+ds-3) OK > postgis (3.3.1+dfsg-2) OK > python-django (3:3.2.16-1)OK > qmapshack (1.16.1-1) OK > r-cran-rgdal(1.5-32+dfsg-1) OK > r-cran-sf (1.0-8+dfsg-1) OK > r-cran-terra(1.6-17-1) OK > rasterio(1.3.3-2) OK > saga(8.4.0+dfsg-1) OK > vtk6(6.3.0+dfsg2-8.1) FTBFS (#984398) > vtk7(7.1.1+dfsg2-10.2) OK > vtk9(9.1.0+really9.1.0+dfsg2-4) OK > > libgdal-grass (1:1.0.2-2) OK > opencv (4.6.0+dfsg-7) OK > osmcoastline(2.3.1-1) OK > qgis(3.22.12+dfsg-1)OK > sumo(1.12.0+dfsg1-1)FTBFS (#1023520) > > otb (8.0.1+dfsg-1) FTBFS (#1012950) > > > Kind Regards, > > Bas > -- Sebastian Ramacher
Bug#1023846: transition: gdal
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Control: block -1 by 1023480 1023506 1004795 998833 984398 1023520 1012950 For the Debian GIS team I'd like to transition to GDAL 3.6.0. Most reverse dependencies rebuilt successfully with GDAL 3.6.0 from experimental as summarized below. rasterio (1.3.3-1) FTBFS due to test failures (#1023480), this is fixed in rasterio (1.3.3-2). libgdal-grass (1:1.0.1-1) FTBFS due to compile errors (#1023506), this is fixed in libgdal-grass (1:1.0.1-2). gazebo (11.10.1+dfsg-2) FTBFS due to unrelated issues (#1004795). mysql-workbench (8.0.26+dfsg-1) FTBFS due to unrelated issues (#998833). vtk6 (6.3.0+dfsg2-8.1) FTBFS due to unrelated issues (#984398). sumo (1.12.0+dfsg1-1) FTBFS due to unrelated issues (#1023520). otb (8.0.1+dfsg-1) FTBFS due to unrelated issues (#1012950). The bugreports can be found via the gdal-3.6 usertag: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org=gdal-3.6 Transition: gdal libgdal31 (3.5.3+dfsg-1) -> libgdal32 (3.6.0~rc1+dfsg-1~exp1) The status of the most recent rebuilds is as follows. cloudcompare(2.11.3-7) OK fiona (1.8.22-1) OK gazebo (11.10.1+dfsg-2)FTBFS (#1004795) gmt (6.4.0+dfsg-1) OK grass (8.2.0-2) OK libcitygml (2.4.3-1) OK libosmium (2.18.0-1) OK mapcache(1.12.1-1) OK mapnik (3.1.0+ds-2)OK mapproxy(1.15.1-1) OK mapserver (8.0.0-2) OK merkaartor (0.19.0+ds-3) OK mysql-workbench (8.0.26+dfsg-1) FTBFS (#998833) ncl (6.6.2-12) OK octave-mapping (1.4.2-2) OK openorienteering-mapper (0.9.5-3) OK openscenegraph (3.6.5+dfsg1-8) OK paraview(5.11.0~rc1+dfsg-1) OK pgsql-ogr-fdw (1.1.3-1) OK pktools (2.6.7.6+ds-3) OK postgis (3.3.1+dfsg-2) OK python-django (3:3.2.16-1)OK qmapshack (1.16.1-1) OK r-cran-rgdal(1.5-32+dfsg-1) OK r-cran-sf (1.0-8+dfsg-1) OK r-cran-terra(1.6-17-1) OK rasterio(1.3.3-2) OK saga(8.4.0+dfsg-1) OK vtk6(6.3.0+dfsg2-8.1) FTBFS (#984398) vtk7(7.1.1+dfsg2-10.2) OK vtk9(9.1.0+really9.1.0+dfsg2-4) OK libgdal-grass (1:1.0.2-2) OK opencv (4.6.0+dfsg-7) OK osmcoastline(2.3.1-1) OK qgis(3.22.12+dfsg-1)OK sumo(1.12.0+dfsg1-1)FTBFS (#1023520) otb (8.0.1+dfsg-1) FTBFS (#1012950) Kind Regards, Bas
