--- 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.0.
There is no SONAME bump as for 2.0, only the virtual ABI package changed
to account for the C++ symbol changes.
All reverse dependencies rebuilt successfully with GDAL 2.1.0 from
experimental.
libgdal-grass doesn't need a binNMU as the 2.1.0 version will be
uploaded to unstable instead. The initial upload to experimental is
currently in NEW awaiting FTP master review.
Ben file:
title = "gdal";
is_affected = .depends ~ "gdal-abi-2-0-2" | .depends ~ "gdal-abi-2-1-0";
is_good = .depends ~ "gdal-abi-2-1-0";
is_bad = .depends ~ "gdal-abi-2-0-2";
Transition: gdal
libgdal20 (2.0.2+dfsg-5) -> libgdal20 (2.1.0+dfsg-1)
gdal-abi-2-0-2 -> gdal-abi-2-1-0
The status of the most recent rebuilds is as follows.
dans-gdal-scripts (0.23-5) OK
fiona (1.6.3-2) OK
gazebo (7.0.0+dfsg-2) OK
gmt (5.2.1+dfsg-4) OK
imposm (2.6.0+ds-2) OK
libcitygml (2.0-2) OK
liblas (1.8.0-9) OK
libosmium (2.6.1-1) OK
mapcache (1.4.1-2) OK
mapnik (3.0.11+ds-1) OK
mapserver (7.0.1-3) OK
merkaartor (0.18.2-7) OK
mysql-workbench (6.3.4+dfsg-3) OK
ncl (6.3.0-8) OK
node-srs (0.4.8+dfsg-2) OK
openscenegraph (3.2.3+dfsg1-1) OK
osmium (0.0~20160124-b30afd3-1) OK
pdal (1.2.0-2) OK
postgis (2.2.2+dfsg-1) OK
pprepair (0.0~20151110-28dca91-1) OK
prepair (0.7-5) OK
qlandkartegt (1.8.1+ds-5) OK
qmapshack (1.6.1-2) OK
rasterio (0.34.0-1) OK
saga (2.2.4+dfsg-1) OK
sumo (0.25.0+dfsg1-3) OK
thuban (1.2.2-10) OK
vtk6 (6.2.0+dfsg1-11.1 / 6.3.0+dfsg1-1~exp2) OK / OK
xastir (2.0.6-4) OK
grass (7.0.4-1) OK
osgearth (2.7.0+dfsg-1) OK
osmcoastline (2.1.3-1) OK
pktools (2.6.6-1) OK
pyosmium (2.6.0-1) OK
libgdal-grass (2.0.2-2 / 2.1.0-1~exp1) FTBFS / OK
qgis (2.14.1+dfsg-2 / 2.14.2+dfsg-1~exp1) OK / OK
Kind Regards,
Bas
--- End Message ---
--- Begin Message ---
On 27/05/16 11:28, Sebastiaan Couwenberg wrote:
> On 05/27/2016 11:25 AM, Emilio Pozuelo Monfort wrote:
>> On 27/05/16 11:20, Sebastiaan Couwenberg wrote:
>>> On 05/27/2016 11:12 AM, Emilio Pozuelo Monfort wrote:
>>>> On 27/05/16 01:45, Sebastiaan Couwenberg wrote:
>>>>> On 05/22/2016 12:20 PM, Sebastiaan Couwenberg wrote:
>>>>>> On 05/21/2016 11:19 AM, Emilio Pozuelo Monfort wrote:
>>>>>>> On 20/05/16 16:07, Sebastiaan Couwenberg wrote:
>>>>>>>> On 05/20/2016 11:27 AM, Sebastiaan Couwenberg wrote:
>>>>>>>>> On 05/14/2016 11:30 AM, Bas Couwenberg wrote:
>>>>>>>>>> The vtk6 issue on mipsel remains. texlive-bin (2016.20160513.41080-1)
>>>>>>>>>> fixed the FTBFS on most architectures, but still fails on mips, mipsel &
>>>>>>>>>> sparc64. I've reported #824260 for this.
>>>>>>>>>
>>>>>>>>> texlive-bin on mipsel has been fixed, and r-base is now also available
>>>>>>>>> on mipsel which should unblock the mipsel build of vtk6, but that hasn't
>>>>>>>>> started yet.
>>>>>>>>
>>>>>>>> tex-common fails to install on mipsel preventing vtk6 builds. I've
>>>>>>>> reported this in #824862.
>>>>>>>
>>>>>>> Thanks. We're also waiting for the d-i release, as mapnik is waiting for
>>>>>>> harfbuzz which is blocked because of the udeb.
>>>>>>>
>>>>>>> So let's wait a couple of days and see where we stand then.
>>>>>>
>>>>>> The tex-common installation failure can be worked around by installing
>>>>>> the context package.
>>>>>>
>>>>>> The vtk6 build on mipsel is now also blocked by gtk+3.0 being
>>>>>> BD-uninstallable on the all architecture, a source-full upload of
>>>>>> gtk+3.0 should resolve that. I've reported this issue in #824999.
>>>>>
>>>>> The vtk6 build for mipsel is finally here, thanks to the tex-common and
>>>>> gtk+3.0 fixes in their latest uploads.
>>>>
>>>> And to the fact that I bumped its build priority when gtk+ got fixed :)
>>>
>>> I didn't know you could do that. Thank you!
>>>
>>>>> I did not expect the vtk6 build before the end of the weekend, so I
>>>>> updated a couple of rdeps recently which haven't aged 5 days yet.
>>>>> pktools, qgis & otb need one more day, and postgis needs two.
>>>>
>>>> qgis and otb are not in testing so are not a problem. As for pktools, I already
>>>> urgented it a couple of days ago. Let's see if everything migrates in the next
>>>> non-crashy britney run.
>>>
>>> Shouldn't postgis get an urgent hint too then?
>>
>> AFAICS that doesn't depend on gdal-abi-*, only on libgdal. So it doesn't need to
>> migrate with the rest of the packages.
>
> postgis does indeed not depend on the virtual abi package, so it won't
> hinder the migration of gdal. Thank again!
And it's finally in.
Cheers,
Emilio
--- End Message ---