Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID smart card readers

[Hendrik Sattler]

Hi,

Zitat von Godfrey Chung :

Yes, libccid works for a few models only while libacsccid works for  
all models of ACS CCID smart card readers.


You can download the drivers from  
http://www.acs.com.hk/index.php?pid=drivers. For example, select  
ACR122U (http://www.acs.com.hk/index.php?pid=drivers&id=ACR122U) and  
you will find the driver  
(http://www.acs.com.hk/drivers/eng/ACR122U_driver_Lnx_Mac10.5_10.6_1.02_P.zip). The driver "acsccid-1.0.2.tar.bz2" is in the zip  
file.


I am a maintainer of the driver. acsccid-1.0.2 is based on  
ccid-1.3.11 and supports all models of ACS CCID smart card readers.  
The driver is tested by software and hardware engineers from ACS.


I figured from your mail address that ACS is directly involved here.  
OTOH, why are those changes not pushed to libccid upstream? For  
generic protocols like CCID (where even Windows has a generic driver  
for it), there should not be a driver set for each vendor, it simply  
defeats the purpose of generic protocols like that.


Your example of ACR122U is marked as "should work" at
http://pcsclite.alioth.debian.org/ccid/iManufacturer.html#2

If the libccid upstream is not cooperative for including your changes  
(if it's done in a clean way), maybe you can work with the Debian  
libccid maintainer?


HS



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110518094650.47921ux2i5xma...@v1539.ncsrv.de

Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID smart card readers

[Godfrey Chung]

Before we started the driver project in 2009, we had requested to join as a 
developer for libccid in alioth.debian.org but the author rejected us with 
no reason. As the same time, our customer pushed us to release Linux driver. 
Therefore, we decided to release our Linux driver based on libccid and had a 
plan to release our driver to any Linux Distributions.


For the Windows platform, we also release our own driver. It is because the 
generic driver does not work with multi-slot smart card readers and we can 
control our driver source code to fix bugs from the readers.


Please note that libccid upstream author and Debian maintainer are same 
person. He may reject our changes.


Godfrey

-Original Message- 
From: Hendrik Sattler

Sent: Wednesday, May 18, 2011 3:46 PM
To: Godfrey Chung
Cc: 627...@bugs.debian.org ; debian-devel@lists.debian.org
Subject: Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID 
smart card readers


Hi,

Zitat von Godfrey Chung :

Yes, libccid works for a few models only while libacsccid works for  all 
models of ACS CCID smart card readers.


You can download the drivers from 
http://www.acs.com.hk/index.php?pid=drivers. For example, select  ACR122U 
(http://www.acs.com.hk/index.php?pid=drivers&id=ACR122U) and  you will 
find the driver 
(http://www.acs.com.hk/drivers/eng/ACR122U_driver_Lnx_Mac10.5_10.6_1.02_P.zip). 
The driver "acsccid-1.0.2.tar.bz2" is in the zip  file.


I am a maintainer of the driver. acsccid-1.0.2 is based on  ccid-1.3.11 
and supports all models of ACS CCID smart card readers.  The driver is 
tested by software and hardware engineers from ACS.


I figured from your mail address that ACS is directly involved here.
OTOH, why are those changes not pushed to libccid upstream? For
generic protocols like CCID (where even Windows has a generic driver
for it), there should not be a driver set for each vendor, it simply
defeats the purpose of generic protocols like that.

Your example of ACR122U is marked as "should work" at
http://pcsclite.alioth.debian.org/ccid/iManufacturer.html#2

If the libccid upstream is not cooperative for including your changes
(if it's done in a clean way), maybe you can work with the Debian
libccid maintainer?

HS



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/79A371CA9F0942B28C1C4E9401C36BB2@GODFREYPC

Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID smart card readers

[Hendrik Sattler]

Zitat von Godfrey Chung :

Before we started the driver project in 2009, we had requested to  
join as a developer for libccid in alioth.debian.org but the author  
rejected us with no reason. As the same time, our customer pushed us  
to release Linux driver. Therefore, we decided to release our Linux  
driver based on libccid and had a plan to release our driver to any  
Linux Distributions.


But libccid evolves and forks of such projects do usually not follow.  
This leaves both in a rather sad situation. Did you track the changes  
of 1.3.12 and 1.3.13? Any intention to rebase the work on 1.4.x so  
libusb-1.0 gets used instead of libusb-0.1?


For the Windows platform, we also release our own driver. It is  
because the generic driver does not work with multi-slot smart card  
readers and we can control our driver source code to fix bugs from  
the readers.


The Windows driver is also not very standard-compliant and does nasty  
things. It took me 30min on XP and Vista to get a bluescreen from it :-/
Note that there is also libusb-win32, making it potentially possible  
to use the same source there (ignoring the Microsoft driver for it)  
once it is compatible with (or integrated into) libusb-1.0.


Please note that libccid upstream author and Debian maintainer are  
same person. He may reject our changes.


Let's CC him so that he can comment...

HS



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110518104806.17831ti5w4pzq...@v1539.ncsrv.de

Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID smart card readers

[Ludovic Rousseau]

Hello,

2011/5/18 Hendrik Sattler :
> Zitat von Godfrey Chung :
>
>> Before we started the driver project in 2009, we had requested to join as
>> a developer for libccid in alioth.debian.org but the author rejected us with
>> no reason. As the same time, our customer pushed us to release Linux driver.
>> Therefore, we decided to release our Linux driver based on libccid and had a
>> plan to release our driver to any Linux Distributions.

Godfrey, I do not remember rejecting your request. The normal steps
are first to send good patches to the project before requesting to
join. You do not need to be on alioth.debian.org to participate to the
development of libccid.

Godfrey, do you participate on the MUSCLE (Movement for Using Smart
Card in a Linux Environment) mailing list [1]?

I could not find any message from "Godfrey Chung" in my email archives.

> But libccid evolves and forks of such projects do usually not follow. This
> leaves both in a rather sad situation. Did you track the changes of 1.3.12
> and 1.3.13? Any intention to rebase the work on 1.4.x so libusb-1.0 gets
> used instead of libusb-0.1?

Good question.

>> Please note that libccid upstream author and Debian maintainer are same
>> person. He may reject our changes.
>
> Let's CC him so that he can comment...

Thanks for the notice.

Godfrey, are you a Debian Developer? If not the bug should be an RFP
instead of ITP. But that is a minor point.

Bye,

[1] http://musclecard.com/list.html

-- 
 Dr. Ludovic Rousseau


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktikqprmnpy8s6ntjgnevte4rfr+...@mail.gmail.com

Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID smart card readers

[Didier Raboud]

Le mercredi, 18 mai 2011 11.56:39, Ludovic Rousseau a écrit :
> Godfrey, are you a Debian Developer? If not the bug should be an RFP
> instead of ITP. But that is a minor point.

Wrong. Anyone can submit an ITP if he Intends To Package something. Getting 
it uploaded by a DD is then still mandatory to get the package to the 
archive, but said DD will not be the maintainer of the package.

-- 
OdyX


signature.asc
Description: This is a digitally signed message part.

Re: Bug#627105: ITP: configshell -- python framework for building simple CLI-based applications

[Salvo Tomaselli]

On Tuesday 17 May 2011 20:19:54 Ritesh Raj Sarraf wrote:


> * URL : http://www.risingtidesystems.com
Are you sure this is the url of the project?


-- 
Salvo Tomaselli


signature.asc
Description: This is a digitally signed message part.

Arbitrary-length numbers

[Тони Стоев | Toni Stoev]

Hi people,

I would like to discuss a complex issue with you that could take up several 
swirls of discussion, inclusively in other places with other people.

Here's an idea of writing and reading arbitrarily long numbers, generally 
integers in binary form:
Write the number in such a way that when reading it you can do without knowing 
its maximum length.
Read the number being normally limited by computational resources and not by a 
predefined mental maximum.

Why so, what is the gain? Just a cruel example: use of numbers in network 
addresses.
Node addresses can be adequate in size to fit local needs, not squeezing the 
universal expansion of the network.

So here is an algorithm for this writing/reading:

Binary Indicators-Termination Sequence: A pattern for writing down and 
recognition of binary integer numbers, which consist of arbitrary count of bits
A binary indicators-termination sequence (BIT sequence) is the following binary 
sequence for a given unsigned integer:
– bits in reverse order of a binary sequence formed for the given unsigned 
integer by the following rules:
1) Each component number is in binary form and contains only significant bits 
ordered by significance ascendingly.
2) The given unsigned integer is a component of the sequence.
3) If the given unsigned integer is not zero, before that number the sequence 
contains a single bit set to zero. (termination)
4) Immediately after each component number with count of bits greater than one, 
a number, less by one than that count, follows as a component. (indicators)

I know there are numerous software libraries for arbitrary-precision 
arithmetic. Don't know whether any of them implement a universal algorithm.

Would you encourage use of arbitrary-length numbers in any area of 
implementation? And would you advocate software development for that purpose?

Related topics:
Processor architecture: CPU ALUs
Network architecture: Addressing


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201105181443.10640.ent...@tonistoev.info

Arbitrary-length numbers

[Тони Стоев | Toni Stoev]

Hi people,

I would like to discuss a complex issue with you that could take up several 
swirls of discussion, inclusively in other places with other people.

Here's an idea of writing and reading arbitrarily long numbers, generally 
integers in binary form:
Write the number in such a way that when reading it you can do without knowing 
its maximum length.
Read the number being normally limited by computational resources and not by a 
predefined mental maximum.

Why so, what is the gain? Just a cruel example: use of numbers in network 
addresses.
Node addresses can be adequate in size to fit local needs, not squeezing the 
universal expansion of the network.

So here is an algorithm for this writing/reading:

Binary Indicators-Termination Sequence: A pattern for writing down and 
recognition of binary integer numbers, which consist of arbitrary count of bits
A binary indicators-termination sequence (BIT sequence) is the following binary 
sequence for a given unsigned integer:
– bits in reverse order of a binary sequence formed for the given unsigned 
integer by the following rules:
1) Each component number is in binary form and contains only significant bits 
ordered by significance ascendingly.
2) The given unsigned integer is a component of the sequence.
3) If the given unsigned integer is not zero, before that number the sequence 
contains a single bit set to zero. (termination)
4) Immediately after each component number with count of bits greater than one, 
a number, less by one than that count, follows as a component. (indicators)

