JamesI emailed upstream about a year ago (http://sundials.2283335.n4.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/nabble.com/Packaging-sundials- ), 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.for-debian-td4653658.html
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).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 <dkogan@debian.org> wrote:James Tocknell <aragilar@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 http://www.gnu.org/philosophy/no-word-attachments.html .
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.