[Debichem-devel] RFS: libchemps2/1.4-1 -- spin-adapted DMRG for ab initio quantum chemistry

[Sebastian Wouters]

Hi Michael,

2014-11-29 14:25 GMT-05:00 Michael Banck <mbanck at debian.org>:

> Hi Sebastian,
>
> On Sat, Nov 29, 2014 at 12:12:49AM -0500, Sebastian Wouters wrote:
> > In my last mail I forgot to CC the mailing list, so that's why part of
> > the mail will seem familiar.
> >
> >  - My freshly created account on alioth is "sebwouters-guest".
>
> Ok, I've added you to the project now, welcome!
>
> >  - Do I just need to provide the modified libchemps2-1.4 source (with
> > patches) and the debian/ folder (with patches) on the debichem git repo?
>
> I have to admit I haven't been using git for packaging yet, so I hope
> somebody else can answer this.  I think most people are using
> pristine-tar for the handling of upstream code in git.
>

I'll try to get the things for the C++ library uploaded today.


>
> >  - Thus far, I have only worked out the C++ shared library and
> development
> > files, but there's in fact also a python interface (PyCheMPS2) which
> would
> > be nice to have as a third library in the package.
>
> Which one is used by the external packages you mentioned in your first
> mail?  In any case, exposing the python package does not make sense at
> some point IMO.  If you don't have a lot of experience with python
> packages, somebody else from the team can take a look at some point if
> you want.
>

psi4 uses the C++ library directly, pyscf uses the python interface to the
library, and I don't know about horton at this point, although I assume
they also want to use the python interface.
I think it would be good to have the python bindings as a third part of the
libchemps2 package.


>
> >  - A second thing which I still need to figure out is how to run the
> tests
> > of the shared C++ / Python library. They're not intended for users to
> > install as an executable, but it might be good to run these tests after
> the
> > buildd deamon has finished.
>
> In general (and I haven't looked at your package yet), there's two ways
> to runs tests: (i) as part of the package building process and (ii)
> after package installation using the autopkgtest framework[1].
>
> We have not done a lot with autopkgtest so far (but this is an important
> topic we should tackle after the jessie release), but we try to run
> testsuites during build whenever possible.
>
> I try to keep the following in mind when doing (i):
>
> 1. If debhelper's dh is used, dh_auto_test should run tests
> automatically, but this is seldom the case for chemistry software. So we
> usually add an override_dh_auto_test target, which runs the testsuite.
>
> 2. I honor DEB_BUILD_OPTIONS=nocheck - if that is set, tests are not
> run, see e.g. the mpqc package.
>
> 3. In general, I make test suite failures non-fatal for the build, and
> review the build logs for problems instead, also done in the mpqc
> package.
>
> 4. depending on how long the testsuite takes (some take a very long
> time, especially on lower-powered autobuilders), I only enable a couple
> of tests which cover the functionality users are most likely to require.
> This is either done via patch to upstream, or some Debian-specific
> test-configuration from debian/.
>
> 5. If I do 4., then I try to add an option so that passing
> DEB_BUILD_OPTIONS=fullcheck runs the full testsuite optionally.  See
> the libint2 package (only in subversion so far) for that.
>
> Does that answer your question?
>
> That answers my question. I'll take a look at mpqc. Thanks!


>
> Michael
>
> [1]
> http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
>

Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debichem-devel/attachments/20141129/d773daa4/attachment.html>