Bug#1055891: transition: gdal
Hi Bas, On 22-11-2023 14:59, Sebastiaan Couwenberg wrote: On 11/22/23 14:47, Paul Gevers wrote: To prevent that manual labor, I can drop the autopkgtest from libgdal-grass as it just hinders testing migration. That's not a solution to the problem I'm trying to address, that will just hide it again. The version mismatches it detects (like #1006446) are less likely since grass got fixed (in 8.2.0-3). Good. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055891: transition: gdal
On 11/22/23 14:47, Paul Gevers wrote: I mean, in the ideal situation, this class of issues is prevented by proper package relations, but I also want to avoid manual labor that's a PITA to maintain and prone to wrong in the future. To prevent that manual labor, I can drop the autopkgtest from libgdal-grass as it just hinders testing migration. The version mismatches it detects (like #1006446) are less likely since grass got fixed (in 8.2.0-3). Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
Hi, On 20-11-2023 12:54, Adrian Bunk wrote: It is a case where a binary tries to load the new soversion of the library and plugins for the old soversion of the library. And, do we (as project) already have established processes where this is expressed correctly in package dependencies? Can that be done automatically (for packages that are likely to need it)? I mean, in the ideal situation, this class of issues is prevented by proper package relations, but I also want to avoid manual labor that's a PITA to maintain and prone to wrong in the future. Paul PS: I'll schedule the tests shortly OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055891: transition: gdal
On Sun, Nov 19, 2023 at 09:34:40AM +0100, Paul Gevers wrote: >... > On 19-11-2023 09:06, Sebastiaan Couwenberg wrote: >... > > grass-core in testing depends on the old libgdal33, hence the need to > > also get grass and libgdal-grass from unstable when running autopkgtest > > with gdal from unstable. > > Why? (In other words, what breaks exactly?) Is this a case where some > binaries load the old library and others load the new one leading to symbol > clashes? It is a case where a binary tries to load the new soversion of the library and plugins for the old soversion of the library. > Paul >... cu Adrian
Bug#1055891: transition: gdal
On 11/19/23 09:34, Paul Gevers wrote: On 19-11-2023 09:06, Sebastiaan Couwenberg wrote: britney only schedules: gdal/3.8.0+dfsg-1 src:gdal from unstable Likely because there is no new version for the libgdal-grass source package, only a binNMU. Well, because there's no relation that tells britney this combination is no good. If there is a newer version of the libgdal-grass source or binary packages britney should also try with those in addition to just gdal. libgdal-grass (1:1.0.2-6+b1) has these dependencies to reflect the tight coupling: grass831 (provided by grass-core) libgdal34 (>= 3.8.0) It *might* [1] be missing the upper limit (or some binary of gdal missing a breaks relation)? In other words, yes, libgdal-grass from unstable will pull in the right (current) version, but libgdal-grass (or other binary from libgdal-grass) in testing doesn't know it's broken with the version of src:gdal from unstable. grass is not the most problematic dependency, gdal is: ERROR 1: OGR/GRASS driver was compiled against GDAL 3.7, but the current library version is 3.8 This will never work with libgdal-grass from testing, you need the version from unstable which was rebuilt as part of the transition. grass-core in testing depends on the old libgdal33, hence the need to also get grass and libgdal-grass from unstable when running autopkgtest with gdal from unstable. Why? (In other words, what breaks exactly?) Is this a case where some binaries load the old library and others load the new one leading to symbol clashes? It should work with the version from testing, the version check in libgdal-grass will succeed with the grass version from testing. Just tested in a trixie chroot, both libgdal-grass and gdal packages from unstable are required, grass from testing suffices. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
Hi, On 19-11-2023 09:06, Sebastiaan Couwenberg wrote: britney only schedules: gdal/3.8.0+dfsg-1 src:gdal from unstable Likely because there is no new version for the libgdal-grass source package, only a binNMU. Well, because there's no relation that tells britney this combination is no good. libgdal-grass (1:1.0.2-6+b1) has these dependencies to reflect the tight coupling: grass831 (provided by grass-core) libgdal34 (>= 3.8.0) It *might* [1] be missing the upper limit (or some binary of gdal missing a breaks relation)? In other words, yes, libgdal-grass from unstable will pull in the right (current) version, but libgdal-grass (or other binary from libgdal-grass) in testing doesn't know it's broken with the version of src:gdal from unstable. grass-core in testing depends on the old libgdal33, hence the need to also get grass and libgdal-grass from unstable when running autopkgtest with gdal from unstable. Why? (In other words, what breaks exactly?) Is this a case where some binaries load the old library and others load the new one leading to symbol clashes? Paul [1] and maybe not, the autopkgtest, binNMU and transitions situation isn't britney's strongest side OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055891: transition: gdal
On 11/19/23 08:54, Paul Gevers wrote: On 19-11-2023 07:32, Sebastiaan Couwenberg wrote: For the libgdal-grass autopkgtest to pass it needs to pull gdal, grass, and libgdal-grass from unstable due to the tight coupling. If it doesn't happen automatically and there is a tight coupling, where is the tight coupling missing in the package relations? britney only schedules: gdal/3.8.0+dfsg-1 src:gdal from unstable Likely because there is no new version for the libgdal-grass source package, only a binNMU. libgdal-grass (1:1.0.2-6+b1) has these dependencies to reflect the tight coupling: grass831 (provided by grass-core) libgdal34 (>= 3.8.0) grass-core in testing depends on the old libgdal33, hence the need to also get grass and libgdal-grass from unstable when running autopkgtest with gdal from unstable. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
Hi On 19-11-2023 07:32, Sebastiaan Couwenberg wrote: For the libgdal-grass autopkgtest to pass it needs to pull gdal, grass, and libgdal-grass from unstable due to the tight coupling. If it doesn't happen automatically and there is a tight coupling, where is the tight coupling missing in the package relations? Paul PS: I didn't check the situation, merely commented on the words in the e-mail that confused me. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055891: transition: gdal
For the libgdal-grass autopkgtest to pass it needs to pull gdal, grass, and libgdal-grass from unstable due to the tight coupling. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
cmake on mips64el will also need a higher priority to unblock the rebuilds of several rdeps. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
grass is now also built & installed on all release architectures. libgdal-grass & qgis can be rebuilt. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
On 11/17/23 07:45, Sebastian Ramacher wrote: On 2023-11-13 18:53:40 +0100, Bas Couwenberg wrote: For the Debian GIS team I'd like to transition to GDAL 3.8.0. Please go ahead. Thanks. gdal (3.8.0+dfsg-1) has been uploaded to unstable and is now built and installed on all release architectures except mips64el, the priority may need to be increased to not have the package in Needs-Build status for three weeks. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1055891: transition: gdal
Control: tags -1 confirmed On 2023-11-13 18:53:40 +0100, Bas Couwenberg wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: g...@packages.debian.org > Control: affects -1 + src:gdal > Control: forwarded -1 > https://release.debian.org/transitions/html/auto-gdal.html > Control: block -1 by 1051433 > > For the Debian GIS team I'd like to transition to GDAL 3.8.0. Please go ahead. Cheers -- Sebastian Ramacher
Bug#1055891: transition: gdal
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: g...@packages.debian.org Control: affects -1 + src:gdal Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Control: block -1 by 1051433 For the Debian GIS team I'd like to transition to GDAL 3.8.0. All reverse dependencies except mysql-workbench rebuilt successfully with GDAL 3.8.0 from experimental as summarized below. mysql-workbench (8.0.32+dfsg-1) FTBFS due to unrelated issues. (#1051433) Transition: gdal libgdal33 (3.7.3+dfsg-1) -> libgdal34 (3.8.0~rc2+dfsg-1~exp1) The status of the most recent rebuilds is as follows. cloudcompare(2.11.3-7.1) OK fiona (1.9.5-1) OK gmt (6.4.0+dfsg-2)OK grass (8.3.1-1) OK libcitygml (2.5.1-1) OK libgeo-gdal-ffi-perl(0.1-3) OK libosmium (2.20.0-1)OK mapcache(1.14.0-2)OK mapnik (3.1.0+ds-4) OK mapproxy(1.16.0+dfsg-1) OK mapserver (8.0.1-2) OK merkaartor (0.19.0+ds-4) OK mysql-workbench (8.0.32+dfsg-1) FTBFS (#1051433) ncl (6.6.2.dfsg.1-2) OK octave-mapping (1.4.2-3) OK openorienteering-mapper (0.9.5-3.1) OK openscenegraph (3.6.5+dfsg1-8) OK paraview(5.11.0+dfsg-2) OK pgsql-ogr-fdw (1.1.4-3) OK pktools (2.6.7.6+ds-4)OK postgis (3.4.0+dfsg-3)OK python-django (3:4.2.6-1) OK qmapshack (1.17.0-1)OK r-cran-rgdal(1.6-7+dfsg-1)OK r-cran-sf (1.0-14+dfsg-1) OK r-cran-terra(1.7-55-1)OK rasterio(1.3.9-2) OK saga(9.2.0+dfsg-1)OK vtk9(9.1.0+really9.1.0+dfsg2-7) OK facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) BD-UNINST libgdal-grass (1:1.0.2-6) OK opencv (4.6.0+dfsg-13) OK osmcoastline(2.4.0-2) OK qgis(3.28.12+dfsg-1) OK sumo(1.18.0+dfsg-3) OK Kind Regards, Bas
