Bug#917323: transition: gdal
On 1/4/19 10:36 AM, Emilio Pozuelo Monfort wrote:
> 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?
You mean for all packages that fail their autopkgtest with the new
numpy? Or one for python-numpy about breaking autopkgtest of its rdeps
which block the gdal transition?
Kind Regards,
Bas
--
GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Reply to: