Bug 210168
| Summary: | math/gsl: Update 2.2.0 -> 2.3 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Adam Weinberger <adamw> | ||||||||
| Component: | Individual Port(s) | Assignee: | Port Management Team <portmgr> | ||||||||
| Status: | Closed Overcome By Events | ||||||||||
| Severity: | Affects Only Me | CC: | adamw, pi, rhurlin, tcberner, wen | ||||||||
| Priority: | --- | Keywords: | needs-patch, needs-qa | ||||||||
| Version: | Latest | Flags: | koobs:
maintainer-feedback?
(adamw) koobs: exp-run? |
||||||||
| Hardware: | Any | ||||||||||
| OS: | Any | ||||||||||
| Bug Depends on: | 211444 | ||||||||||
| Bug Blocks: | 213685 | ||||||||||
| Attachments: |
|
||||||||||
math/gsl has many consumers. Did you check the update doesn't break them? According to devel/abi-compliance-checker some symbols were removed in 2.0 and SONAME was bumped in 2.1. cf. http://abi-laboratory.pro/tracker/timeline/gsl/ TBH, no. At this point I've only tested it with bogofilter. Maintainer reset. Created attachment 173099 [details]
patch to update math/gsl, rev. 2
I tried your patch with some minor modifications on 12-CURRENT amd64 and it builds and installs fine. 'portlint -AC' also is fine.
(The changes in the newer patch, rev. 2, against the older one are an obsolete patch under files, a style problem with COMMENT and a bit better sorting in pkg-plist.)
Next, I tried 44 known dependencies with GSL 2.1 on Poudriere and only 8 stopped with errors [EE]. A append a list with all ports. They are marked [OK], if they build, ohterwise [EE], if errors occurred. The reasons for not building are from Poudriere log files:
[OK] audio/snd
[OK] benchmarks/flowgrind
[OK] benchmarks/sipp
[OK] biology/bcftools
[OK] comms/gnuradio
[OK] editors/calligra
[EE]!!! graphics/amide
tb_profile.c:671:33: error: no member named 'J' in 'gsl_multifit_fdfsolver'
gsl_multifit_covar (solver->J, 0.0, covar);
[OK] graphics/enblend
[OK] graphics/inkscape
[EE]!!! science/kst2 no newer version, no deps
src/plugins/fits/lorentzian_unweighted/../non_linear.h:180:40: error:
no member named 'J' in 'gsl_multifit_fdfsolver'
gsl_multifit_covar( pSolver->J, 0.0, pMatrixCovariance );
[OK] graphics/luminance
[OK] graphics/luminance-qt5
[OK] graphics/nip2
[OK] graphics/ocropus
[OK] graphics/pfstmo
[OK] graphics/qgis
[OK] graphics/xaos
[OK] lang/algol68g
[OK] lang/newlisp
[OK] lang/newlisp-devel
[OK] mail/bogofilter
[OK] math/asymptote
[OK] math/dieharder
[OK] math/fflas-ffpack
[OK] math/giacxcas
[OK] math/labplot
[OK] math/libflame
[OK] math/libproj4
[EE]!!! math/ocamlgsl NEW RELEASE 1.19.1
[OK] math/octave-forge-gsl
[EE]!!! math/orpie deps on math/ocamgsl
[EE]!!! math/p5-Math-GSL
xs/BSpline_wrap.1.16.c:3277:62: error: too many arguments to function call,
expected 4, have 5
result = (int)gsl_bspline_deriv_eval(arg1,arg2,arg3,arg4,arg5);
[OK] math/PDL
[OK] math/pspp
[EE]!!! math/py-gsl NEW RELEASE 2.2.0
[EE]!!! math/qtiplot no newer version, no deps
src/analysis/Fit.cpp:131:29: error: no member named 'J' in 'gsl_multifit_fdfsolver'
gsl_multifit_covar (s->J, 0.0, covar);
[EE]!!! math/rubygem-rb-gsl no newer version, no deps
histogram.c:1245:25: error: no member named 'J' in 'gsl_multifit_fdfsolver'
gsl_multifit_covar(s->J, 0.0, covar);
[OK] net/ns3
[OK] science/afni
[OK] science/fisicalab
[OK] science/getdp
[OK] science/gnudatalanguage
[OK] science/py-mlpy
[OK] science/step
So it seems, that math/ocamlgsl and math/py-gsl should be updated. For five of the other failing ports we need patches, only math/orpie should build, after the update of math/ocamgsl.
I just added a new PR (bug #211444), which updates math/ocamlgsl to 1.19.1. This updates builds with math/gsl 2.1. Other than mentiond in comment #4, math/orpie does not build with updated math/ocamlgsl. Instead, it gives two errors: mlgsl_sf.c:261:51: error: too many arguments to function call, expected 3, have 4 SF4(ellint_D, Double_val, Double_val, Double_val, GSL_MODE_val) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~ mlgsl_sf.c:56:22: note: expanded from macro 'GSL_MODE_val' #define GSL_MODE_val Int_val ^ mlgsl_sf.c:95:43: note: expanded from macro 'SF4' ML4(gsl_sf_##name, conv1, conv2, conv3, conv4, copy_double) \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ ./wrappers.h:74:66: note: expanded from macro 'ML4' CAMLreturn(convr(name(conv1(arg1), conv2(arg2), conv3(arg3), conv4(arg4)))) ; } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ mlgsl_sf.c:261:1: error: too many arguments to function call, expected 4, have 5 SF4(ellint_D, Double_val, Double_val, Double_val, GSL_MODE_val) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mlgsl_sf.c:96:3: note: expanded from macro 'SF4' ML4_res(gsl_sf_##name##_e, conv1, conv2, conv3, conv4) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mlgsl_sf.c:77:62: note: expanded from macro 'ML4_res' name(conv1(arg1), conv2(arg2), conv3(arg3), conv4(arg4), &res); \ ~~~~ ^~~~ /usr/local/include/gsl/gsl_sf_ellint.h:84:1: note: 'gsl_sf_ellint_D_e' declared here int gsl_sf_ellint_D_e(double phi, double k, gsl_mode_t mode, gsl_sf_result * result); ^ So, at least six ports will fail after update of math/gsl and math/ocamlgsl. I suggest we repocopy gsl --> gsl2 first, any objects ? wen No, I don't think a repocopy is warranted yet. Given that all nearly all our ports build against gsl2, there's no reason for a repocopy at this time. We have 3 options with the remaining ports: 1) Fix them to build against gsl2 2) Deprecate them and then remove them from the tree 3) Repocopy gsl -> gsl1 so that those 6 ports can build against an old gsl. I'm opposed to adding a gsl2 port. In the meantime, there's gsl-2.2.1 Changes: http://git.savannah.gnu.org/cgit/gsl.git/tree/NEWS There's Math::GSL 0.39, which says it builds against 2.2.1 Created attachment 176025 [details]
patch-to-2.2.1
Testbuilds@work
math/qtiplot has upstream @ 0.9.9.7 testbuilds for 2.2.1 are fine. After the discuss with adamw@, now I suggest: 1 repocopy math/gsl --> math/gsl1 2 update math/gsl to 2.2.1 3 if it break some ports, change these ports' depend to math/gsl1 Any suggestions ? wen Reporter is committer, assign accordingly. I see 46 dependents, is an exp-run worthwhile so that potential fallout can be seen (at least at build time), prior to updating the main port to 2.x? + 1 on a gsl1 port (if gsl is to move across the major version barrier), OR a new gsl2 port for 2.x versions. I would add that in addition to this, a sweeping change pointing all dependents to the 1.x port is better than switching them implicitly/automatically to 2.x. This allows those port maintainers to switch to the 2.x port at their leisure (and having QA'd it them individually). I did this with the www/py-requests 1.x -> 2.x transition which worked well. Kurt do you want to take this PR? wen: I agree with "no gsl2 or gsl1 port", which means: one or two of the dependent ports will break. adamw: I'm not too eager to work on this PR, it's a time sink if we try to do it perfectly. koobs: Yes, that would be the perfect way, but I'm not too invested in this port to work this in. Any other volunteers ? For the exp-run, could you create a patch with: - math/gsl updated to 2.2.1 - math/p5-Math-GSL updated to 0.39 - math/rubygem-rb-gsl renamed to math/rubygem-gsl and updated to 2.1.0.1 - math/py-gsl updated to 2.2.0 A few patches that may be useful too: https://sources.debian.net/patches/qtiplot/0.9.8.9-15/10_adopt_to_gsl2.diff/ https://sources.debian.net/patches/orpie/1.5.2-1/gsl-fix/ https://sources.debian.net/patches/amide/1.0.5-7/gsl_2x.patch/ https://github.com/Kst-plot/kst/commit/a9d24f91057441bbd2e3ed9e7536b071121526cb I believe that with those few patches + the update of p5-Math-GSL / rubygem-gsl / py-gsl there is no need for a new port. gsl is now at 2.3, so this patch needs an update. Sorry, I didn't see this bug soon enough -- as gsl is now already at 2.3, and will be updated soon to 2.4, I'll close this. |
Created attachment 171234 [details] 2.1 Attached patch updates gsl to 2.1.