sundials_2.7.0+dfsg-1~1_amd64.changes REJECTED

Andreas Tille andreas at fam-tille.de
Thu Apr 13 11:55:23 UTC 2017


Hi Dima,

thanks a lot for your work on this and the status update.

On Tue, Apr 11, 2017 at 11:56:25AM -0700, Dima Kogan wrote:
> Andreas Tille <andreas at an3as.eu> writes:
> 
> > Please let me know if any help might be needed. New queue is currently
> > very short - so this might be a good time for uploading.
> 
> Hi. Before trying to upload again, I'd like to actually get this into a
> state when I myself know that it's semi-working. My benchmark is that I
> should be able to
> 
> - install the packages
> - build the examples from the packages
> - run the examples I just built
> 
> I worked on it a bit last week, and it's in much better shape now, but
> still not upload-worthy, I think. I talked to James Tocknell about
> progress to coordinate with him, but I don't think he had the cycles to
> do anything here.
> 
> The current state of the tree in master:
> 
> - All the various nvec types split into separate packages. All the
>   different PARALLEL types split into separate packages
> 
> - A single libsundials-dev does everything. This probably is wrong, but
>   is good enough to test. Let's get everything else right, then split
>   this
> 
> - debian/control has bogus descriptions and dependencies
> 
> - I'm not building examples WHEN BUILDING THE PACKAGES, but instead I'm
>   shipping them in libsundials-doc (should instead go into the -dev
>   package of whatever is being demonstrated). The user should be able to
> 
>     1. cd /usr/share/doc/whatever/examples
>     2. mkdir build
>     3. cd build
>     4. cmake ..
>     5. make
>     6. run example
> 
>   This required some patching to the example cmake files (I've only
>   touched arkode for now), but this now works at least for
>   arkode/C_serial
> 
>   Once we're happy with how this is done, we can apply these patches to
>   all the examples
> 
> - The pkgconfig business for PETSc wasn't working. Rather pkg-config
>   itself was working, but cmake was being stupid and doing something
>   wrong with the results. It took me way too long to debug it, and I
>   never did figure it out. But we have Build-depends, so we don't need
>   to find anything: we already know where everything is. Thus the
>   current makefiles simply take the output of pkg-config and don't test
>   it. If somebody wants to fix that, go for it.
> 
> 
> In any case, the packages are building are working somewhat. I'll pick
> this up again when I have the cycles, but if somebody wants to push on
> it before then, PLEASE do so!

I wonder whether you think the package names will need some change.  If
not I think it might make sense to push again to experimental to let it
pass new queue.  Users should assume that packages in experimental are
... well, just experimental.  My motivation to suggest this upload is
that while I fully agree that the examples should work I could in
parallel check whether other libs needing this library will build.  I
could concentrate on my initial target and while doing so doing parallel
tests.  Even if I could use locally build packages I think its worth to
have something we could refer to as a released package.

Kind regards

        Andreas.

-- 
http://fam-tille.de



More information about the debian-science-maintainers mailing list