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

[Michael Banck]

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.

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

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


Michael

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