Hi Aaron and Michael, I've uploaded the changes to the git repo: http://anonscm.debian.org/cgit/debichem/packages/chemps2.git/
As I haven't changed upstream source, do I restick debian/1.5-1, or does this become a new version? In case of the latter: any preference for naming schemes? ( I added the bug closures in the changelog: http://anonscm.debian.org/cgit/debichem/packages/chemps2.git/tree/debian/changelog ) Best wishes, Sebastian 2015-07-11 21:23 GMT-04:00 Aaron M. Ucko <u...@debian.org>: > Sebastian Wouters <sebastianwout...@gmail.com> writes: > > > Hi Aaron, > > Hi! Thanks for the quick response. > > > I can add the dependency, but is there an easy way to test beforehand > > whether it will help? > > I just tested on a kFreeBSD porterbox (falla.debian.org), and can > confirm that it does. > > > The library itself should in principle be sufficient as the c-functions > are > > declared external in the chemps2 source code itself: > > > https://github.com/SebWouters/CheMPS2/blob/master/CheMPS2/include/chemps2/Lapack.h > > All the same, the build-time linker ordinarily relies on (unversioned) > lib*.so symlinks, which are also relegated to -dev packages so that > multiple versions of runtime packages can coexist. On Linux, CMake > somehow figures out that it can explicitly point the linker at > /usr/lib/libatlas.so.3gf and the like, but it doesn't do so on kFreeBSD, > and being able to specify -latlas, etc. is cleaner anyway. > > Thanks for checking! > > -- > Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) > http://www.mit.edu/~amu/ | > http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu >
