[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging new upstream for sundials



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


Reply to: