I looked at 2.7.0, there's another ABI break: it looks like Sls* symbols were moved to Sparse*. I've nearly finished cleaning up what I did, the main problem is the soversions, it looks like upstream is assuming soversion == release version.
On 13 October 2016 at 14:32, James Tocknell <aragi...@gmail.com> wrote: > I emailed upstream about a year ago (http://sundials.2283335.n4. > nabble.com/Packaging-sundials-for-debian-td4653658.html), 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. > > James > > 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 > <http://opendotdotdot.blogspot.com/2010/04/rms-and-tim-berners-lee-separated-at.html>, > 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. > -- Don't send me files in proprietary formats (.doc(x), .xls, .ppt etc.). It isn't good enough for Tim Berners-Lee <http://opendotdotdot.blogspot.com/2010/04/rms-and-tim-berners-lee-separated-at.html>, 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.
