Bug#917323: transition: gdal

[Emilio Pozuelo Monfort <pochu@debian.org>]

On 03/01/2019 17:44, Sebastiaan Couwenberg wrote:
> On 1/3/19 4:39 PM, Sebastiaan Couwenberg wrote:
>> On 1/3/19 4:23 PM, Emilio Pozuelo Monfort wrote:
>>> On 02/01/2019 21:10, Sebastiaan Couwenberg wrote:
>>>> On 1/2/19 12:55 PM, Emilio Pozuelo Monfort wrote:
>>>>> On 26/12/2018 08:46, Bas Couwenberg wrote:
>>>>>> Package: release.debian.org
>>>>>> Severity: normal
>>>>>> User: release.debian.org@packages.debian.org
>>>>>> Usertags: transition
>>>>>>
>>>>>> For the Debian GIS team I'd like to transition to GDAL 2.4.0.
>>>>>>
>>>>>> Like the previous transition to GDAL 2.3.0 (#898566), there is no SONAME
>>>>>> bump, only the virtual ABI package changed to account for the C++ symbol
>>>>>> changes.
>>>>>>
>>>>>> All reverse dependencies rebuilt successfully with GDAL 2.4.0 from
>>>>>> experimental as summarized below, except mysql-workbench due to an
>>>>>> unrelated issue (#914761).
>>>>>>
>>>>>> libgdal-grass doesn't need a binNMU as the 2.4.0 version will be
>>>>>> uploaded to unstable instead. liblas likewise doesn't need a binNMU,
>>>>>> the version is experimental will be moved to unstable instead.
>>>>>
>>>>> Go ahead.
>>>>
>>>> Thanks.
>>>>
>>>> gdal (2.4.0+dfsg-1), liblas (1.8.1-9) & libgdal-grass (2.4.0-1) have
>>>> been uploaded to unstable, and gdal (2.4.0+dfsg-1) is now installed on
>>>> all release architectures.
>>>
>>> Looks like the rebuilt gazebo fails its autopkgtest due to a broken gazebo.pc,
>>> see #918121. That causes migration delays for gdal. No idea where the broken
>>> flag is coming from, I haven't investigated that deep.
>>
>> That looks like @Boost_PKGCONFIG_LIBS@ which is constructed in
>> CMakeLists.txt with:
>>
>>   foreach (b ${Boost_LIBRARIES})
>>     get_filename_component(bname ${b} NAME_WE)
>>     # Prefix always -l
>>     set (bname "-l${bname}")
>>     # Remove the prefix lib (not always present, like in pthread)
>>     string (REPLACE "lib" "" bname "${bname}")
>>     set (Boost_PKGCONFIG_LIBS "${Boost_PKGCONFIG_LIBS} ${bname}")
>>   endforeach(b)
>>
>> get_filename_component() seems to return an empty string for one of the
>> boost libraries.
> 
> Patch submitted in #918128.
> 
> That just leaves python-numpy breaking many autopkgtests, which I'm not
> in a position to fix.

Can you file a bug report?

Emilio