On 18-08-15 14:12, Scott Kitterman wrote: > On August 18, 2015 4:24:02 AM EDT, Sebastiaan Couwenberg wrote: >> On 18-08-15 06:44, Scott Kitterman wrote: >>> On Monday, August 03, 2015 02:20:40 PM Sebastiaan Couwenberg >>> wrote: >>>> On 03-08-15 00:54, Sebastiaan Couwenberg wrote: >>>>> On 01-08-15 16:40, Sebastiaan Couwenberg wrote: >>>>>> The debdiff in case libkml needs to be NMUed is attached. >>>>> >>>>> The debdiff needs to be updated to incorporate the changes for >>>>> todays libkml 1.3.0~rc0 release, the Debian package in >>>>> experimental has been updated to 1.3.0~rc0-1~exp1 but the >>>>> symbols have only been updated for amd64. Due to the icu >>>>> uninstallability the package cannot be built on the other >>>>> architectures at the moment. >>>> >>>> The symbols have been updated and libkml (1.3.0~rc0-1~exp2) >>>> should be available in experimental shortly. >>>> >>>> The updated debdiff for the NMU to unstable is attached. >>> >>> I just test build gdal in unstable against the libkml in >>> experimental. It compiled successfully, but failed do to an issue >>> with the python3 part of the build that I expect is unrelated to >>> gcc5, so I think this should go ahead and go to Unstable. >> >> My build of gdal with with libkml in experimental did not have an >> issue with python3, so that looks good indeed. There are some C++ >> symbols changes that warrant their own transition if we take the >> conservative approach. We have GDAL 1.11 ready in experimental for >> some time now, so maybe we should also start the gdal transition >> (#756867) triggered by these GCC 5 transitions. > > The chroot I did the build in wasn't clean, so you can probably > ignore the problem I had. I think we should get on with libkml and > then gdal, but given the history of the gdal discussion, I think we > should definitely be conservative. If you need gdal looked at in > New after the package name is bumped, feel free to ping me.
Thanks for the feedback, and NEW processing assistance. I've just uploaded libkml (1.3.0~rc0-1) to unstable to kick off this transition. If we move GDAL 1.11 out of experimental for the gdal transition, the packages won't need to pass NEW again. They already contain a SONAME bump so a v5 rename is not required. I just need to update the symbols files for libgdal1i again. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
