[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#842288: transition: gdal



On 29/10/16 21:59, Sebastiaan Couwenberg wrote:
> On 10/29/2016 10:26 AM, Emilio Pozuelo Monfort wrote:
>> On 28/10/16 21:38, Sebastiaan Couwenberg wrote:
>>> On 10/28/2016 01:39 AM, Sebastiaan Couwenberg wrote:
>>>> On 10/27/2016 11:58 PM, Emilio Pozuelo Monfort wrote:
>>>>> On 27/10/16 20:10, Bas Couwenberg wrote:
>>>>>> Package: release.debian.org
>>>>>> Severity: normal
>>>>>> User: release.debian.org@packages.debian.org
>>>>>> Usertags: transition
>>>>>>
>>>>>> Dear Release Team,
>>>>>>
>>>>>> For the Debian GIS team I'd like to transition to GDAL 2.1.2.
>>>>>>
>>>>>> Like the previous transition to GDAL 2.1.1 (#830966), 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.1.2 from
>>>>>> experimental as summarized below, except mysql-workbench whose build
>>>>>> dependencies are not installable (#840786), but it's not in testing due
>>>>>> to (#839356).
>>>>>>
>>>>>> libgdal-grass doesn't need a binNMU as the 2.1.2 version will be
>>>>>> uploaded to unstable instead. liblas likewise doesn't need a binNMU,
>>>>>> the version is experimental will be moved to unstable instead.
>>>>>>
>>>>>> Please also binNMU osgearth in experimental as part of the transition.
>>>>>
>>>>> Sounds good. Go ahead.
>>>>
>>>> Thanks for the super quick feedback again!
>>>>
>>>> gdal (2.1.2+dfsg-1), liblas (1.8.1-3) & libgdal-grass (2.1.2-1) have
>>>> been uploaded to unstable, and gdal was just accepted. Sometime tomorrow
>>>> the buildds should have installed the packages.
>>>
>>> The mips64el buildd just installed gdal (2.1.2+dfsg-1), it's now
>>> available on all release architectures and all ports where the build
>>> dependencies are installable.
>>>
>>> Looks like we're ready for the binNMUs.
>>
>> Scheduling them.
> 
> The binNMUs are looking good so far, except vtk6 which FTFBS on mips due
> to a g++ segfault.
> 
> Can the build be retried (on another buildd)?

Given back. I can't pick a specific buildd (not sure I want to in this case
anyway), so let's see.

Cheers,
Emilio


Reply to: