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

Bug#813916: transition: gdal



On 03-03-16 20:13, Sebastiaan Couwenberg wrote:
> On 03-03-16 19:12, Emilio Pozuelo Monfort wrote:
>> On 01/03/16 20:18, Sebastiaan Couwenberg wrote:
>>> On 01-03-16 19:50, Emilio Pozuelo Monfort wrote:
>>>> On 19/02/16 14:08, Sebastiaan Couwenberg wrote:
>>>>> On 12-02-16 19:05, Emilio Pozuelo Monfort wrote:
>>>>>> On 12/02/16 18:52, Sebastiaan Couwenberg wrote:
>>>>>>> On 12-02-16 18:28, Emilio Pozuelo Monfort wrote:
>>>>>>>> On 06/02/16 17:43, Bas Couwenberg wrote:
>>>>>>>>> Package: release.debian.org
>>>>>>>>> For the Debian GIS team I'd like to transition to the recently released
>>>>>>>>> GDAL 1.11.4. Only the packages using C++ symbols need to be rebuilt.
>>>>>>>>>
>>>>>>>>> GDAL 2.0.2 was released along with 1.11.4, but we still don't have
>>>>>>>>> support for GDAL 2.0 in all reverse dependencies. Since the transition
>>>>>>>>> to GDAL 1.11.3, support for GDAL 2.0 was added to all reverse
>>>>>>>>> depedencies except Fiona [0]. Upstream has recently included changes for
>>>>>>>>> GDAL 2.0, but these differ from the initial GDAL 2.0 changes available
>>>>>>>>> as a patch in #802808. The improved GDAL 2.0 changes are entangled with
>>>>>>>>> other changes for the upcoming Fiona 1.7 release, which I've not been
>>>>>>>>> able to successfully backport. This will not be a blocker for the GDAL
>>>>>>>>> 2.0 transition, as discussed with the maintainer on the debian-gis list
>>>>>>>>> [1].
>>>>>>>>>
>>>>>>>>> Because the transition for GDAL 1.11.4 is ready now, I'd like to do that
>>>>>>>>> first before preparing the transition to GDAL 2.0. All reverse
>>>>>>>>> dependencies rebuilt successfully with GDAL 1.11.4, the summary of
>>>>>>>>> rebuilds is included below.
>>>>>>>>>
>>>>>>>>
>>>>>>>> This would get entangled with the openmpi transition, so it will have to wait.
>>>>>>>> After openmpi, I'm thinking about doing libpng, but we'll see.
>>>>>>>
>>>>>>> Waiting for openmpi is no problem, but if the libpng transition is going
>>>>>>> to happen first, I think it's better to use that time the prepare the
>>>>>>> transition to GDAL 2.0 instead of 1.11.4. Last week the last blocker was
>>>>>>> resolved [0], so we're also pretty much ready to transition to GDAL 2.0.
>>>>>>> The 2.0 packages will have to pass the NEW queue again, because of the
>>>>>>> delay that will cause I've opted to transition to 1.11.4 which is ready now.
>>>>>>>
>>>>>>> If you can confirm that the libpng transition is going to happen first,
>>>>>>> I'll upload the packages for GDAL 2.0 to experimental, and we can switch
>>>>>>> to that in unstable after the libpng transition and the new gdal has
>>>>>>> passed NEW.
>>>>>>
>>>>>> Sure, let's do that.
>>>>>
>>>>> The GDAL 2.0.2 packages are available in experimental and ready for
>>>>> transition.
>>>>>
>>>>> libgdal-grass (2.0.2-1) not available in experimental yet, liblas and
>>>>> grass need to be rebuilt with GDAL 2.0 before it can be built too,
>>>>> because the SOVERSION is included in the binary package it builds the
>>>>> package will have to pass the NEW queue after upload first. To get it
>>>>> passed the NEW queue, I'll rebuild liblas & grass with gdal
>>>>> (2.0.2-1-1~exp2) from experimental and upload all three to experimental too.
>>>>>
>>>>> All reverse dependencies build successfully with GDAL 2.0.
>>>>>
>>>>>
>>>>> Transition: gdal
>>>>>
>>>>>  libgdal1i (1.11.3+dfsg-3) -> libgdal20 (2.0.2+dfsg-1)
>>>>>  libgdal.so.1-1.11.3       -> gdal-abi-2-0-2
>>>>>
>>>>> The status of the most recent rebuilds is as follows.
>>>>>
>>>>>  dans-gdal-scripts (0.23-4)                           OK
>>>>>  fiona             (1.6.3-2)                          OK
>>>>>  gazebo            (6.5.0+dfsg-2)                     OK
>>>>>  gmt               (5.2.1+dfsg-3)                     OK
>>>>>  imposm            (2.6.0+ds-2)                       OK
>>>>>  libcitygml        (2.0-1)                            OK
>>>>>  liblas            (1.8.0-7)                          OK
>>>>>  libosmium         (2.6.0-1)                          OK
>>>>>  mapcache          (1.4.0-4)                          OK
>>>>>  mapnik            (3.0.9+ds-1)                       OK
>>>>>  mapserver         (7.0.0-9)                          OK
>>>>>  merkaartor        (0.18.2-5)                         OK
>>>>>  mysql-workbench   (6.3.4+dfsg-3)                     OK
>>>>>  ncl               (6.3.0-6)                          OK
>>>>>  node-srs          (0.4.8+dfsg-2)                     OK
>>>>>  openscenegraph    (3.2.1-9)                          OK
>>>>>  osmium            (0.0~20160124-b30afd3-1)           OK
>>>>>  osrm              (4.9.1+ds-1~exp2)                  OK
>>>>>  postgis           (2.2.1+dfsg-2)                     OK
>>>>>  pprepair          (0.0~20150624-82a2019-1)           OK
>>>>>  prepair           (0.7-4)                            OK
>>>>>  qlandkartegt      (1.8.1+ds-4)                       OK
>>>>>  qmapshack         (1.5.1-1)                          OK
>>>>>  rasterio          (0.31.0-2)                         OK
>>>>>  saga              (2.2.3+dfsg-1)                     OK
>>>>>  sumo              (0.25.0+dfsg1-2)                   OK
>>>>>  thuban            (1.2.2-9)                          OK
>>>>>  vtk6              (6.2.0+dfsg1-7)                    OK
>>>>>  xastir            (2.0.6-4)                          OK
>>>>>
>>>>>  grass             (7.0.3-1)                          OK
>>>>>  osgearth          (2.5.0+dfsg-8 / 2.7.0+dfsg-1~exp5) OK / OK
>>>>>  osmcoastline      (2.1.2-1)                          OK
>>>>>  pktools           (2.6.6-1)                          OK
>>>>>  pyosmium          (2.6.0-1)                          OK
>>>>>
>>>>>  libgdal-grass     (1.11.3-3 / 2.0.2-1)               FTBFS / OK
>>>>>  qgis              (2.8.6+dfsg-1)                     OK
>>>>
>>>> I guess https://release.debian.org/transitions/html/auto-gdal.html is better
>>>> than https://release.debian.org/transitions/html/gdal-1.11.4.html now?
>>>
>>> Yes, the auto-gdal tracker is better. The tracker for 1.11.4 can be removed.
>>>
>>>> Let's do this.
>>>
>>> Thanks. I'll upload gdal (2.0.2+dfsg-1) to unstable shortly.
>>
>> Looks like gdal-bin is uninstallable on mips64el as it depends on gdal-abi-2-0-1:
> 
> Fixed in gdal (2.0.2+dfsg-2).

