Your message dated Thu, 30 May 2024 15:54:40 +0200
with message-id <ecf63e3c-b0dd-4740-a1a5-aad997780...@debian.org>
and subject line Re: Bug#1070852: transition: gdal
has caused the Debian Bug report #1070852,
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.)
--
1070852: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070852
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.8.0.
All reverse dependencies except python-django and facet-analyser rebuilt
successfully with GDAL 3.9.0 from experimental as summarized below.
python-django (3:4.2.11-1) FTBFS due to unrelated test failures. (#1042637)
facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) FTBFS due to uninstallable
build dependencies. (#1040334)
Bugreports can be found using the gdal-3.9 usertag:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-...@lists.debian.org&tag=gdal-3.9
Transition: gdal
libgdal34t64 (3.8.5+dfsg-1) -> libgdal35 (3.9.0~beta1+dfsg-1~exp1)
The status of the most recent rebuilds is as follows.
cloudcompare (2.11.3-7.1) OK
fiona (1.9.6-1) OK
gmt (6.5.0+dfsg-3) OK
grass (8.3.2-1) OK
libcitygml (2.5.2-1) OK
libgeo-gdal-ffi-perl (0.11-2) OK
libosmium (2.20.0-1) OK
mapcache (1.14.0-4) OK
mapnik (3.1.0+ds-7) OK
mapproxy (2.0.2+dfsg-1) OK
mapserver (8.0.1-4) OK
merkaartor (0.19.0+ds-5) OK
mysql-workbench (8.0.32+dfsg-2) OK
ncl (6.6.2.dfsg.1-7) 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.2+dfsg-6) OK
pgsql-ogr-fdw (1.1.4-3) OK
pktools (2.6.7.6+ds-6) OK
postgis (3.4.2+dfsg-1) OK
python-django (3:4.2.11-1) FTBFS (#1042637)
qmapshack (1.17.1-1) OK
r-cran-sf (1.0-15+dfsg-1) OK
r-cran-terra (1.7-65-1) OK
rasterio (1.3.10-2) OK
saga (9.4.0+dfsg-1) OK
vtk9 (9.1.0+really9.1.0+dfsg2-7.1) OK
facet-analyser (0.0~git20221121142040.6be10b8+ds1-3) FTBFS (#1040334)
libgdal-grass (1:1.0.2-7) OK
opencv (4.6.0+dfsg-13.1) OK
osmcoastline (2.4.0-2) OK
qgis (3.34.6+dfsg-1) OK
sumo (1.18.0+dfsg-3) OK
Kind Regards,
Bas
--- End Message ---
--- Begin Message ---
On 26/05/2024 08:36, Sebastiaan Couwenberg wrote:
On 5/24/24 11:46 AM, Sebastiaan Couwenberg wrote:
On 5/24/24 11:29 AM, Emilio Pozuelo Monfort wrote:
On 24/05/2024 11:02, Sebastiaan Couwenberg wrote:
On 5/24/24 9:30 AM, Emilio Pozuelo Monfort wrote:
If that's the case, gdal should probably break older versions of
libgdal-grass so that that combination is not possible. That will also make
britney happy, otherwise it will block gdal due to the test regression.
gdal, grass, and libgdal-grass just need to be tested together.
I'd rather drop the autopkgtest test than having to maintain the Breaks in
gdal.
*shrug*. If that's a runtime check, then there's an issue with the
dependencies/breaks, as one could have old libgdal-grass with newer gdal (as
is happening in the autopkgtest) and then libgdal-grass is broken.
The dependencies of the rebuilt libgdal-grass correctly reflects the required
versions of gdal & grass.
If it's a check that's being done in libgdal-grass, then maybe that check can
be dropped?
That likely results in silent breakage. The situation is already better since
grass (8.2.0-3) which was patched to not include the build time in the version
check.
The autopkgtest was added to detect the breakage after grass was updated in
stable, but libgdal-grass wasn't rebuilt (#1022768).
With the information that autopkgtest has, the current situation is broken
and testing migration will be (rightly) blocked.
The autopkgtest just needs to use the affected packages from unstable like
we've done before.
I'd schedule these CI jobs myself, but britney ignores test results it did not
schedule itself.
gdal, grass, and libgdal-grass all get rebuilt during gdal transitions,
expecting libgdal-grass from testing to work with only gdal from unstable is a
broken assumption.
What are we going to do about the autopkgtest?
I've retried older jobs created by britney with gdal, grass, and libgdal-grass
from unstable which succeed, and also with only gdal and libgdal-grass from
unstable which likewise succeed as expected.
Jobs I've scheduled myself with gdal and libgdal-grass from unstable fail
because they don't actually use libgdal-grass from unstable as requested.
Because autopkgtests are just a hindrance to testing migration dropping the one
from libgdal-grass makes sense. It doesn't resolve the blocked testing migration
however, because the new revision can't migrate without the new gdal. We'd need
an RC bug to get libgdal-grass autoremoved from testing, make britney use the
autopkgtest results which succeed when using both gdal and libgdal-grass from
unstable, or hint it to ignore the autopkgtest failure.
I have ignored the test so that gdal could migrate, and the lot has gone in.
I think there's a real bug here with partial upgrades (which is something that
we support), but solving it would probably be at the cost of smooth upgrades
(e.g. by making libgdalN+1 break libgdalN), or perhaps adding the breaks in
libgdal-grass. But breaking smooth upgrades is not nice, so maybe we can live
with the status quo.
Cheers,
Emilio
--- End Message ---
