Bug#813916: transition: gdal
On 07/03/16 06:50, Sebastiaan Couwenberg wrote: > What to do about the entanglement with the libvigraimpex transition > (#815153) through saga? > > Should we get saga removed from testing to allow the rest of the > affected packages in the gdal transition to migrate? I'm not sure that'll be necessary, as it looks like libgdal20 can migrate while libgdal1i stays in testing (until those issues are sorted out). We'll see what happens once gdal is old enough, but if that's a problem, then yes, I'll add removal hints as necessary. Cheers, Emilio
Bug#813916: transition: gdal
What to do about the entanglement with the libvigraimpex transition (#815153) through saga? Should we get saga removed from testing to allow the rest of the affected packages in the gdal transition to migrate? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#813916: transition: gdal
On 05/03/16 00:26, Sebastiaan Couwenberg wrote: > Can you also binNMU opencv (3.0.0+dfsg-1~exp2) in experimental with > libgdal20? Sure. Scheduled. Emilio
Bug#813916: transition: gdal
On 04-03-16 00:34, Emilio Pozuelo Monfort wrote: > On 04/03/16 00:21, Sebastiaan Couwenberg wrote: >> On 03-03-16 21:44, Sebastiaan Couwenberg wrote: >>> 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. > > No problem. Scheduled. > >>> 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 >> >> libgdal-grass (2.0.2-1) picked up the old gdal via grass (7.0.3-1) on >> mips, mipsel, mips64el & hurd-i386, these need to binNMUed to build with >> gdal (2.0.2+dfsg-2) & grass (7.0.3-2). The nmu & dw commands are attached. > > Scheduled. Can you also binNMU opencv (3.0.0+dfsg-1~exp2) in experimental with libgdal20? nmu opencv_3.0.0+dfsg-1~exp2 . ALL . experimental . -m "Rebuild with libgdal20" I'll take care of osgearth, osrm & qgis in experimental. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#813916: transition: gdal
On 04/03/16 00:21, Sebastiaan Couwenberg wrote: > On 03-03-16 21:44, Sebastiaan Couwenberg wrote: >> 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. No problem. Scheduled. >> 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 > > libgdal-grass (2.0.2-1) picked up the old gdal via grass (7.0.3-1) on > mips, mipsel, mips64el & hurd-i386, these need to binNMUed to build with > gdal (2.0.2+dfsg-2) & grass (7.0.3-2). The nmu & dw commands are attached. Scheduled. Emilio
Bug#813916: transition: gdal
On 03-03-16 21:44, Sebastiaan Couwenberg wrote: > 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)
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 >
Bug#813916: transition: gdal
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
Bug#813916: transition: gdal
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)
Bug#813916: transition: gdal
On 01/03/16 20:18, Sebastiaan Couwenberg wrote: > Thanks. I'll upload gdal (2.0.2+dfsg-1) to unstable shortly. binNMUs scheduled. Emilio
Processed: Re: Bug#813916: transition: gdal
Processing control commands: > forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html Bug #813916 [release.debian.org] transition: gdal Ignoring request to change the forwarded-to-address of bug#813916 to the same value -- 813916: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813916 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#813916: transition: gdal
Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html On 01/03/16 20:18, Sebastiaan Couwenberg wrote: > On 01-03-16 19:50, Emilio Pozuelo Monfort wrote: >> 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. Ack. >> Let's do this. > > Thanks. I'll upload gdal (2.0.2+dfsg-1) to unstable shortly. Great. Emilio
Bug#813916: transition: gdal
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 >>
Bug#813916: transition: gdal
Control: tags -1 confirmed 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)
Processed: Re: Bug#813916: transition: gdal
Processing control commands: > tags -1 confirmed Bug #813916 [release.debian.org] transition: gdal Added tag(s) confirmed. -- 813916: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813916 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#813916: transition: gdal
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. libgdal-grass (2.0.2-1~exp1) and its dependencies are in experimental now too. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#813916: transition: gdal
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)
Bug#813916: transition: gdal
Control: forwarded -1 https://release.debian.org/transitions/html/gdal-1.11.4.html On 06/02/16 17:43, Bas Couwenberg wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > 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. > > The spatialite->postgis->gdal->spatialite circular dependency was > initially preventing the rebuild of the reverse dependencies with the > new GDAL. Because this was causing more issues [3][4], I've dropped the > liblwgeom dependency from spatialite in 4.3.0a-5. > > Because of the postgis->sfcgal->openscenegraph dependency chain, it's > important to rebuild openscenegraph with the new gdal before rebuilding > postgis, otherwise the old gdal will be pulled in via openscenegraph. > > osrm (4.9.1+ds-1~exp1) only needs to be rebuilt in experimental. > > libgdal-grass (1.11.3-3) doesn't need to be rebuilt, 1.11.4-1 will be > uploaded instead. It requires liblas & grass to be rebuilt first. 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. Cheers, Emilio
Processed: Re: Bug#813916: transition: gdal
Processing control commands: > forwarded -1 https://release.debian.org/transitions/html/gdal-1.11.4.html Bug #813916 [release.debian.org] transition: gdal Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/gdal-1.11.4.html'. -- 813916: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813916 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#813916: transition: gdal
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. Cheers, Emilio
Bug#813916: transition: gdal
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. [0] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gdal-2.0;users=debian-...@lists.debian.org Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#813916: transition: gdal
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition 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. The spatialite->postgis->gdal->spatialite circular dependency was initially preventing the rebuild of the reverse dependencies with the new GDAL. Because this was causing more issues [3][4], I've dropped the liblwgeom dependency from spatialite in 4.3.0a-5. Because of the postgis->sfcgal->openscenegraph dependency chain, it's important to rebuild openscenegraph with the new gdal before rebuilding postgis, otherwise the old gdal will be pulled in via openscenegraph. osrm (4.9.1+ds-1~exp1) only needs to be rebuilt in experimental. libgdal-grass (1.11.3-3) doesn't need to be rebuilt, 1.11.4-1 will be uploaded instead. It requires liblas & grass to be rebuilt first. [0] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gdal-2.0;users=debian-...@lists.debian.org [1] https://lists.debian.org/debian-gis/2016/02/msg00018.html [2] https://lists.debian.org/debian-gis/2016/02/msg00023.html [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808606 [4] https://lists.alioth.debian.org/pipermail/pkg-grass-devel/2016-January/thread.html Only the virtual ABI package changed, so there is no automatically created transition tracker. Ben file: title = "gdal"; is_affected = .depends ~ /libgdal\.so\.1-1\.11\.[34]/; is_good = .depends ~ /libgdal\.so\.1-1\.11\.4/; is_bad = .depends ~ /libgdal\.so\.1-1\.11\.3/; Transition: gdal libgdal1i (1.11.3+dfsg-2) -> libgdal1i (1.11.4+dfsg-1~exp1) libgdal.so.1-1.11.3 -> libgdal.so.1-1.11.4 The status of the most recent rebuilds is as follows. dans-gdal-scripts (0.23-4) OK fiona (1.6.3-1) 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.5.4-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~exp1) 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.5.4-1) OK libgdal-grass (1.11.3-3 / 1.11.4-1) FTBFS / OK qgis (2.8.6+dfsg-1) OK Kind Regards, Bas
