On 17-08-15 17:32, Sebastiaan Couwenberg wrote: > The API changes don't look very worrying, but I'd like to verify that > all reverse dependencies still build with GEOS 3.5.0 before uploading it > to experimental. I don't want to holdup the GCC 5 transitions in case of > breakage.
I've completed the rebuilds of first dependency level, we need to untangle the spatialite->postgis->gdal->spatialite circular dependency to make the build dependencies for all these packages installable with the new libgeos-c1v5 package. gdal (1.10.1+dfsg-9 / 1.11.2+dfsg-1~exp4) cannot be built because the build dependencies cannot be installed. It at least needs spatialite to be rebuilt with the new geos to not pull in the old libgeos-c1. osm2pgsql (0.88.0-1 / 0.88.1-1) both build successfully with the new geos, because the geos transition hasn't started in unstable yet, it's still not possible to build osm2psql in sid. ossim (1.8.16-4) like gdal cannot be built because the build dependencies cannot be installed. It needs at least gdal to be rebuilt with the new geos first. player (3.0.2+dfsg-4.2) also has uninstallable build dependencies, but these seem unrelated to the packages in the geos transition. The following packages have unmet dependencies: libopenexr6v5 : Conflicts: libopenexr6 but 1.6.1-8 is to be installed. libilmbase6v5 : Conflicts: libilmbase6 but 1.0.1-6.1 is to be installed. libstdc++6 : Breaks: libpqxx-4.0 (<= 4.0.1+dfsg-3) but 4.0.1+dfsg-3 is to be installed. postgis (2.1.8+dfsg-1) will also need gdal & spatialite to be rebuilt with the new geos packages before its build dependencies can be installed. python-shapely (1.4.3-1) needs a patch to not depend on libgeos-c1 which has been renamed to libgeos-c1v5 for the GCC 5 transition. The patch has been forwarded in #795883. The issue was already reported in #795259 so my duplicate bug has been merged. spatialite (4.3.0-1) needs postgis to be rebuilt with the new geos, so but postgis requires gdal & spatialite to be rebuilt first. To untangle this circular dependency we need to dropping the liblwgeom dependency to allow spatialite to rebuild with the new geos, after which we can rebuild gdal and postgis, reinstate the liblwgeom dependency in spatialite and rebuild spatialite & gdal again. Splitting liblwgeom into a separate source package may be an option with PostGIS 2.2. I need to think this issue through some more. It's not specific to the GEOS 3.5.0 update, and affects 3.4.2 v5 libraries for the GCC 5 transition too. Transition: geos libgeos-3.4.2v5 (3.4.2-8~exp3) -> libgeos-3.5.0 (3.5.0-1) libgeos-c1v5 (3.4.2-8~exp3) -> libgeos-c1v5 (3.5.0-1) The status of the most recent rebuilds is as follows. Entries tagged with [+] build successfully after applying the patch from the bugreport. basemap (1.0.7+dfsg-3) OK gdal (1.10.1+dfsg-9 / 1.11.2+dfsg-1~exp4) TODO / TODO osm2pgsql (0.88.0-1 / 0.88.1-1) OK / OK ossim (1.8.16-4) TODO player (3.0.2+dfsg-4.2) TODO postgis (2.1.8+dfsg-1) TODO python-shapely (1.4.3-1 / 1.5.9-1) OK / OK [+] spatialite (4.3.0-1) TODO grass (6.4.4-1 / 7.0.1-1~exp1) TODO / TODO libosmium (2.2.0-1) TODO mapcache (1.4.0-1) TODO mapserver (7.0.0-1) TODO osgearth (2.5.0+dfsg-4 / 2.7.0+dfsg-1~exp2) TODO / TODO osmium (0.0~20150428-7f23002-1) TODO pyspatialite (3.0.1-9) TODO spatialite-gui (2.0.0~devel2-1) TODO spatialite-tools (4.3.0-1) TODO osmcoastline (2.0.1-2) TODO pyosmium (2.2.0-1) TODO qgis (2.8.2+dfsg-3 / 2.8.3+dfsg-1~exp1) TODO / TODO Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