I know there are numerous software libraries for arbitrary-precision 
arithmetic. Don't know whether any of them implement a universal algorithm.

Would you encourage use of arbitrary-length numbers in any area of 
implementation? And would you advocate software development for that purpose?

Related topics:
Processor architecture: CPU ALUs
Network architecture: Addressing


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201105181501.26607.deb...@tonistoev.info

Re: Additional info about recommended/suggested packages

[Eshat Cakar]

> In Debian we do this via package descriptions since the
> recommends/suggests are not meant to be human readable information.

The DPM does not mention information about suggested/recommended
packages in the description field [1]. Only "significant dependencies
and conflicts" are named.
This might be the reason why most maintainers do not use the
description for that, in fact I couldn't find any package listing the
recommended packages in the package-description.

> I would suggest filing bugs on any packages you feel could benefit
> from such information in the package description.

Anyway, I'm not sure if that's the way to go:
- it is not up on the users to know what recommends do, the maintainer
  should know first
- the way bugs are fixed might not be clean, since each
  maintainer will use his syntax, providing the users a not uniform way

[1] http://lists.debian.org/debian-devel/2011/05/msg00701.html

-- 
eshat cakar
web: www.eshat.degpg-id: 799B 95D5
gpg-fingerprint: D59E 3B77 8662 D221 0900 D758 9D0F C2C1 799B 95D5


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110518141359.7ff83...@fox40.math.uni-bielefeld.de

Re: Re: Additional info about recommended/suggested packages

[Eshat Cakar]

> [1] http://lists.debian.org/debian-devel/2011/05/msg00701.html

Of course that should be
[1] http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110518151101.0cdd6...@fox40.math.uni-bielefeld.de

Bug#627201: ITP: libcrypt-cracklib-perl -- Perl interface to the Cracklib password strength check library

[Dominic Hargreaves]

Package: wnpp
Severity: wishlist
Owner: Dominic Hargreaves 

* Package name: libcrypt-cracklib-perl
  Version : 1.4
  Upstream Author : Dan Sully 
* URL : http://search.cpan.org/dist/Crypt-Cracklib/
* License : Perl
  Programming Lang: Perl
  Description : Perl interface to the Cracklib password strength check 
library

This package provides a Perl interface to Cracklib, the password strong
checking library.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110518170831.10591.61210.report...@urchin.earth.li

httpd-cgi is it really CGI or maybe *CGI instead

[Anton Martchukov]

Hello All.

I wanted to install MoinMoin wiki (python-moinmoin) using
FastCGI on nginx web server (nginx-full), but python-moinmoin
brings Apache web server into the system due to its
dependencies:

python-moinmoin depends on libapache2-mod-wsgi | httpd-cgi

nginx-full provides httpd

