On 04/01/2019 10:57, Sebastiaan Couwenberg wrote:
> 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....@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?
I had assumed (without investigating) that the problem would be in numpy, but
looking at the bug report that you added to this one's blocker list, I see that
the problem is with the new deprecated functions in numpy, so it's a problem in
the rdeps (that fail because of that). So yeah I suppose all rdeps with failing
autopkgtests need bugs filed (if they don't have a bug yet) so the maintainers
can determine if it is due to those deprecation warnings or something else and
act accordingly.
Cheers,
Emilio
