Re: Interested in maintaining the gsl package.

[Julien Bect]

Le 20/04/2016 07:34, Julien Bect a écrit :

Le 19/04/2016 23:56, Steven Wasserbaech a écrit :

I'm not really having an issue with gsl.  I found some instructions online and I managed to make gsl work with Octave 3.6.2.  I'm not sure whether it could work with Octave 4.  I feel it is a kind of moral imperative that these functions be conveniently available in Octave, so I think gsl needs to be a maintained package that can be installed effortlessly.

I will try to use your first suggested method of working, and I'll let you know if I have trouble.  Are you aware of any particular issues that need to be fixed before gsl can run with Octave 4 and be an "official" package?  Thank you.

(Please use bottom-posting when replying to this list.)

Hi Steve,

There is an open ticket for gsl since January 2014 on the package release tracker: https://sourceforge.net/p/octave/package-releases/83. Some issues can readily be identified from the discussion there.  As you can see, Nik Krakauer and Carnë Draug were the ones active in this discussion at the time.

There are also some open bug reports on the bug tracker:
https://savannah.gnu.org/bugs/?func=detailitem&item_id=46442
https://savannah.gnu.org/bugs/?func=detailitem&item_id=39309

I have clone the gsl repo:
https://sourceforge.net/p/octave/gsl/ci/default/tree/

and then followed the steps to produce a package:
http://octave.sourceforge.net/developers.html

Everything went fine, and I could install the resulting package.

----

Then I wanted to test the installed package...

a) There are two test scripts (?) named test_ellint and test_hyperg.  They run without error,

b) I tried __run_unit_tests__ but apparently the only unit tests are in private/strsplit (which I think could be removed now) and several of them were failing for me.

c) On the release tracker, Carnë refers to "tests in src" that are failing.  I couldn't find these tests.  There is a test_sf.c file in inst/ but I don't know how to use it.

----

Here are a few steps that I can suggest based on all these observations:

1) Test the configure script.  From Carnë's last message on the release tracker, it seemed that missing dependencies were not always correctly detected.  From the repo history (see changeset 049c58821e1b) the problem seems to have been addressed but you have to test to be sure (perhaps Nik can comment on that).  To test this, you can start from a clean build environment (say, a fresh stable Debian install in a virtual box), add dependencies one by one, and check at each step that missing dependencies are properly detected.

2) Try to add a precise version requirement for the gsl library in DESCRIPTION.  This should end up in SystemRequirements and BuildRequires (see, e.g., https://sourceforge.net/p/octave/interval/ci/default/tree/DESCRIPTION).  If you're not sure, try to install older releases of the gsl library and check that you can build against them.  For instance, the old-stable Debian release has gsl 1.15, can you build against that one?

3) Improve the NEWS file.  They were some remarks about it in Carnë's messages.  You should have a look at all commits made since the 1.0.8 release in 2009 (don't be afraid, it's only 16 commits) and document the important ones in the NEWS file.  Nik has made one commit in that direction before stopping the work on gsl in 2014, but perhaps are there other modifications that deserve being mentioned?

4) Investigate whether having a private copy of strsplit is still necessary.  It was put there to avoid issues when Octave 3.8 was released (see http://www.gnu.org/software/octave/NEWS-3.8.html) but, actually, I don't think the changes in strsplit do not affect the package at all.

5) Consider moving the file test_sf.c to a more appropriate location.  I don't think it should be in inst/.

6) Consider turning all the available tests files (test_ellint.m, test_hyperg.m, test_sf.c) into proper Octave unit tests that can be run using Octave's "test" function.

----

I hope this helps,

@++
Julien