I would submit a bug report on any of those packages, but 
it does not appear clear to me:

1. Virtual package httpd-cgi is this only plain CGI or also
can be FactCGI too? In case with nginx, it does not support
plain old CGI, but does support FastCGI (plus SCGI and WSGI).

2. libapache2-mod-wsgi is not the only WSGI web server
available. 

3. moinmoin is not limited to WCGI and CGI and also can
be run with built-in web server, FastCGI, SCGI and AJP.

The bottom line is that we are probably missing a bunch of
virtual packages like:

httpd-fastcgi
httpd-wsgi
httpd-scgi
httpd-ajp

At least I would bet for the first two ones (httpd-fastcgi and
httpd-wsgi).

- Anton

-- 
Anton Martchukov
http://www.martchukov.com


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110518165123.ga26...@algol.martchukov.com

Re: httpd-cgi is it really CGI or maybe *CGI instead

[Russ Allbery]

Anton Martchukov  writes:

> I wanted to install MoinMoin wiki (python-moinmoin) using
> FastCGI on nginx web server (nginx-full), but python-moinmoin
> brings Apache web server into the system due to its
> dependencies:

> python-moinmoin depends on libapache2-mod-wsgi | httpd-cgi

> nginx-full provides httpd

> I would submit a bug report on any of those packages, but 
> it does not appear clear to me:

> 1. Virtual package httpd-cgi is this only plain CGI or also
> can be FactCGI too? In case with nginx, it does not support
> plain old CGI, but does support FastCGI (plus SCGI and WSGI).

> 2. libapache2-mod-wsgi is not the only WSGI web server
> available. 

> 3. moinmoin is not limited to WCGI and CGI and also can
> be run with built-in web server, FastCGI, SCGI and AJP.

> The bottom line is that we are probably missing a bunch of
> virtual packages like:

> httpd-fastcgi
> httpd-wsgi
> httpd-scgi
> httpd-ajp

httpd-wsgi has already been requested.  See #588497.  So far, no one seems
to have run into a practical requirement for the others, although if you
have some cases where we'd use them (as opposed to just a theoretical
need), please do file a debian-policy bug about that.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxijgb8k@windlord.stanford.edu

Re: httpd-cgi is it really CGI or maybe *CGI instead

