Bug#830966: marked as done (transition: gdal)
Your message dated Thu, 21 Jul 2016 19:18:05 +0200
with message-id <fe663460-e4cd-61de-6215-a9beb9d04b3c@debian.org>
and subject line Re: Bug#830966: transition: gdal
has caused the Debian Bug report #830966,
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.)
--
830966: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830966
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
Dear Release Team,
For the Debian GIS team I'd like to transition to GDAL 2.1.1.
Like the previous transition to GDAL 2.1.0 (#823335), there is no SONAME
bump, only the virtual ABI package changed to account for the C++ symbol
changes.
All reverse dependencies rebuilt successfully with GDAL 2.1.1 from
experimental as summarized below.
libgdal-grass doesn't need a binNMU as the 2.1.1 version will be
uploaded to unstable instead. liblas likewise doesn't need a binNMU,
the version is experimental will be moved to unstable instead.
Ben file:
title = "gdal";
is_affected = .depends ~ "gdal-abi-2-1-0" | .depends ~ "gdal-abi-2-1-1";
is_good = .depends ~ "gdal-abi-2-1-1";
is_bad = .depends ~ "gdal-abi-2-1-0";
Transition: gdal
libgdal20 (2.1.0+dfsg-3) -> libgdal20 (2.1.1+dfsg-1~exp1)
gdal-abi-2-1-0 -> gdal-abi-2-1-1
The status of the most recent rebuilds is as follows.
dans-gdal-scripts (0.23-6) OK
fiona (1.7.0.post2-1) OK
gazebo (7.0.0+dfsg-2) OK
gmt (5.2.1+dfsg-6) SKIP (no C++)
imposm (2.6.0+ds-3) SKIP (no C++)
libcitygml (2.0-3) OK
liblas (1.8.0-10) OK
libosmium (2.7.2-1) SKIP (no C++)
mapcache (1.4.1-3) SKIP (no C++)
mapnik (3.0.11+ds-1) OK
mapserver (7.0.1-3) SKIP (no C++)
merkaartor (0.18.2-7 / 0.18.3~rc1-1~exp1) OK / OK
mysql-workbench (6.3.4+dfsg-3) OK
ncl (6.3.0-8) SKIP (no C++)
node-srs (0.4.8+dfsg-2) OK
openscenegraph (3.2.3+dfsg1-2) OK
osmium (0.0~20160425-e2e4368-1) SKIP (no C++)
pdal (1.2.0-4) OK
postgis (2.2.2+dfsg-3) SKIP (no C++)
pprepair (0.0~20160321-87ffae5-1) OK
prepair (0.7-6) OK
qlandkartegt (1.8.1+ds-6) OK
qmapshack (1.6.2-1) OK
rasterio (0.36.0-1) OK
saga (2.2.7+dfsg-2 / 2.3.1+dfsg1-1~exp1) OK / OK
sumo (0.26.0+dfsg1-1) OK
thuban (1.2.2-11) OK
vtk6 (6.3.0+dfsg1-1) OK
xastir (2.0.8-1) SKIP (no C++)
grass (7.0.4-3) SKIP (no C++)
osgearth (2.7.0+dfsg-2) OK
osmcoastline (2.1.3-2) OK
otb (5.4.0+dfsg-2) OK
pktools (2.6.7-2) OK
pyosmium (2.7.1-2) SKIP (no C++)
libgdal-grass (2.1.0-1 / 2.1.1-1~exp1) FTBFS / OK
qgis (2.14.4+dfsg-1) OK
Kind Regards,
Bas
--- End Message ---
--- Begin Message ---
On 15/07/16 11:51, Emilio Pozuelo Monfort wrote:
> On 15/07/16 11:13, Sebastiaan Couwenberg wrote:
>> It looks like #831336 that is preventing the rebuild of vtk6 will cause
>> some delay in the testing migration of the packages involved in this
>> transition.
>>
>> This leaves testing users of the qmapshack package affected by the
>> critial issue reported in #831297. It's been fixed with the new upstream
>> release in unstable, and with a patched backport in jessie-backports.
>>
>> I'd like to fix the version in testing with an upload to
>> testing-proposed-updates including the same patch also used for
>> jessie-backports, to fix the issue in the time mean time until the
>> version from unstable migrates or the automatic removal gets the buggy
>> version out of testing.
>>
>> Does this sound reasonable, or should I just wait for the automatic removal?
>
> I forced the vtk6 build to workaround the dose issue, so that shouldn't block
> the transition. It looks like things are looking well and we just need some ageing.
This is over.
Cheers,
Emilio
--- End Message ---
Reply to: