I emailed upstream about a year ago (
and I sent them the patches directly, but never heard back from them. I've
got no idea about upstream's release schedule or future plans, the 2.7
release came as a complete surprise to me. I get the impression sundialsTB
may be gone for a while (as while it hasn't changed for 7 years, I don't
see much change in the higher level interface of sundials, apart from the
new runga-kutta solver, which sundialsTB doesn't support, so maybe there's
bugs which haven't been mentioned on the mailing list?), but that just
speculation, and they could just as well be working on a 2.7.1 release
which only updated sundialsTB.

I ignored the tests, I've had no problems building scikits.odes on top of
sundials, and I'm not inclined to trust examples where results may vary
based on optimisation, as opposed to real tests (this could be something
worth asking upstream about).

What's your plan on the organisation of the packages, my idea (which I
haven't started on, I'm very open to opinions on this) was to have a
package per DSO (which makes more sense if we add support for the other
parallelisation method sundials now has), a libsundials-dev which has the
things for each of the solvers, but not the serial/parallel/openmp stuff,
and which depends on a separate
libsundials-{serial/parallel/openmp/etc.}-dev? I can also see advantages
for splitting out separate packages for each of the solvers, or for a
single dev package, but I thought that this would involve the least change.
OTOH, there's nothing in Debian which depends on sundials, and it's isn't
that popular, so that may not be a strong argument.


On 11 October 2016 at 18:27, Dima Kogan <dko...@debian.org> wrote:

> James Tocknell <aragi...@gmail.com> writes:
> > I do plan on finishing it, but was going to wait till after the freeze
> > to push it to the archive, as it involved dropping octave-sundials,
> > which now seems like a moot point given upstream's decision to drop
> > the matlab interface from the release.
> >
> > I've pushed the latest stuff to
> > https://github.com/aragilar/debian-packaging-sundials (which I uploaded
> > originally as someone was trying to install sundials to use
> scikits.odes),
> > but it is a mess. Also, it looks like upstream has finally made it easy
> to
> > download tarballs (it used to require providing an email), so the watch
> > file from my work is no longer valid.
> OK. I think it makes sense to not touch it until the freeze so that
> octave-sundials can remain. Afterwards, it would be good to get the
> latest code pushed. Upstream says they'll reinstate sundialsTB at some
> point, so we can aim to push the code then. Are you talking to upstream?
> Do you have any sense when they aim to get the sundialsTB back?
> My code lives here:
>   ssh://git.debian.org/git/debian-science/packages/sundials.git
> The 'stash' branch contains a patch with all the not-yet-sorted-out
> stuff committed into it.
> The packages build.
> The symbols, copyright and watch files need updating. It's not obvious
> which APIs have been broken. Upstream bumped some SONAMEs, but not all
> of them. However all the DSOs have had symbols removed. I want to build
> some executables against sundials-2.5.0 and see what can run against the
> new DSOs.
> The tests don't pass. This is probably OK, because these are tests
> written by the previous Debian maintainer, and they probably make false
> assumptions.
> I won't get to this again for a few days, but am interested to hear your
> thoughts.
> dima

Don't send me files in proprietary formats (.doc(x), .xls, .ppt etc.). It
isn't good enough for Tim Berners-Lee
and it isn't good enough for me either. For more information visit

Truly great madness cannot be achieved without significant intelligence.
 - Henrik Tikkanen

If you're not messing with your sanity, you're not having fun.
 - James Tocknell

In theory, there is no difference between theory and practice; In practice,
there is.

Reply via email to