Thanks to the britney hints by Julien Cristau & Adam D. Barratt the first part of the GCC 5 related transitions have migrated to testing about a month after the start of the GCC 5 related transitions. Because there are still a number of outstanding transitions, I didn't expect testing migration already. So this is very much appreciated, the beginning of the end is here. I initially thought that the remaining GCC 5 related transitions would take until the end of the year (having it done by Christmas would've been a nice present), but we'll likely be done sooner now.
I have some mixed feelings about having spent my vacation handling most of the GCC 5 transitions for the Debian GIS team. I'm happy that we managed to get all our transitions (except hdf5) done during this first phase of the GCC 5 transitions, having several full weeks to dedicate to the transitions was very valuable. At the same time a lot of time was wasted waiting for feedback from the Release Team. Due to the unfortunate timing of starting the GCC 5 transitions at the same time as both Release Managers go on vacation, and the huge number of followup transitions, it's very understandable that the remaining Release Team members couldn't provide feedback to all the outstanding transitions. I very much missed the invaluable input from the Release Team in most of our GCC 5 related transitions. Coordinating transitions with the Release Team and waiting for their go-ahead is the general recommendation, but that unfortunately didn't work very well for the GCC 5 transitions. Big props to Julien Cristau & Jonathan Wiltshire in particular for all their work on the Release Team side for the many transitions. The rebuilds required for the GCC 5 transitions was a good excuse to finally get most our new upstream releases into unstable. As part of the GCC 5 transition we now have GEOS 3.5.0, GDAL 1.11.2, GRASS 7.0.1, QGIS 2.8.3 & osm2pgsql 0.88.1 in testing/unstable. Unfortunately the GRASS support in QGIS had to be disabled to get GRASS 7.0.1 in unstable. We now also have libkml 1.3.0-RC0, this is the first release using the libkml/libkml fork on GitHub. This fork has triggered some Google engineers to get involved in libkml development to revive the long dead project. One of the benefits of the libkml fork is the use of system provided libraries instead of embedded copies of 3rd party libraries. libkml now uses libminizip-dev instead of providing its own libminizip, allowing libkml-dev and libminzip-dev to coexist again. The removal of the 3rd party libraries did require a patch in GDAL to also support building with the libkml fork. I've upstreamed that change, but it hasn't been merged yet. Hopefully the restarted libkml development will manage one or more 1.3.0+ releases during the stretch development cycle so we can switch back to the google/libkml releases on GitHub before the freeze. There are still a few of our packages left that haven't migrated to testing along with gcc-5, most are waiting for protobuf (#791246): * imposm (2.6.0+ds-2) waiting for protobuf, 4 days old, eligible for migration Monday * imposm-parser (1.0.7+ds-1) waiting for protobuf * osmium (0.0~20150428-7f23002-2) waiting for protobuf * osmpbf (1.3.3-5) waiting for protobuf * protozero (1.1.0-5) not waiting for anything, 3 days old, eligible for migration Tuesday * libosmium (2.4.1-3) waiting for protozero, 3 days old, eligible for migration Tuesday * osmium-tool (1.2.1-2) waiting for libosmium, 3 days old, eligible for migration Tuesday * pyosmium (2.4.1-2) waiting for libosmium, 3 days old, eligible for migration Tuesday * ruby-netcdf (0.7.1.1-5) not waiting for anything, 3 days old, eligible for migration Tuesday * sfcgal (1.1.0-5) not waiting for anything, 3 days old, eligible for migration Tuesday * osrm (4.7.1-1) waiting for luabind, protobuf, tbb: - luabind has an RC bug (#795235) preventing testing migration. - tbb is only 0 days old. It must be 5 days old to go in. Only the osrm blockers are a little worrying, we may need to assist the luabind & tbb maintainers to get those packages into testing along with osrm. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
