[arch-dev-public] New package group in extra: fprint
The fprint project (http://www.reactivated.net/fprint/wiki/Main_Page) has been around for about 3 months now and produced quite usable results. Right now, there are three packages: - libfprint A library that abstracts the tasks of enrolling and verifying fingerprints and includes hardware drivers. Currently only USB readers are supported and are accessed using libusb. There is no stable API yet, however the library is in a usable and stable state. Note that many common USB fingerprint readers and laptop builtin readers are supported, including the ones supported by the thinkfinger project! - fprint_demo This application demonstrates what libfprint can currently do. You can enroll fingerprints, verify your fingers or identify fingers from a set of enrolles prints. - pam_fprint This pam plugin allows authenticating with your fingerprint. It currently only checks your finger against the first enrolled print it can find in your $HOME and is not configurable. I am adding these packages to extra now.
On Jan 8, 2008 2:20 AM, Thomas Bächler
The fprint project (http://www.reactivated.net/fprint/wiki/Main_Page) has been around for about 3 months now and produced quite usable results. Right now, there are three packages:
- libfprint A library that abstracts the tasks of enrolling and verifying fingerprints and includes hardware drivers. Currently only USB readers are supported and are accessed using libusb. There is no stable API yet, however the library is in a usable and stable state. Note that many common USB fingerprint readers and laptop builtin readers are supported, including the ones supported by the thinkfinger project!
- fprint_demo This application demonstrates what libfprint can currently do. You can enroll fingerprints, verify your fingers or identify fingers from a set of enrolles prints.
- pam_fprint This pam plugin allows authenticating with your fingerprint. It currently only checks your finger against the first enrolled print it can find in your $HOME and is not configurable.
I am adding these packages to extra now.
Now, I don't want to be rude or anything, and this specific set of packages are for hardware support, so odds are no one would disagree with them - but while you were away we agreed to discuss packages that go into extra beforehand. It's just a minor protection mechanism against getting special case packages pulled into extra. I don't think too many people have a problem with additional hardware support, so this should be a moot point. But going forward, could we at least get some time to look into these things before they're moved to extra, just so we try to prevent the situation like we have currently, with hundreds of unused packages floating around in extra.
Aaron Griffin schrieb:
Now, I don't want to be rude or anything, and this specific set of packages are for hardware support, so odds are no one would disagree with them - but while you were away we agreed to discuss packages that go into extra beforehand.
I sort of missed that, but I will remember it. And I agree that nobody will object to hardware support. The situation could have been worse though: I could have pulled a completely useless package without asking first.
But going forward, could we at least get some time to look into these things before they're moved to extra
What is the rule here? - Ask and wait a few days until someone objects or - Ask and wait until someone agrees. The latter case would slow us down considerably, because often nobody even replies.
Thomas Bächler
What is the rule here? - Ask and wait a few days until someone objects or - Ask and wait until someone agrees.
Ask and wait a few days until someone objects. The point is to find people who have a problem with a package. I think by default I trust developers. -- .: [ + carpe diem totus tuus + ] :.
participants (3)
-
Aaron Griffin
-
Jeff 'codemac' Mickey
-
Thomas Bächler