The ben file should probably be updated to mark packages depending on
gdal-abi-2-0-1 as bad (e.g. like the attached gdal.ben).

All rdeps on mips64el are affected by this bug and will need to be
rebuilt with gdal (2.0.2+dfsg-2), sorry about that.

I think this requires both new NMUs combined with dep-waits to ensure
they don't rebuild with -1, I've included the list of nmu & dw commands
in the attached gdal_2.0.2+dfsg-2_nmu-dw.txt

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
title = "gdal";
is_affected = .depends ~ /\b(libgdal20|libgdal1\-dev|libgdal1i)\b/;
is_good = .depends ~ /\b(libgdal20|gdal-abi-2-0-2)\b/;
is_bad = .depends ~ /\b(libgdal1\-dev|libgdal1i|gdal-abi-2-0-1)\b/;
nmu dans-gdal-scripts_0.23-5 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw dans-gdal-scripts_0.23-5 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu fiona_1.6.3-2 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw fiona_1.6.3-2 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu gazebo_7.0.0+dfsg-1 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw gazebo_7.0.0+dfsg-1 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu gmt_5.2.1+dfsg-4 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw gmt_5.2.1+dfsg-4 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu libcitygml_2.0-2 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw libcitygml_2.0-2 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu liblas_1.8.0-8 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw liblas_1.8.0-8 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu mapcache_1.4.1-2 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw mapcache_1.4.1-2 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu mapnik_3.0.9+ds-1 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw mapnik_3.0.9+ds-1 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu mapserver_7.0.1-2 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw mapserver_7.0.1-2 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu merkaartor_0.18.2-6 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw merkaartor_0.18.2-6 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu mysql-workbench_6.3.4+dfsg-3 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw mysql-workbench_6.3.4+dfsg-3 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu ncl_6.3.0-8 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw ncl_6.3.0-8 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu node-srs_0.4.8+dfsg-2 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw node-srs_0.4.8+dfsg-2 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu openscenegraph_3.2.1-9 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw openscenegraph_3.2.1-9 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu osmcoastline_2.1.2-2 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw osmcoastline_2.1.2-2 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu postgis_2.2.1+dfsg-3 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw postgis_2.2.1+dfsg-3 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu pprepair_0.0~20151110-28dca91-1 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw pprepair_0.0~20151110-28dca91-1 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu prepair_0.7-5 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw prepair_0.7-5 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu qlandkartegt_1.8.1+ds-5 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw qlandkartegt_1.8.1+ds-5 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu qmapshack_1.6.0-1 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw qmapshack_1.6.0-1 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu rasterio_0.31.0-3 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw rasterio_0.31.0-3 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu saga_2.2.4+dfsg-1 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw saga_2.2.4+dfsg-1 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu sumo_0.25.0+dfsg1-2 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw sumo_0.25.0+dfsg1-2 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu thuban_1.2.2-10 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw thuban_1.2.2-10 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu vtk6_6.2.0+dfsg1-9 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw vtk6_6.2.0+dfsg1-9 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu xastir_2.0.6-4 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw xastir_2.0.6-4 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu grass_7.0.3-2 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw grass_7.0.3-2 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu osgearth_2.5.0+dfsg-8 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw osgearth_2.5.0+dfsg-8 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu pktools_2.6.6-1 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw pktools_2.6.6-1 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu libgdal-grass_2.0.2-1 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw libgdal-grass_2.0.2-1 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"
nmu qgis_2.8.6+dfsg-1 . mips64el . -m "Rebuild with libgdal20 (>= 2.0.2+dfsg-2)"
dw qgis_2.8.6+dfsg-1 . mips64el . -m "libgdal20 (>= 2.0.2+dfsg-2)"

Reply to: