Bug#791132: transition: libkml (GCC 5)

[Scott Kitterman <debian@kitterman.com>]

On August 18, 2015 4:24:02 AM EDT, Sebastiaan Couwenberg <sebastic@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