Re: Packaging new upstream for sundials

[Dima Kogan]

James Tocknell  writes:

> 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.

OK. Thanks for running those tests.


> 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 think this how it is laid out currently (in 2.5.0), except there's no
separate libsundials-dev. With the separate serial/parallel/openmp/...
business, we'd need the finer granularity, as you say. Fine with me.

I'm now using my 2.7.0 packages in the project I needed them for, so my
personal short-term need has been met. After stretch is out the door,
Let's get 2.7.0 into the archive. If you want to spearhead that and to
use your tree, that's fine with me. In any case, I'm not going to apply
much effort on this front until after the release.

dima

Re: Packaging new upstream for sundials

[James Tocknell]

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  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  wrote:
>
>> James Tocknell  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.
>



-- 
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 achiev

Re: Packaging new upstream for sundials

[James Tocknell]

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  wrote:

> James Tocknell  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.

Re: Packaging new upstream for sundials

[Dima Kogan]

James Tocknell  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

Re: Packaging new upstream for sundials

[James Tocknell]

I haven't packaged 2.7 due to lack of time (as it wasn't out when I
packaged it), and because the reason I packaged it was so that I could use
scikits.odes (https://pypi.python.org/pypi/scikits.odes), which currently
uses 2.6.2 (though updating scikits.odes to use 2.7 shouldn't be hard). I
was planning on pulling out the sundials matlab interface and making it
compatible with octave-forge (which seems to be the way the octave
community and debian's octave team package stuff), but I haven't had time.
Also, there was a ABI break between 2.5 and 2.6 which upstream ignored, and
I was waiting for them to get back to me. 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.

On 10 October 2016 at 15:17, Dima Kogan  wrote:

> James Tocknell  writes:
>
> > How much of the packaging have you done? I've almost done 2.6-2.6.2, the
> > main problem was trying to make octave-sundials multiarch (given the
> build
> > system used upstream is a hacky matlab script). I've got multiarch
> working
> > for the rest of sundials, and have added pkg-config files.
>
> I've done most of it, but that doesn't mean that my work needs to
> supercede yours. If you've worked on 2.6.2, then you're not at the
> latest upstream release. Did you stick with 2.6.2 to retain
> octave-sundials? And are you intending to finish the work and to push
> the packages to the archive in the near future?
>



-- 
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.

Re: Packaging new upstream for sundials

[Dima Kogan]

James Tocknell  writes:

> How much of the packaging have you done? I've almost done 2.6-2.6.2, the
> main problem was trying to make octave-sundials multiarch (given the build
> system used upstream is a hacky matlab script). I've got multiarch working
> for the rest of sundials, and have added pkg-config files.

I've done most of it, but that doesn't mean that my work needs to
supercede yours. If you've worked on 2.6.2, then you're not at the
latest upstream release. Did you stick with 2.6.2 to retain
octave-sundials? And are you intending to finish the work and to push
the packages to the archive in the near future?

Re: Packaging new upstream for sundials

[James Tocknell]

Hi Dima

How much of the packaging have you done? I've almost done 2.6-2.6.2, the
main problem was trying to make octave-sundials multiarch (given the build
system used upstream is a hacky matlab script). I've got multiarch working
for the rest of sundials, and have added pkg-config files.

James

On 9 October 2016 at 19:24, Dima Kogan  wrote:

> Hi.
>
> I'm packaging the new 2.7.0 release of sundials to update our very old
> 2.5.0 packages. Upstream has removed (possibly temporarily) the matlab
> toolbox:
>
> http://computation.llnl.gov/projects/sundials/sundials-software
>
> Thus a packaging of 2.7.0 would remove the octave-sundials package. Any
> objections to this?
>
> 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.