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

Bug#804246: transition: gsl



On 20/11/15 12:57, Dirk Eddelbuettel wrote:
> 
> On 20 November 2015 at 11:45, Sebastiaan Couwenberg wrote:
> | On 09-11-15 18:21, Emilio Pozuelo Monfort wrote:
> | > On 06/11/15 15:06, Bas Couwenberg wrote:
> | >> Package: release.debian.org
> | >> Severity: normal
> | >> User: release.debian.org@packages.debian.org
> | >> Usertags: transition
> | >> Forwarded: https://release.debian.org/transitions/html/auto-gsl.html
> | >>
> | >> An uncoordinated transition to GSL 2.0 has started in unstable.
> | >>
> | >> It caused nco to FTBFS and I suspect other reverse dependencies will
> | >> likewise need to be updated to build successfully with gsl (2.0+dfsg-1).
> | >>
> | >> The automatically created transition tracker is already available.
> | >>
> | >> The maintainer is CC'ed.
> | > 
> | > Any idea how many packages fail to build against the new version? Not speaking
> | > of how many need to change the build dependencies from libgsl0-dev (>= x.y) to
> | > libgsl-dev, but of build failures in all the rdeps due to API changes.
> | 
> | I haven't tested any gsl rdeps other than those maintained by the Debian
> | GIS team, and those rebuilds are already available in unstable.
> | 
> | Can we binNMU the remaining rdeps and see what breaks?
> 
> Sounds good to me.

No, as I said that won't work as long as libgsl0-dev is still around, because
right now any build attempt will install that together with the old library,
instead of the new libgsl-dev and the new library. That's because real packages
are preferred over virtual ones.

And I didn't want to request its removal until I know how many packages will
fail to build.

> | Or should Dirk or someone else first rebuild the rdeps themselves before
> | this transition can move on?
> 
> Do you happen to have a list of what has / has not rebuilt?

See https://release.debian.org/transitions/html/gsl.html

Emilio


Reply to: