On 23/11/15 01:46, Sebastiaan Couwenberg wrote: > On 20-11-15 13:15, Emilio Pozuelo Monfort wrote: >> 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....@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 > > To keep this transition moving I've started a round of rebuilding the > gsl rdeps to see what breaks. > > > 3dldf (2.0.3+dfsg-3) explicitly build depends on libgsl0ldbl, > libgsl0-dev which needs to be changed to just libgsl-dev to build with > libgsl2. I've forwarded the patch in #805740. > > adun.app (0.81-7) only build depends on libgsl0-dev, but didn't pull in > libgsl2. It built successfully with libgsl2 after changing the build > dependency to libgsl-dev. Because of this all other reverse dependencies > were also updated to use libgsl-dev instead of libgsl0-dev. > > aghermann (1.0.6-1) has the build dependency issue, and FTBFS after > changing the build dependency to libgsl-dev with: > > model/borbely.cc:175:32: error: 'struct gsl_multifit_fdfsolver' has no > member named 'J' > gsl_multifit_covar( S->J, 0.0, covar); > ^ > I've reported this build failure in #805746. > > amide (1.0.5-4) FTBFS due to the same issue as aghermann: > > tb_profile.c:671:31: error: 'gsl_multifit_fdfsolver > {aka struct <anonymous>}' has no member named 'J' > gsl_multifit_covar (solver->J, 0.0, covar); > ^ > This is reported in #805748. And fixed with amide (1.0.5-5). > > Besides aghermann & amide, this common issue also affects: > > #805794 gbutils (5.6.7-1) > #805799 kst (2.0.3-4) > #805801 mathgl (2.3.3-3) > #805819 odin (1.8.8-1.1) > #805832 scidavis (1.D8-1) > #805834 siril (0.9.0-1) > #805835 voxbo (1.8.5~svn1246-1.1) > #805841 qtiplot (0.9.8.9-10) > #805842 ruby-gsl (1.16.0.4+dfsg1-1) > > altree (1.3.1-2) cannot be built after updating the build dependency to > libgsl-dev, because some other dependency still pulls in libgsl0ldbl > causing a conflict with libgsl2. > > asymptote (2.35-2) FTBFS too: > > gsl.cc: In function 'void trans::gen_rungsl_venv(trans::venv&)': > gsl.cc:1091:67: error: no matching function for call to > 'addGSLDOUBLE3Func(sym::symbol&, sym::symbol&, sym::symbol&, > sym::symbol&)' > addGSLDOUBLE3Func<gsl_sf_ellint_D>(SYM(D),SYM(phi),SYM(k),SYM(n)); > ^ > gsl.cc:192:6: note: candidate: template<double (* fcn)(double, double, > double, gsl_mode_t)> void trans::addGSLDOUBLE3Func(sym::symbol, > sym::symbol, sym::symbol, sym::symbol) > void addGSLDOUBLE3Func(symbol name, symbol arg1, symbol arg2, > ^ > gsl.cc:192:6: note: template argument deduction/substitution failed: > gsl.cc:1091:67: error: could not convert template argument > 'gsl_sf_ellint_D' to 'double (*)(double, double, double, gsl_mode_t) > {aka double (*)(double, double, double, unsigned int)}' > addGSLDOUBLE3Func<gsl_sf_ellint_D>(SYM(D),SYM(phi),SYM(k),SYM(n)); > ^ > Reported in #805749. > > ball (1.4.2+20140406-1.1) FTBFS due to a Boost issue, this seems to be > #777791 and unrelated to GSL 2. > > calligra (1:2.8.5+dfsg-1.2) also FTBFS due to an issue unrelated to GSL > 2, that seems to be #797389. > > gambas3 (3.5.4-2) FTBFS due to a WebKit issue: > > make[6]: Entering directory '/tmp/buildd/gambas3-3.5.4/gb.qt4 > /src/webkit' > CXX gb_qt4_webkit_la-main.lo > CXX gb_qt4_webkit_la-cwebsettings.lo > CXX gb_qt4_webkit_la-cwebframe.lo > main.cpp:31:21: fatal error: QDateTime: No such file or directory > > This is probably related to #784465. > > getdp (sid only) (2.4.2-1) FTBFS with make 4 as reported in #747109. > > mrtrix (0.2.12-1) FTBFS with type error: > > /usr/include/gsl/gsl_sf_legendre.h:323:33: error: 'size_t' > does not name a type > const size_t lmax, const double x, > ^ > Reported in #805814. > > ocamlgsl (0.6.0-7) FTBFS > > mlgsl_fit.c:154:5: error: too many arguments to function > 'gsl_multifit_linear_svd' > gsl_multifit_linear_svd(&m_x, &v_y, > ^ > Reported in #805818. > > openms (1.11.1-5) FTBFS due to arguments mismatch: > > source/ANALYSIS/MAPMATCHING/TransformationModel.C: In member function > 'void OpenMS::TransformationModelBSpline::computeLinear_(double, > double&, double&, double&)': > source/ANALYSIS/MAPMATCHING/TransformationModel.C:366:70: error: > too many arguments to function 'int gsl_bspline_deriv_eval(double, > size_t, gsl_matrix*, gsl_bspline_workspace*)' > gsl_bspline_deriv_eval(pos, 1, deriv, workspace_, deriv_workspace); > ^ > In file included from > include/OpenMS/ANALYSIS/MAPMATCHING/TransformationModel.h:40:0, > source/ANALYSIS/MAPMATCHING/TransformationModel.C:35: > /usr/include/gsl/gsl_bspline.h:107:1: note: declared here > gsl_bspline_deriv_eval(const double x, > ^ > Reported in #805823. > > pdl (1:2.007-4) FTBFS due to a similar issue: > > In file included from ELLINT.xs:39:0: > ELLINT.xs: In function 'pdl_gsl_sf_ellint_D_readdata': > ELLINT.xs:1720:8: error: too many arguments to function > 'gsl_sf_ellint_D_e' > GSLERR(gsl_sf_ellint_D_e,((phi_datap)[0] PDL_COMMENT("ACCESS()") > ,(k_datap)[0] PDL_COMMENT("ACCESS()") ,(n_datap)[0] > PDL_COMMENT("ACCESS()") ,GSL_PREC_DOUBLE,&r)) > ^ > Reported in #805824. > > r-cran-gsl (1.9-10-1) FTBFS at configure already: > > configure: error: Need GSL version >= 1.12 > ERROR: configuration failed for package 'gsl' > > Reported in #805829. > > root-system (5.34.19+dfsg-1.2) FTBFS due to unresolved GCC-5 issues > (#778108). > > herwig++ (2.6.0-1) FTBFS due to missing /usr/lib/libgsl.a: > > checking for gsl location... not found > configure: error: Can't find /usr/lib/libgsl.a or the headers in > /usr/include > > Reported in #805844. > > > Transition: gsl > > libgsl0ldbl (1.16+dfsg-4) -> libgsl2 (2.1+dfsg-1) > > The status of the most recent rebuilds is as follows. > > 3dldf (2.0.3+dfsg-3) OK > adun.app (sid only) (0.81-7) OK > aghermann (1.0.6-1) FTBFS > altree (1.3.1-2) BD-Uninstallable > amide (1.0.5-4) FTBFS > ampliconnoise (1.29-2) OK > apophenia (0.999e+ds-4) OK > ardesia (sid only) (1.1-2) OK > astrometry.net (0.64+dfsg-1) OK > asymptote (2.35-2) FTBFS > ball (sid only) (1.4.2+20140406-1.1) FTBFS > bist (0.5.2-1) OK > bogofilter (1.2.4+dfsg1-3) OK > calligra (sid only) (1:2.8.5+dfsg-1.2) FTBFS > chemps2 (1.6-1) OK > clonalframe (1.2-3) OK > cnrun (1.1.14-1) OK > comedilib (0.10.2-3) OK > cpl-plugin-fors (5.1.4+dfsg-1) OK > cpl-plugin-hawki (1.8.18+dfsg-4) OK > cpl-plugin-naco (4.4.1+dfsg-1) OK > cpl-plugin-vimos (3.0.6+dfsg-3) OK > cvxopt (1.1.4-1.3) OK > dieharder (3.31.1-4) OK > dynare (4.4.3-2) OK > ea-utils (sid only) (1.1.2+dfsg-1) OK > enblend-enfuse (4.1.4+dfsg-2) OK > flowgrind (0.7.5-1) OK > freefem++ (3.38.1-1) OK > gambas3 (sid only) (3.5.4-2) FTBFS > gbutils (5.6.7-1) FTBFS > getdp (sid only) (2.4.2-1) FTBFS > gjay (0.3.2-1.1) OK > gnudatalanguage (sid only) (0.9.5-3) OK > gpsshogi (sid only) (0.6.0-3+nmu1) OK > guvcview (2.0.2+debian-1) OK > hkl (4.99.99.1955-1) OK > inkscape (0.91-6) OK > kst (2.0.3-4) FTBFS > libgpiv (0.6.1-4.2) OK > libindi (1.0.0-3) OK > luminance-hdr (2.4.0-6) OK > mathgl (2.3.3-3) FTBFS > meep (1.3-3) OK > meep-lam4 (1.3-1) OK > meep-mpi-default (1.3-2) OK > meep-mpich2 (1.3-2) OK > meep-openmpi (1.3-2) OK > mia (2.2.7-1) OK > mlpy (2.2.0~dfsg1-3) OK > mrtrix (0.2.12-1) FTBFS > ngraph-gtk (6.06.13-5) OK > nip2 (8.0-1) OK > ns3 (3.22+dfsg-1) OK > ocamlgsl (0.6.0-7) FTBFS > octave-gsl (1.0.8-6) OK > odin (sid only) (1.8.8-1.1) FTBFS > openms (sid only) (1.11.1-5) FTBFS > pdl (1:2.007-4) FTBFS > pdp (1:0.14.1-2) OK > pfstools (2.0.4-4) OK > proftmb (1.1.12-2) OK > pspp (0.8.5-4) OK > pyxplot (0.9.2-5) OK > r-cran-gsl (1.9-10-1) FTBFS > rivet (sid only) (1.8.3-1.2) OK > root-system (sid only) (5.34.19+dfsg-1.2) FTBFS > saint (2.5.0+dfsg-1) OK > scidavis (sid only) (1.D8-1) FTBFS > sip-tester (1:3.2-1) OK > siril (0.9.0-1) FTBFS > slgsl (sid only) (0.7.0-5.2) OK > step (4:15.08.0-3) OK > tamuanova (0.2-3) OK > theseus (3.3.0-3) OK > visp (2.10.0+dfsg-1) OK > votca-tools (sid only) (1.2.4-1) OK > voxbo (1.8.5~svn1246-1.1) FTBFS > xaos (3.5+ds1-2) OK > > 3depict (sid only) (0.0.18-2) BD-Uninstallable > gpiv (sid only) (0.6.1-2.3) OK > gpivtools (sid only) (0.6.0-3.1) OK > libpdl-stats-perl (0.6.5.1-1) BD-Uninstallable > orpie (1.5.1-10) BD-Uninstallable > psi4 (1:0.3-3) OK > qtiplot (0.9.8.9-10) FTBFS > ruby-gsl (sid only) (1.16.0.4+dfsg1-1) FTBFS > thepeg (sid only) (1.8.0-1) OK > > herwig++ (sid only) (2.6.0-1) FTBFS >
Would 2.1+dfsg-2 help in any way? From the changelog it sounds like it could. Cheers, Emilio
