tags 683863 +moreinfo thanks Le samedi, 4 août 2012 23.56:02, Andrew Pimlott a écrit : > Package: libfprint0 > Version: 1:0.4.0-4-gdfff16f-4 > Severity: normal > > Dear Maintainer,
Hi Andrew, and thanks for your bugreport, > libfprint0 installs some udev rules to make fingerprint readers > accessible to the plugdev group. However, since many fingerprint > readers are built-in to computers, they are never plugged in, and thus > the udev rules never fire. In my experience, that's partially wrong: the udev rules get run (at least) at boot time. Are you really experiencing this problem for a device or is it a theoretical problem? > The result is that after installing the > package, the fingerprint reader does not work for non-root users. If the udev rules don't get run, OK. > libfprint0 should trigger the udev rules when it installs them. I don't think that libfprint should be special-cased here. On my system, there are 32 different packages installing udev rules under /lib/udev/rules.d and libfprint is certainly not the only one that would benefit from "udevadm trigger" runs. In my understanding of the situation of the udev rules, there is a requirement to reboot to have things working correctly; and that's nothing libfprint should fix for its own benefit. > I think > this can be done with the "udevadm trigger" command. By default, this > will trigger change events for all devices. I'm not sure whether that > could have undesirable consequences. You could limit the events to just > fingerprint readers with a series of > > udevadm trigger --attr-match=idVendor=xxxx --attr-match=idProduct=xxxx > > Possible dh_installudev should help you with this. As mentionned above, I don't think it's libfprint's job to handle this: if deemed useful, it should be done by dh_installudev (that doesn't do much else than installing the udev rules file) or by a udev dpkg trigger. I'm CC'ing the udev maintainer to have his input on this. Marco: opinions? Cheers, OdyX
signature.asc
Description: This is a digitally signed message part.