[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1023846: marked as done (transition: gdal)



Your message dated Sat, 3 Dec 2022 23:33:30 +0100
with message-id <Y4vOuumRHZQlDGrj@ramacher.at>
and subject line Re: Bug#1023846: transition: gdal
has caused the Debian Bug report #1023846,
regarding transition: gdal
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1023846: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023846
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pkg-grass-devel@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-gis@lists.debian.org&tag=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

--- End Message ---
--- Begin Message ---
On 2022-11-23 19:59:19 +0100, Sebastiaan Couwenberg wrote:
> 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.

The old binaries got removed from testing. Closing.

Cheers
-- 
Sebastian Ramacher

--- End Message ---

Reply to: