Your message dated Thu, 9 Jan 2025 05:29:48 +0100
with message-id <99b7a182-d5f9-45e7-bfab-091dc5a1c...@xs4all.nl>
and subject line Re: Bug#1086845: transition: gdal
has caused the Debian Bug report #1086845,
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 ow...@bugs.debian.org
immediately.)
--
1086845: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086845
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: g...@packages.debian.org
Control: affects -1 + src:gdal
User: release.debian....@packages.debian.org
Usertags: transition
Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html
For the Debian GIS team I'd like to transition to GDAL 3.10.0.
All reverse dependencies except mysql-workbench and facet-analyser rebuilt
successfully with GDAL 3.10.0 from experimental as summarized below.
mysql-workbench (8.0.32+dfsg-2) FTBFS due to unrelated issues
[-Werror=template-id-cdtor]. (#1085320)
facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) FTBFS due to unrelated
reasons. (#1040334)
Bugreports:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org&tag=gdal-3.10
Transition: gdal
libgdal35 (3.9.3+dfsg-1) -> libgdal36 (3.10.0~rc2+dfsg-1~exp1)
The status of the most recent rebuilds is as follows.
cloudcompare (2.13.2+git20240821+ds-1) OK
fiona (1.10.1-2) OK
gmt (6.5.0+dfsg-3) OK
grass (8.4.0-1) OK
jeolib-miallib (1.1.6-1) OK
libcitygml (2.5.2-1) OK
libgeo-gdal-ffi-perl (0.11-3) OK
libosmium (2.20.0-1) OK
mapcache (1.14.1-1) OK
mapnik (4.0.3+ds-1) OK
mapproxy (3.1.0+dfsg-1) OK
mapserver (8.2.2-1) OK
merkaartor (0.20.0+ds-1) OK
mysql-workbench (8.0.32+dfsg-2) FTBFS (#1085320)
ncl (6.6.2.dfsg.1-8) 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.13.1+dfsg-8) OK
pgsql-ogr-fdw (1.1.5-2) OK
pktools (2.6.7.6+ds-6) OK
postgis (3.5.0+dfsg-1) OK
pyogrio (0.10.0+ds-3) OK
python-django (3:4.2.16-1) OK
qmapshack (1.17.1-1) OK
r-cran-sf (1.0-17+dfsg-1) OK
r-cran-terra (1.7-78-1) OK
rasterio (1.4.2-1) OK
saga (9.6.1+dfsg-1) OK
survex (1.4.12-2) OK
vtk9 (9.3.0+dfsg1-1) OK
facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) FTBFS (#1040334)
libgdal-grass (1:1.0.2-8) OK
opencv (4.6.0+dfsg-14) OK
osmcoastline (2.4.0-2) OK
qgis (3.34.12+dfsg-1) OK
sumo (1.18.0+dfsg-4) OK
Kind Regards,
Bas
--- End Message ---
--- Begin Message ---
On 1/2/25 2:13 PM, Sebastiaan Couwenberg wrote:
On 1/2/25 1:47 PM, Emilio Pozuelo Monfort wrote:
On 01/01/2025 17:28, Sebastiaan Couwenberg wrote:
On 12/31/24 5:10 AM, Sebastiaan Couwenberg wrote:
On 12/30/24 2:17 PM, Sebastiaan Couwenberg wrote:
On 12/30/24 8:34 AM, Sebastiaan Couwenberg wrote:
On 12/29/24 6:26 PM, Sebastiaan Couwenberg wrote:
On 12/29/24 10:45 AM, Emilio Pozuelo Monfort wrote:
On 28/12/2024 09:57, Sebastiaan Couwenberg wrote:
On 11/7/24 10:57 AM, Emilio Pozuelo Monfort wrote:
This is in a very good state, but I think we want to finish openmpi before
acking this.
Can we do this now that the openmpi, hdf5, and python3-defaults transitions
have finished?
mapserver can be hinted out of testing if that helps with the php8.4 transition
entanglement.
Ack. Go ahead.
gdal (3.10.0+dfsg-1) has been uploaded to unstable, and its now built &
installed on all release architectures.
libgdal-grass & qgis can be binNMUed now that grass has been rebuilt on all
release architectures.
ffmpeg may need to get its priority bumped on mips64el as it hasn't been built
there for over two days.
The ffmpeg FTBFS on arm64 (#1091711) blocks the binNMUs for gmt, opencv,
paraview, sumo, and survex.
The libgdal-grass autopkgtest needs to be run with gdal, grass, and libgdal-
grass from unstable because all these packages need to be built with the same
GDAL version.
78s ERROR 1: OGR/GRASS driver was compiled against GDAL 3.9, but the current
library version is 3.10
78s ERROR 1: GDAL/GRASS driver was compiled against GDAL 3.9, but the current
library version is 3.10
That looks like a strict runtime check. Can that be dropped? If not, maybe
libgdal-grass, or its autopkgtests, need a stricter dependency on libgdal? That
would help the autopkgtest run with the right combination of dependencies.
The purpose of the autopkgtest is to verify that all three packages are built
with the same GDAL version, as a stable-update of grass has broken the plugin
in the past.
Britney should schedule the autopkgtest with all packages from unstable that
were rebuilt as part of the transition, or it should use the results that
others have scheduled with all three packages from unstable.
This keeps coming up every gdal transition, the force-skiptest hint by
sramacher help until the above is implemented.
I can also drop the autopkgtest and wait users to notice the plugin breaking
when we again forget to rebuild libgdal-grass after a grass stable update.
Please also binNMU libgdal-grass & mapserver in experimental.
Done.
With mapserver hinted out of testing the old packages got removed from testing.
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
--- End Message ---