[Jérémy Lal]

On 18/05/2011 19:38, Russ Allbery wrote:
> Anton Martchukov  writes:
> 
>> I wanted to install MoinMoin wiki (python-moinmoin) using
>> FastCGI on nginx web server (nginx-full), but python-moinmoin
>> brings Apache web server into the system due to its
>> dependencies:
> 
>> python-moinmoin depends on libapache2-mod-wsgi | httpd-cgi
> 
>> nginx-full provides httpd
> 
>> I would submit a bug report on any of those packages, but 
>> it does not appear clear to me:
> 
>> 1. Virtual package httpd-cgi is this only plain CGI or also
>> can be FactCGI too? In case with nginx, it does not support
>> plain old CGI, but does support FastCGI (plus SCGI and WSGI).
> 
>> 2. libapache2-mod-wsgi is not the only WSGI web server
>> available. 
> 
>> 3. moinmoin is not limited to WCGI and CGI and also can
>> be run with built-in web server, FastCGI, SCGI and AJP.
> 
>> The bottom line is that we are probably missing a bunch of
>> virtual packages like:
> 
>> httpd-fastcgi
>> httpd-wsgi
>> httpd-scgi
>> httpd-ajp

+1
especially for the distinction between httpd-fcgi and httpd-cgi.
Note that "fcgi" name is more used than "fastcgi" in packages names.

> httpd-wsgi has already been requested.  See #588497.  So far, no one seems
> to have run into a practical requirement for the others, although if you
> have some cases where we'd use them (as opposed to just a theoretical
> need), please do file a debian-policy bug about that.

I have the feeling it is a good idea to enforce web servers to declare their
abilities like that. Today many webapps can run through fcgi, whether they are
in php, ruby, c... but they can't state that fact in their control fields.
Instead, i've seen some of them depend on apache2, whereas they can run with
any other httpd-fcgi (example: roundcube-core)
Trouble is i'm not good at argumenting this in a bug report.

Jérémy.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dd40815.5020...@melix.org

New virtual package(s) for different kinds of httpd (fastcgi etc)

[Jan Hauke Rahm]

Package: debian-policy
Version: 3.9.2.0
Severity: wishlist

On Wed, May 18, 2011 at 07:55:33PM +0200, Jérémy Lal wrote:
> On 18/05/2011 19:38, Russ Allbery wrote:
> > Anton Martchukov  writes:
> > 
> >> I wanted to install MoinMoin wiki (python-moinmoin) using
> >> FastCGI on nginx web server (nginx-full), but python-moinmoin
> >> brings Apache web server into the system due to its
> >> dependencies:
> > 
> >> python-moinmoin depends on libapache2-mod-wsgi | httpd-cgi
> > 
> >> nginx-full provides httpd
> > 
> >> I would submit a bug report on any of those packages, but 
> >> it does not appear clear to me:
> > 
> >> 1. Virtual package httpd-cgi is this only plain CGI or also
> >> can be FactCGI too? In case with nginx, it does not support
> >> plain old CGI, but does support FastCGI (plus SCGI and WSGI).
> > 
> >> 2. libapache2-mod-wsgi is not the only WSGI web server
> >> available. 
> > 
> >> 3. moinmoin is not limited to WCGI and CGI and also can
> >> be run with built-in web server, FastCGI, SCGI and AJP.
> > 
> >> The bottom line is that we are probably missing a bunch of
> >> virtual packages like:
> > 
> >> httpd-fastcgi
> >> httpd-wsgi
> >> httpd-scgi
> >> httpd-ajp
> 
> +1
> especially for the distinction between httpd-fcgi and httpd-cgi.
> Note that "fcgi" name is more used than "fastcgi" in packages names.
> 
> > httpd-wsgi has already been requested.  See #588497.  So far, no one seems
> > to have run into a practical requirement for the others, although if you
> > have some cases where we'd use them (as opposed to just a theoretical
> > need), please do file a debian-policy bug about that.
> 
> I have the feeling it is a good idea to enforce web servers to declare their
> abilities like that. Today many webapps can run through fcgi, whether they are
> in php, ruby, c... but they can't state that fact in their control fields.
> Instead, i've seen some of them depend on apache2, whereas they can run with
> any other httpd-fcgi (example: roundcube-core)
> Trouble is i'm not good at argumenting this in a bug report.

I think you've made yourself clear. Let's just open the bug with this
mail to track what's already been said.

Hauke

-- 
 .''`.   Jan Hauke Rahmwww.jhr-online.de
: :'  :  Debian Developer www.debian.org
`. `'`   Member of the Linux Foundationwww.linux.com
  `- Fellow of the Free Software Foundation Europe  www.fsfe.org


signature.asc
Description: Digital signature

Re: Bug#627105: ITP: configshell -- python framework for building simple CLI-based applications

[Ritesh Raj Sarraf]

On 05/18/2011 03:49 PM, Salvo Tomaselli wrote:
> On Tuesday 17 May 2011 20:19:54 Ritesh Raj Sarraf wrote:
> 
> 
>> * URL : http://www.risingtidesystems.com
> Are you sure this is the url of the project?
> 
> 
http://www.risingtidesystems.com/git/

sorry about that.

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System



signature.asc
Description: OpenPGP digital signature

Bug#627255: ITP: zita-rev1 -- reworked version of the reverb originally developed for Aeolus

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: zita-rev1
  Version : 0.1.1
  Upstream Author : Fons Adriaensen 
* URL : 
http://kokkinizita.linuxaudio.org/linuxaudio/zita-rev1-doc/quickguide.html
* License : GPL
  Programming Lang: C++
  Description : reworked version of the reverb originally developed for 
Aeolus

 REV1's character is more 'hall' than 'plate', but it can be used on
 a wide variety of instruments or voices. It is not a spatialiser -
 the early reflections are different for the L and R inputs, but do
 not correspond to any real room. They have been tuned to match left
 and right sources to some extent.
 .
 In Stereo mode a dry/wet mix control is provided, so it can be used
 either as an insert or in send/return mode. For mono just connect one
 of the two channels.
 .
 In Ambisonic mode (selected by the -B command line option) the only
 option is the send/return mode.
 .
 This package provide REV1, a standalone reverb effect.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110518232333.27016.47860.reportbug@alessio-laptop

Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID smart card readers

[Godfrey Chung]

Yes, we track the changes on every libccid release and update back to 
acsccid release if the changes are correct. Starting from libccid 1.3.11, we 
found that libccid blacklisted our best selling reader "ACR122U" of some 
firmware versions (< 2.06). Therefore, it made our customer getting into 
trouble and created a storm of customer complaints. We introduced them to 
use our officially supported driver.


Starting from libccid 1.3.12, we found that it did not maintain backward 
compatibility. The users are required to upgrade pcsc-lite to 1.6.x and 
libusb to 1.0.x. We have a lot of customer using old Linux distributions and 
these required components will not be ported. We must maintain our quality 
standard and customer satisfaction. However, acsccid can be used with 
pcsc-lite 1.3.3 - 1.7.x and kept to use libusb 0.1.x. We also consider to 
use libusb 1.0.x on future release but the driver will be modified to use 
either libusb 0.1.x or libusb 1.0.x to maintain backward compatibility. Next 
release of our driver also include ACS non-CCID readers support.


Godfrey

-Original Message- 
From: Hendrik Sattler

Sent: Wednesday, May 18, 2011 4:48 PM
To: Godfrey Chung
Cc: 627...@bugs.debian.org ; debian-devel@lists.debian.org ; 
rouss...@debian.org
Subject: Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID 
smart card readers


Zitat von Godfrey Chung :

Before we started the driver project in 2009, we had requested to  join as 
a developer for libccid in alioth.debian.org but the author  rejected us 
with no reason. As the same time, our customer pushed us  to release Linux 
driver. Therefore, we decided to release our Linux  driver based on 
libccid and had a plan to release our driver to any  Linux Distributions.


But libccid evolves and forks of such projects do usually not follow.
This leaves both in a rather sad situation. Did you track the changes
of 1.3.12 and 1.3.13? Any intention to rebase the work on 1.4.x so
libusb-1.0 gets used instead of libusb-0.1?

For the Windows platform, we also release our own driver. It is  because 
the generic driver does not work with multi-slot smart card  readers and 
we can control our driver source code to fix bugs from  the readers.


The Windows driver is also not very standard-compliant and does nasty
things. It took me 30min on XP and Vista to get a bluescreen from it :-/
Note that there is also libusb-win32, making it potentially possible
to use the same source there (ignoring the Microsoft driver for it)
once it is compatible with (or integrated into) libusb-1.0.

Please note that libccid upstream author and Debian maintainer are  same 
person. He may reject our changes.


Let's CC him so that he can comment...

HS



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/E6EBDFA9262B4D578EE6E6AE3EAC0E9F@GODFREYPC

Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID smart card readers

[Godfrey Chung]

Thank you for your information. I think you should provide some instructions 
on alioth.debian.org and not reject us with no reason.


No, I did not subscribe MUSCLE mailing list.

No, I am not a Debian Developer. I am looking for sponsor to upload our 
package and I follow the steps from Developer Reference. Therefore, I chose 
ITP.


Godfrey

-Original Message- 
From: Ludovic Rousseau

Sent: Wednesday, May 18, 2011 5:56 PM
To: Hendrik Sattler ; Godfrey Chung
Cc: 627...@bugs.debian.org ; debian-devel@lists.debian.org
Subject: Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID 
smart card readers


Hello,

2011/5/18 Hendrik Sattler :

Zitat von Godfrey Chung :


Before we started the driver project in 2009, we had requested to join as
a developer for libccid in alioth.debian.org but the author rejected us 
with
no reason. As the same time, our customer pushed us to release Linux 
driver.
Therefore, we decided to release our Linux driver based on libccid and 
had a

plan to release our driver to any Linux Distributions.


Godfrey, I do not remember rejecting your request. The normal steps
are first to send good patches to the project before requesting to
join. You do not need to be on alioth.debian.org to participate to the
development of libccid.

Godfrey, do you participate on the MUSCLE (Movement for Using Smart
Card in a Linux Environment) mailing list [1]?

I could not find any message from "Godfrey Chung" in my email archives.


But libccid evolves and forks of such projects do usually not follow. This
leaves both in a rather sad situation. Did you track the changes of 1.3.12
and 1.3.13? Any intention to rebase the work on 1.4.x so libusb-1.0 gets
used instead of libusb-0.1?


Good question.


Please note that libccid upstream author and Debian maintainer are same
person. He may reject our changes.


Let's CC him so that he can comment...


Thanks for the notice.

Godfrey, are you a Debian Developer? If not the bug should be an RFP
instead of ITP. But that is a minor point.

Bye,

[1] http://musclecard.com/list.html

--
Dr. Ludovic Rousseau 



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8DAE5E21224C4CC88275860B1DC3A476@GODFREYPC

Re: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID smart card readers

[Godfrey Chung]

Thank you for your clarification.

-Original Message- 
From: Didier Raboud

Sent: Wednesday, May 18, 2011 6:06 PM
To: Ludovic Rousseau
Cc: Hendrik Sattler ; Godfrey Chung ; 627...@bugs.debian.org ; 
debian-devel@lists.debian.org
Subject: Bug#627038: ITP: libacsccid -- PC/SC driver for ACS USB CCID smart 
card readers


Le mercredi, 18 mai 2011 11.56:39, Ludovic Rousseau a écrit :

Godfrey, are you a Debian Developer? If not the bug should be an RFP
instead of ITP. But that is a minor point.


Wrong. Anyone can submit an ITP if he Intends To Package something. Getting
it uploaded by a DD is then still mandatory to get the package to the
archive, but said DD will not be the maintainer of the package.

--
OdyX


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/0624333F990C45A98ADDF80D3490ECE3@GODFREYPC

Bug#627262: ITP: klustakwik -- spike sorting tool

[NeuroDebian Team]

Package: wnpp
Severity: wishlist
Owner: NeuroDebian Team 

* Package name: klustakwik
  Version : 2.0.1
  Upstream Author : Ken Harris (har...@axon.rutgers.edu)
* URL : http://sourceforge.net/projects/klustakwik/
* License : GPL-2+
  Programming Lang: C/C++
  Description : automatic sorting of the samples (spikes) into clusters

 KlustaKwik is a program for automatic clustering of continuous data
 into a mixture of Gaussians. The program was originally developed for
 sorting of neuronal action potentials, but can be applied to any sort
 of data.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110519025327.26939.26373.report...@novo.onerussian.com

Re: httpd-cgi is it really CGI or maybe *CGI instead

[Vincent Bernat]

OoO Pendant  le repas du  mercredi 18 mai  2011, vers 19:55,  Jérémy Lal
 disait :

> I have the feeling it is a good idea to enforce web servers to declare their
> abilities like that. Today many webapps can run through fcgi, whether they are
> in php, ruby, c... but they can't state that fact in their control fields.
> Instead, i've seen some of them depend on apache2, whereas they can run with
> any other httpd-fcgi (example: roundcube-core)

roudncube-core depends on apache2 | lighttpd | httpd, php5.

Therefore,  you  can  install  it   with  nginx  and  php5-cgi  (or  now
php5-fpm).  The presence  of "apache2"  is  merely a  default here.  The
presence of "lighttpd"  may be removed since this  is neither a default,
neither a dependency that is not stated in httpd.
-- 
Vincent Bernat
http://www.luffy.cx


pgpcdhOEhvluF.pgp
Description: PGP signature

Suspend/Hibernate Resume in debian

[Arief M Utama]

Hi all,


First, I gotta say thanks for the awesome work in debian. I'm not a DD, 
just a long time debian user, been using it since potato era (wow, 
that's a long time) and I could testify that it has been a fun and 
joyful ride :)


I wanna help test and improve suspend-resume framework in debian, from 
time to time, suspend-resume has not yet been reliable enough for me.


Latest try with only pm-utils package, I can do hibernate and resume 
just fine, but suspend and resume does not work, suspend ok, resume fail.


With pm-utils+uswsusp, I can suspend-resume just fine, but 
hibernate-resume does not work, same thing, hibernate ok, resume fail, 
on resume I can see the progress of loading back the image data and it 
goes through to 100% but then it just stop there. Magic sysrq reboot 
worked though.


I wanna file bug, but not sure against which package and I wanna try 
gather more info first before I do it. Like how does it work now without 
hal?


My current test system is a Sony Vaio laptop, with 
testing/unstable/experimental repository configured (I need experimental 
for gnome3 packages).


Do we have a database of quirks and workarounds for suspend-resume? I've 
only been reading wiki.debian.org/Suspend and not sure if it's up to 
date (still mentioned hal) and it does not have links to such database.


Anything I could provide for more info?

Thanks for the help.

All the best.
-arief


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dd4be6b.1000...@gmail.com

Re: Bug#627201: ITP: libcrypt-cracklib-perl -- Perl interface to the Cracklib password strength check library

[Andrei Popescu]

On Mi, 18 mai 11, 18:08:31, Dominic Hargreaves wrote:
> 
> This package provides a Perl interface to Cracklib, the password strong
> checking library.

I'm guessing s/strong/strength/ ;)

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature