[Neurodebian-devel] Debian packages for Stimfit

Sat Feb 5 20:39:12 UTC 2011

Dear Yaroslav,

there's been some progress with the packaging:

On Mon, 31 Jan 2011, Yaroslav Halchenko wrote:
> * I guess there is no need to ship  /usr/lib/python-stfio/ at all --
> static library is of no use (or do you want to expose interface and make
> library public?), and .so seems to be duplicated under dist-packages as well

Fixed

> * as above it builds only for the default version of python.  Would you
>  consider building for all supported?  it is desired but not mandated... just wanted
>  to know

Not implemented yet.

> * better not to ship .la files at all
>  http://wiki.debian.org/ReleaseGoals/LAFileRemoval

Fixed.

> * during build there is report of
> dpkg-shlibdeps: warning: debian/stimfit/usr/lib/python2.6/dist-packages/stimfit/_stf.so contains an unresolvable reference to symbol _ZN9Recording9SetFitEndEi: it's probably a plugin.
>
> is that indeed a plugged in via some custom loading of some dynamic library? I see it undefined:
>
> $> objdump -t /usr/lib/python2.6/dist-packages/stimfit/_stf.so | grep _ZN9Recording9SetFitEndEi
> 0000000000000000         *UND*  0000000000000000              _ZN9Recording9SetFitEndEi
> $> objdump -t /usr/lib/stimfit/libstf.so | grep _ZN9Recording9SetFitEndEi
> 0000000000000000         *UND*  0000000000000000              _ZN9Recording9SetFitEndEi
>
> and there is more of them:
> dpkg-shlibdeps: warning: 48 other similar warnings have been skipped (use -v to see them all).

These warnings are still present after adding -fPIC. Supposedly because _stf.so is only loaded by Python at runtime?

> * all lintian warnings should be addressed:
>
> neurodebian at lego:/tmp/stimfit$ lintian stimfit_0.10.7-0ubuntu2_amd64.changes
> E: stimfit: copyright-contains-dh_make-todo-boilerplate
> W: stimfit: binary-without-manpage usr/bin/stimfit
> W: stimfit: executable-not-elf-or-script ./usr/lib/python2.6/dist-packages/stimfit/charlie.py
> W: stimfit: executable-not-elf-or-script ./usr/lib/python2.6/dist-packages/stimfit/natools.py
> W: stimfit: executable-not-elf-or-script ./usr/lib/python2.6/dist-packages/stimfit/ivtools.py
> W: stimfit: executable-not-elf-or-script ./usr/lib/python2.6/dist-packages/stimfit/minidemo.py
> W: stimfit: executable-not-elf-or-script ./usr/lib/python2.6/dist-packages/stimfit/hdf5tools.py
> W: stimfit: executable-not-elf-or-script ./usr/lib/python2.6/dist-packages/stimfit/mintools.py
> E: stimfit: unstripped-binary-or-object ./usr/bin/stimfit
> E: stimfit: unstripped-binary-or-object ./usr/lib/python2.6/dist-packages/stimfit/_stf.so
> E: stimfit: unstripped-binary-or-object ./usr/lib/stimfit/libstf.so
> E: python-stfio: copyright-contains-dh_make-todo-boilerplate
> W: python-stfio: wrong-section-according-to-package-name python-stfio => python
> W: python-stfio: executable-not-elf-or-script ./usr/lib/python2.6/dist-packages/stfio/hdf5tools.py
> E: python-stfio: unstripped-binary-or-object ./usr/lib/python-stfio/libstfio.so
> E: python-stfio: unstripped-binary-or-object ./usr/lib/python2.6/dist-packages/stfio/_stfio.so
>
>  - stripping -- you've forgotten to add dh_strip
>    you might like to create also stimfit-dbg package which would absorb all debug symbols, so you just
>   call
>   dh_strip --dbg-package=stimfit-dbg
>
>   that would help people to get meaningful backtraces if they are to file a bugreport
>
>   N.B. you can avoid running into 'missing calls to dh_' scripts by switching
>   to use debhelper 7 format of debian/rules, where you specify only
>   customizations

Fixed, but haven't switched to debhelper 7 format yet.

>  - manpage... since you have some command line options -- it is better to provide such one

Added.

>  - debian/copyright
>
>    needs to become a bit more extended, with proper copyright/license
>    header and entries -- now many things are missing (see below)
>
>   Also I would recommend to adopt DEP5 format for that file:
>
>   http://dep.debian.net/deps/dep5/
>
>   many (if not all) of above packages of ours carry such copyright files
>
>
>   also I see some files which might be problematic:
>
> ./src/core/filelib/axon/Common/axodebug.h
> //    Copyright (c) 1993-1997 Axon Instruments.
> //    All rights reserved.
>
> and no license, I have not spotted it among ./src/core/filelib/axon files
> -- so strictly speaking it is not allowed to be used or distributed...  where
> it came from and what is the license? (should be listed in debian/copyright).
> The same for any other file for which you are not the copyright holder/author
> (besides common free ones part of build infrastructure like  ltmain.sh):
>
>
> ./src/core/levmar/* GPL (v2 or later)
>  [Copyright: 2004-05 Manolis Lourakis (lourakis at ics.forth.gr)]

I've added the missing parts to debian/copyright.
The Axon Instruments/Molecular Devices code is still a problem. While most files mention:

"Permission is granted to freely to use, modify and copy the code in this file." (sic!)

this sentence is missing in a few other files. At best, they simply forgot to put it in. I'll try to get a reply from Molecular Devices (they've bought up Axon Instruments).

> * isn't stimfit using stfio anyhow?  I do not see any reference but I thought
> it would be logical... may be worth adding python-stfio to at least Suggests of
> stimfit?

No, stimfit isn't using stfio. stfio is a standalone Python module for reading files, while Stimfit is a GUI program that happens to have an embedded Python shell. They're just using the same file reading library. I've added python-stfio to the Recommends for Stimfit.

> * is test.h5  which you use in ./src/stfswig/unittest_stfio.py  too big
>  to be included at least into version control repository?
>
>   ideally unittests should run during build (invoked from debian/rules) so
>   functionality for the built package gets tested.  It is most of the time better
>   to fail while building than then interact with angry users ;-)
>
>  would you mind sharing some way some other samples files to test
>  functionality of stimfit/python-stfio ?
>
> * are there any other tests available besides the above?

Shame on me, unit testing is pathetic at the moment. We'll try to add some more testing on the long run.

> * since stimfit ships python module, to be friendly to Debian python
>  guys, might be useful to add

No, there's no standalone stimfit Python module. _stf.so can only be imported from the embedded Python shell in a running stimfit application.

> * since stimfit is a gui application, it would be great to register it within
>  the system by providing .desktop file to be shipped into
>  /usr/share/applications so people could invoke it from the GNOME or KDE
>  menu.
>
>  NB ideally there should also be debian/stimfit.menu and call to
>  dh_installmenu to register stimfit within Debian menu system which would
>  provide support for environments which do not care about .desktop files

Will do in the near future.

Thanks again for your review,

Christoph