[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFR: eegdev



Hi,

On 20/01/2012 13:20, Michael Hanke wrote:
> The comments at the top of debian/rules should go away -- it is no
> longer a sample rules file.

Done


> When I build the package on my i386 laptop (up-to-date wheezy) the build
> hangs in one of the tests until I kill it (reproduced every time):
> 
> make[4]: Entering directory `/home/michael/debian/cnbi/eegdev/tests'
> PASS: verify-cast.sh
> PASS: verifysplit
> PASS: syseegfile
> 	Testing biosemi with float data type
> 	Testing biosemi with double data type
> PASS: testfakeact2.sh
> 		error caught (97) Address family not supported by protocol
> ^C
> 
> When I build the package with 'nocheck' it builds.

It is the unit test of one particular plugin that fails. I think it is
not related to the architecture but it more a bug in the plugin and its
unit test which, if I am right, does not handle IPv6 correctly. To
confirm this, could you tell me what localhost refers to in your
configuration? If it is a IPv6 address, my theory is likely to be the
right one! :-)


> I noticed the eegdev-plugins-free binary package name and that the
> build uses this configuration
> 
>     Core library build : yes
>     --------------------------
>     EEG file support : yes
>     Biosemi support  : yes
>     gTec support     : no
>     Neurosky support : no
>     TobiIA support   : yes
> 
> Do the two missing plugins depend on something that is not in Debian? Or
> that is non-free? It looks like (at least some of) the code for these
> plugins is shipped with the package. I didn't see any copyright notice
> that would indicate 3rd-party code. 

Neurosky device corresponds to experimental hardware that the
manufacturer has given us to test (for those who know, it is not the EEG
device that Neurosky sells). I kept the code because it can be an
example for writing the plugin of another bluetooth based acquisition
device.

The other one (gTec) is the plugin for hardware (g.USBAmp) which depends
on a library that cannot be distributed, not even as non-free. The
source code is provided because those who have bought the library (a
kind of SDK) can compile it and use it.


> It might make sense to put some
> information about the "missing" plugins into README.Debian or
> README.source, depending on why they are missing and whether there are
> plans to add them later on.

Good point, I will write a README that describes this. README.Debian or
README.source, which one should I use? (what is the policy?)

> I have updated the information on this package in the Debian Science
> taskfiles.

Thanks

I will update all of this,

Cheers,

Nicolas

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: