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

Bug#811219: transition: netcdf



On 21-01-16 20:17, Sebastiaan Couwenberg wrote:
> On 21-01-16 11:20, Emilio Pozuelo Monfort wrote:
>> On 17/01/16 00:32, Bas Couwenberg wrote:
>>> NetCDF 4.4.0 final has been released and bumps the SOVERSION to 11
>>> accounting for the removed symbols in RC4. Fortunately we only have to
>>> transition netcdf, and not also the C++ & Fortran packages. Only a few
>>> packages FTBFS:
>>>
>>> minc (2.2.00-6) FTBFS, this is the same issue as the for the previous
>>> netcdf transition (#793885), which has been fixed in libminc, but not minc.
>>>
>>> python-scientific (2.9.4-3) FTBFS due to an old issue too (#799195).
>>>
>>> mmtk (2.7.9-1) FTBFS due to #798665, and requires python-scientific.
>>>
>>> These packages are sid-only already, so shouldn't be much of an issue
>>> for this transition.
>>
>> I was waiting for the python3 transition, which is now done. So go ahead.
> 
> Thanks. I've just uploaded netcdf (1:4.4.0-1) to unstable.

netcdf-cxx, netcdf-cxx-legacy, netcdf-fortran & netcdf4-python have
already been rebuilt with netcdf (1:4.4.0-1) on the release architectures.

The transition tracker does still need to be updated to also mark the
packages still depending on the netcdf (1:4.1.3-7.2) from the previous
transitions. Using the attached ben configuration (or the one in the
initial bugreport) will also include gerris, kst, minc & mmtk in the
tracker.

minc & mmtk both FTBFS and are sid-only as noted before.

gerris links to netcdf but the resulting packages don't depend on any
netcdf packages.

kst doesn't detect the new netcdf libraries any more, and disables the
netcdf plugin because of that.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
title = "netcdf";
is_affected = (.build-depends ~ /libnetcdf-dev/)|(.depends ~ /libnetcdfc?(7|11)/);
is_good = .depends ~ /libnetcdf11/;
is_bad = .depends ~ /libnetcdfc?7/;
notes = "#811219";

Reply to: