[Fingerforce-devel] Bug#502138: fprintd: changing back from ITP to RFP

[Dererk]

On 14/05/12 10:34, Luca Capello wrote:
> Hi Didier!
>
> On Mon, 14 May 2012 14:29:16 +0200, Didier 'OdyX' Raboud wrote:
>> Le 14.05.2012 12:35, Luca Capello a écrit :
>>> It seems that the FingerForce SVN repository is no more visible on
>>> anonscm.debian.org, while it is still working on my local copy:
>> I don't mind to use SVN; it's just not really straightforward to see
>> where and how one can.
> No, no, use Git ;-)
>
>>>> I plan to upload the above (after push of the packaging to collab-maint)
>>>> before the end of the week; I would of course welcome co-maintainers and
>>>> any comments.
>>> I would prefer to keep everything under the FingerForce umbrella (the
>>> fact that this team is not in the form 'pkg-fingerprint' is an
>>> unfortunate effect, I would be more than welcome to rename everything!)
>>> and I am perfectly fine to move from SVN to Git.
>> Actually, the repository has Maintainer set as FingerForce, myself as
>> uploader. VCS is IMHO implementation detail.
> I do not agree: upstream uses Git, so there is no point is using
> anything else than Git, because the Debian packaging will simply be a
> Git branch.
>
> Please note that 1) I did not checked your package beforehand, sorry,
> and 2) my note above is true for any VCS, not only Git.
>
>>> - as I told you in Real Life™, how does today's fprint works WRT PAM
>>>   modules, i.e. could you use *both* fingerprint and password
>>>   authentication or should you still wait for fingerprint authentication
>>>   to fail to enter the password?  This was the major problem I found
>>>   when testing fprintd and it is IMHO a show-stopper.
>> This is addressed by upstream's pam/README:
>>
>>> * pam_fprintd doesn't support entering either the password or a
>>>   fingerprint, as pam_thinkfinger does, because it's a gross hack,
>>>   and could be fixed by having the login managers run 2 separate PAM
>>>   stacks
>> So although this might be seen as a showstopper, it is considered by
>> upstream as a responsibility of pam, not pam_*.
> How to run 2 separate PAM stacks should be at least discussed with the
> PAM maintainers, thus also fixing:
>
>   <http://bugs.debian.org/469059>
>
> However, from my very-limited experience with PAM (especially with
> libpam-ldapd) the fact that you need 2 separate PAM stacks is against
> PAM design, which actually enables delegating "authority" to another
> modules.  This is why the bug above is IMHO a show-stopper: I am fine if
> pam_fprintd obliges you to use the fingerprint, but this should not be
> the default.
>
>>> - how does libpam-fprintd plays with fingerprint-gui (see #666990),
>>>   given that the PAM configuration conflicts with it?
>> No idea, as I haven't tried. That said, I guess they would probably
>> conflict (Breaks:) as providing the same functionality and using the
>> same libfprint backend.
> IMHO if you add a conflict in the PAM configuration file this conflict
> should be reflected in the debian/control file as well.
>
>>> - overall, how well is fprintd integrated with the rest of the system?
>> Gnome is supposed to have fprintd integration since 2.26 and is reported
>> to work nicely in Gnome3:
>>
>> https://nfolamp.wordpress.com/2011/06/24/fedora-15-enabling-the-fingerprint-reader/
> I read similar reports in the past (way before fprint), but then in Real
> Life™ things were different.
>
>>>   Please note that while fingerprint authentication is nice, it is in
>>>   the end more problematic than useful (this is what I found out after
>>>   having started with so much enthusiasm), especially considering how
>>>   hardware upstream uses USB's VID/PID...
>> I think it would be good to have a packaged way to experiment that;
>> maybe we should target experimental instead.
> This is how it was done in the past, but nothing moved from there.
>
> Please do not take my comments as complaint-only: I would like to be
> able to use my fingerprint reader again, but when I moved to fprint from
> ThinkFinger a lot of stuff stopped working, simply because upstream
> thought differently (and the PAM issue above is another example).
>
>>> - actually, I would completely rework the Git repository (again, see
>>>   lua-ldap as an example), because:
>>>
>>>   1) upstream uses Git as well, thus we should simply start from there
>> That's what is done; see upstream branch which is the master branch from
>> http://cgit.freedesktop.org/libfprint/fprintd.
> This is not what I intended, sorry if I was not clear.  The lua-ldap
> package should clarify things: given that upstream is using Git, there
> is no point in having the Debian package using 'upstream' to refer to
> the upstream's 'master' branch.  So in your package 's/master/debian/'
> and 's/upstream/master/' ;-)
>
> Feel free to ask to be added to the FingerForce Alioth project!
>
> Thx, bye,
> Gismo / Luca

Hi all.

I've to apologies, since I'm very delayed with lots of FF tasks due to a
massive overflow on ~dererk/TODO's.

Totally perfectly fine switching from svn to git. I'm kind of a git/hg
fan myself, in fact that's something I think I started migrating 3
different times and couldn't finish any of them. +1

I've Just accepted OdyX request to join FF Taskforce. Congrats and
thanks for joining forces!


Cheers,

D

ps: OdyX, I've just upgraded your role to admin, so you have the
permissions to create a new git repository there.

-- 
BOFH excuse #316:
Elves on strike. (Why do they call EMAG Elf Magic)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/fingerforce-devel/attachments/20120514/9b62ef02/attachment.pgp>