[Neurodebian-devel] Debian packages for Stimfit

[Christoph Schmidt-Hieber]

Dear Yaroslav,

On Tue, 8 Feb 2011, Yaroslav Halchenko wrote:
>>>> * 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.
>
> if someone becomes pedantic (e.g. like Debian ftpmasters do from time to time
> ;)), you might be asked then to ship stimfit module elsewhere, e.g. directly
> under /usr/lib/stimfit since /usr/lib/python2.6/dist-packages/stimfit is for
> public ones, and stimfit is not even a module strictly speaking (lacking
> __init__.py)
>
> e.g. see for reference:
> http://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs

Moved everything to /usr/lib/stimfit (r480)

>>>   ... there would be ./usr/lib/stimfit/libstf.so  which would
>>>   absorbs all the code (e.g. like recording.*) which will be used (linked
>>>   dynamically) by both _stf.so and bin/stimfit
>>>   and definitions present in /usr/lib/stimfit/libstf.so would be defined
>> I can't follow you here: _stf.so is now a symbolic link to
>> libstf.so, i.e. both Python (via _stf.so) as well as bin/stimfit are
>> using the same libstf.so
>
> yes, and that one does not define some symbols which are known to it.
>
> Let me just try to describe once again what I meant, although the whole
> situation is probably more aiming clarity than necessary for
> practicality, since stimfit is not to be used as an independent module, I guess
> all those symbols become available at runtime since they are defined within
> /usr/bin/stimfit binary which loads up libstf.so/_sft.so later on; which is
> what I guess Yury was once trying to deliver to my tired mind ;):
>
>
> Symbol _ZN9Recording9SetFitEndEi is for Recording::SetFitEnd, defined in
> ./src/core/recording.cpp and declared in ./src/core/recording.h.
>
> Compiled stimfit-recording.o's get included into bin/stimfit and
> libstfio.{a,so} but not into libstf.{a,so}, although declarations from
> recording.h manage to get included (through #include's chain which I didn't
> investigate) into libstf.{a,so}, which leads to those undefined symbols.
>
> Since I do not know how to trigger usage of those symbols from within
> stimfit's python shell (or either they are used at all), I do not know if there
> is any effect or they get found due to the fact that python core is running
> within stimfit process having them defined.

This remains to be addressed.

> ok -- since per se I do not see any show-stoppers any longer and
> packaging would be lintian clean -- please provide with a url to the fresh .dsc
> with all those changed incorporated and we will upload it to Debian NEW.

http://www.stimfit.org/deb/index.html

Signed with

http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x37D2370A9F7AC0CC

Thanks for all your work!

Best,
Christoph