GCC 5 transitions, a Debian GIS perspective
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
Reply to: