On August 18, 2015 4:24:02 AM EDT, Sebastiaan Couwenberg <sebas...@xs4all.nl> 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. > >Kind Regards, > >Bas
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. Scott K
