Bug#802222: transition: gdal
On 22/10/15 01:48, Sebastiaan Couwenberg wrote: > On 22-10-15 00:26, Emilio Pozuelo Monfort wrote: >> On 21/10/15 21:30, Sebastiaan Couwenberg wrote: >>> On 21-10-15 21:19, Emilio Pozuelo Monfort wrote: On 18/10/15 16:38, Bas Couwenberg wrote: > Despite only marking the packages relying on C++ symbols as bad, I think > all affected reverse dependencies should be binNMUed as part of this > transition. Why is that? >>> >>> Mostly to be better safe than sorry. >>> If the C ABI is stable, then there's no need to binNMU the rdeps. If it isn't, then you should change the package name. If we binNMU them now, the binNMUs will migrate to testing before the new gdal, which wouldn't be good if there were ABI changes... >>> >>> That's a good point. >> >> Yeah, so let's not do that. Hopefully you've tested the new gdal with some C >> apps that didn't break, that'd be good enough. If something turns out to >> break >> in the end, then you'll have to rename the package... but let's hope that's >> not >> necessary. > > Let's hope that indeed. > >> You can start this. > > Thanks. I've just uploaded gdal (1.11.3+dfsg-1) to unstable. binNMUs scheduled. Cheers, Emilio
Bug#802222: transition: gdal
Control: forwarded -1 https://release.debian.org/transitions/html/gdal-1.11.3.html On 18/10/15 16:38, 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.3 as soon as possible. > > GDAL 2.0.1 was released along with 1.11.3 but several reverse dependencies > still need patches to support GDAL 2.0, as recently discussed on the > debian-gis list: https://lists.debian.org/debian-gis/2015/10/msg00022.html > > gdal (1.11.3+dfsg-1~exp1) is ready in experimental for about a month > now. > > Because of the problematic mix of C & C++ symbols provided by libgdal, > as discussed in the previous transition (#756867), the virtual ABI package > provided by libgdal1i has changed to libgdal.so.1-1.11.3. > > The ben file used to prepare this transition is attached. I think you forgot to attach it? Anyway I've created one. Please check if it looks correct. > Despite only marking the packages relying on C++ symbols as bad, I think > all affected reverse dependencies should be binNMUed as part of this > transition. Why is that? If the C ABI is stable, then there's no need to binNMU the rdeps. If it isn't, then you should change the package name. If we binNMU them now, the binNMUs will migrate to testing before the new gdal, which wouldn't be good if there were ABI changes... > All reverse dependencies build successfully with gdal (1.11.3+dfsg-1~exp1) > from experimental, except gazebo (5.0.1+dfsg-2.1) and > mysql-workbench (6.3.4+dfsg-1) which FTBFS for unrelated reasons. They > both fail to build with plain unstable too. OK that's fine. > libgdal-grass (1.11.2-1) doesn't need a binNMU, libgdal-grass (1.11.3-1) > will be uploaded to unstable instead (after liblas & grass have been > rebuilt). OK. Cheers, Emilio
Bug#802222: transition: gdal
On 21-10-15 21:19, Emilio Pozuelo Monfort wrote: > On 18/10/15 16:38, Bas Couwenberg wrote: >> For the Debian GIS team I'd like to transition to the recently released >> GDAL 1.11.3 as soon as possible. >> >> GDAL 2.0.1 was released along with 1.11.3 but several reverse dependencies >> still need patches to support GDAL 2.0, as recently discussed on the >> debian-gis list: https://lists.debian.org/debian-gis/2015/10/msg00022.html >> >> gdal (1.11.3+dfsg-1~exp1) is ready in experimental for about a month >> now. >> >> Because of the problematic mix of C & C++ symbols provided by libgdal, >> as discussed in the previous transition (#756867), the virtual ABI package >> provided by libgdal1i has changed to libgdal.so.1-1.11.3. >> >> The ben file used to prepare this transition is attached. > > I think you forgot to attach it? Anyway I've created one. > Please check if it looks correct. I guess I did, the ben file used to prepare the transition is now attached, but the one you created will do too. >> Despite only marking the packages relying on C++ symbols as bad, I think >> all affected reverse dependencies should be binNMUed as part of this >> transition. > > Why is that? Mostly to be better safe than sorry. > If the C ABI is stable, then there's no need to binNMU the > rdeps. If it isn't, then you should change the package name. > > If we binNMU them now, the binNMUs will migrate to testing before the new > gdal, which wouldn't be good if there were ABI changes... That's a good point. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 title = "gdal"; is_affected = (.build-depends ~ /libgdal1?-dev/)|(.depends ~ /libgdal1i|libgdal\.so\.1-1\.11\.[23]/); is_good = (.build-depends ~ /libgdal-dev/)|(.depends ~ /libgdal\.so\.1-1\.11\.3/); is_bad = (.build-depends ~ /libgdal1-dev/)|(.depends ~ /libgdal\.so\.1-1\.11\.2/);
Bug#802222: transition: gdal
Control: tags -1 confirmed On 21/10/15 21:30, Sebastiaan Couwenberg wrote: > On 21-10-15 21:19, Emilio Pozuelo Monfort wrote: >> On 18/10/15 16:38, Bas Couwenberg wrote: >>> For the Debian GIS team I'd like to transition to the recently released >>> GDAL 1.11.3 as soon as possible. >>> >>> GDAL 2.0.1 was released along with 1.11.3 but several reverse dependencies >>> still need patches to support GDAL 2.0, as recently discussed on the >>> debian-gis list: https://lists.debian.org/debian-gis/2015/10/msg00022.html >>> >>> gdal (1.11.3+dfsg-1~exp1) is ready in experimental for about a month >>> now. >>> >>> Because of the problematic mix of C & C++ symbols provided by libgdal, >>> as discussed in the previous transition (#756867), the virtual ABI package >>> provided by libgdal1i has changed to libgdal.so.1-1.11.3. >>> >>> The ben file used to prepare this transition is attached. >> >> I think you forgot to attach it? Anyway I've created one. >> Please check if it looks correct. > > I guess I did, the ben file used to prepare the transition is now > attached, but the one you created will do too. OK. >>> Despite only marking the packages relying on C++ symbols as bad, I think >>> all affected reverse dependencies should be binNMUed as part of this >>> transition. >> >> Why is that? > > Mostly to be better safe than sorry. > >> If the C ABI is stable, then there's no need to binNMU the >> rdeps. If it isn't, then you should change the package name. >> >> If we binNMU them now, the binNMUs will migrate to testing before the new >> gdal, which wouldn't be good if there were ABI changes... > > That's a good point. Yeah, so let's not do that. Hopefully you've tested the new gdal with some C apps that didn't break, that'd be good enough. If something turns out to break in the end, then you'll have to rename the package... but let's hope that's not necessary. You can start this. Cheers, Emilio
Bug#802222: transition: gdal
On 22-10-15 00:26, Emilio Pozuelo Monfort wrote: > On 21/10/15 21:30, Sebastiaan Couwenberg wrote: >> On 21-10-15 21:19, Emilio Pozuelo Monfort wrote: >>> On 18/10/15 16:38, Bas Couwenberg wrote: Despite only marking the packages relying on C++ symbols as bad, I think all affected reverse dependencies should be binNMUed as part of this transition. >>> >>> Why is that? >> >> Mostly to be better safe than sorry. >> >>> If the C ABI is stable, then there's no need to binNMU the >>> rdeps. If it isn't, then you should change the package name. >>> >>> If we binNMU them now, the binNMUs will migrate to testing before the new >>> gdal, which wouldn't be good if there were ABI changes... >> >> That's a good point. > > Yeah, so let's not do that. Hopefully you've tested the new gdal with some C > apps that didn't break, that'd be good enough. If something turns out to break > in the end, then you'll have to rename the package... but let's hope that's > not > necessary. Let's hope that indeed. > You can start this. Thanks. I've just uploaded gdal (1.11.3+dfsg-1) to unstable. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#802222: 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.3 as soon as possible. GDAL 2.0.1 was released along with 1.11.3 but several reverse dependencies still need patches to support GDAL 2.0, as recently discussed on the debian-gis list: https://lists.debian.org/debian-gis/2015/10/msg00022.html gdal (1.11.3+dfsg-1~exp1) is ready in experimental for about a month now. Because of the problematic mix of C & C++ symbols provided by libgdal, as discussed in the previous transition (#756867), the virtual ABI package provided by libgdal1i has changed to libgdal.so.1-1.11.3. The ben file used to prepare this transition is attached. Despite only marking the packages relying on C++ symbols as bad, I think all affected reverse dependencies should be binNMUed as part of this transition. All reverse dependencies build successfully with gdal (1.11.3+dfsg-1~exp1) from experimental, except gazebo (5.0.1+dfsg-2.1) and mysql-workbench (6.3.4+dfsg-1) which FTBFS for unrelated reasons. They both fail to build with plain unstable too. libgdal-grass (1.11.2-1) doesn't need a binNMU, libgdal-grass (1.11.3-1) will be uploaded to unstable instead (after liblas & grass have been rebuilt). Transition: gdal libgdal1i (1.11.2+dfsg-3) -> libgdal1i (1.11.3+dfsg-1) libgdal.so.1-1.11.2 -> libgdal.so.1-1.11.3 The status of the most recent rebuilds is as follows. dans-gdal-scripts (0.23-4) OK fiona (1.6.2-1) OK gazebo(5.0.1+dfsg-2.1) FTBFS gmt (5.1.2+dfsg1-2)OK imposm(2.6.0+ds-2) OK libcitygml(2.0-1)OK liblas(1.8.0-5) OK libosmium (2.4.1-3) OK mapcache (1.4.0-4) OK mapnik(3.0.7+ds-4) OK mapserver (7.0.0-5) OK merkaartor(0.18.2-1) OK mysql-workbench (6.3.4+dfsg-1) FTBFS ncl (6.3.0-4~exp2) OK node-srs (0.4.8+dfsg-2) OK openscenegraph(3.2.1-7) OK osmium(0.0~20150428-7f23002-2) OK osrm (4.7.1-2) OK postgis (2.1.8+dfsg-4 / 2.2.0+dfsg-1~exp1) OK / OK pprepair (0.0~20150323-6284890-2) OK prepair (0.7-3)OK qlandkartegt (1.8.1+ds-2) OK qmapshack (1.3.1-1) OK rasterio (0.28.0-1) OK saga (2.2.1+dfsg-1) OK sumo (0.23.0+dfsg1-2) OK thuban(1.2.2-8) OK vtk6 (6.2.0+dfsg1-4)OK xastir(2.0.6-4) OK grass (7.0.1-2) OK osgearth (2.5.0+dfsg-7 / 2.7.0+dfsg-1~exp4) OK / OK osmcoastline (2.1.1-1) OK pktools (2.6.4-3) OK pyosmium (2.4.1-2) OK libgdal-grass (1.11.2-1 / 1.11.3-1) FTBFS / OK qgis (2.8.3+dfsg-3) OK
