Bug#683863: [Fingerforce-devel] Bug#683863: libfprint0: udev rules not applied when libfprint0 is installed
tags 683863 + patch usertags 683863 + debian-packaging thanks Hi there! On Sat, 11 Aug 2012 04:00:57 +0200, Marco d'Itri wrote: On Aug 05, Didier Raboud did...@raboud.com wrote: 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= --attr-match=idProduct= 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? OP is correct: this kind of rules are not magically applied to existing devices when they are installed, so your package needs to use udevadm trigger in postinst to synthesize change uevents for the installed hardware. Attached an untested Git patch, which limit the events to only the devices the package support: I will push it in one week if no one complains, as well as ask for a wheezy unblock. Please note that IMHO dh_installudev should be expanded to handle the creation of the `udevadm trigger` calls, see: http://bugs.debian.org/697362 Thx, bye, Gismo / Luca From f1defc544b4277d8cae718c4b37e77103e95675a Mon Sep 17 00:00:00 2001 From: Luca Capello l...@pca.it Date: Fri, 4 Jan 2013 13:29:38 +0100 Subject: [PATCH] debian/libfprint0.postinst: (#683863) apply udev rules at install --- debian/changelog |7 +++ debian/libfprint0.postinst | 31 +++ 2 files changed, 38 insertions(+) create mode 100644 debian/libfprint0.postinst diff --git a/debian/changelog b/debian/changelog index 896b58e..3f92aff 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +libfprint (1:0.4.0-4-gdfff16f-5) UNRELEASED; urgency=low + + * debian/libprint0.postinst: ++ apply udev rules at package installation (Closes: #683863). + + -- + libfprint (1:0.4.0-4-gdfff16f-4) unstable; urgency=low * Fix libusb global variables FTBFS. (Closes: #680838) diff --git a/debian/libfprint0.postinst b/debian/libfprint0.postinst new file mode 100644 index 000..61bf030 --- /dev/null +++ b/debian/libfprint0.postinst @@ -0,0 +1,31 @@ +#!/bin/sh + +set -e + +#DEBHELPER# + +if [ $1 = configure -o $1 = upgrade ]; then + # apply udev rules at package installation, see + # http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683863#27 + # NOTA BENE: after the DEBHELPER section since dh_installudev + # adds stuff there + udevadm trigger --action=add --attr-match=idVendor=0483 --attr-match=idProduct=2016 + udevadm trigger --action=add --attr-match=idVendor=147e --attr-match=idProduct=2016 + udevadm trigger --action=add --attr-match=idVendor=08ff --attr-match=idProduct=5501 + udevadm trigger --action=add --attr-match=idVendor=08ff --attr-match=idProduct=2500 + udevadm trigger --action=add --attr-match=idVendor=08ff --attr-match=idProduct=2580 + udevadm trigger --action=add --attr-match=idVendor=045e --attr-match=idProduct=00bb + udevadm trigger --action=add --attr-match=idVendor=045e --attr-match=idProduct=00bc + udevadm trigger --action=add --attr-match=idVendor=045e --attr-match=idProduct=00bd + udevadm trigger --action=add --attr-match=idVendor=045e --attr-match=idProduct=00ca + udevadm trigger --action=add --attr-match=idVendor=05ba --attr-match=idProduct=0007 + udevadm trigger --action=add --attr-match=idVendor=05ba --attr-match=idProduct=0008 + udevadm trigger --action=add --attr-match=idVendor=05ba --attr-match=idProduct=000a + udevadm trigger --action=add --attr-match=idVendor=061a --attr-match=idProduct=0110 + udevadm trigger --action=add --attr-match=idVendor=061a --attr-match=idProduct=1000 + udevadm trigger --action=add --attr-match=idVendor=08ff --attr-match=idProduct=1600 + udevadm trigger --action=add --attr-match=idVendor=138a --attr-match=idProduct=0001 + udevadm trigger --action=add --attr-match=idVendor=08ff --attr-match=idProduct=2810 +fi + +exit 0 -- 1.7.10.4 pgpVKfgYQl3Yb.pgp Description: PGP signature
Bug#683863: libfprint0: udev rules not applied when libfprint0 is installed
On Aug 05, Didier Raboud did...@raboud.com wrote: 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= --attr-match=idProduct= 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? OP is correct: this kind of rules are not magically applied to existing devices when they are installed, so your package needs to use udevadm trigger in postinst to synthesize change uevents for the installed hardware. -- ciao, Marco signature.asc Description: Digital signature
Bug#683863: [Fingerforce-devel] Bug#683863: libfprint0: udev rules not applied when libfprint0 is installed
Hi there! On Sun, 05 Aug 2012 16:17:02 +0200, Andrew Pimlott wrote: Excerpts from Didier Raboud's message of Sun Aug 05 02:33:45 -0700 2012: Le samedi, 4 août 2012 23.56:02, Andrew Pimlott a écrit : 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. That sound reasonable. I would definitely be happy with a solution that covers other packages. The only thing that might be different is that most other devices you can simply remove and plug in again. I can't do that with my build-in fingerprint reader. IMHO this is enough for libfprint being a special case. 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. That doesn't sound reasonable to me! I'm not used to rebooting after I install packages, even if they are desktop-oriented. Not reasonable to me either and `man udevadm` does not say anything about reboot. Marco, do you have any suggestion? Thx, bye, Gismo / Luca pgpArlykLQ2fs.pgp Description: PGP signature
Bug#683863: libfprint0: udev rules not applied when libfprint0 is installed
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= --attr-match=idProduct= 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.
Bug#683863: libfprint0: udev rules not applied when libfprint0 is installed
Excerpts from Didier Raboud's message of Sun Aug 05 02:33:45 -0700 2012: Le samedi, 4 août 2012 23.56:02, Andrew Pimlott a écrit : 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? Right, I should have said: the udev rules never fire until a reboot. So the fingerprint reader doesn't work until a reboot. 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. That sound reasonable. I would definitely be happy with a solution that covers other packages. The only thing that might be different is that most other devices you can simply remove and plug in again. I can't do that with my build-in fingerprint reader. 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. That doesn't sound reasonable to me! I'm not used to rebooting after I install packages, even if they are desktop-oriented. Thanks, Andrew -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683863: libfprint0: udev rules not applied when libfprint0 is installed
Package: libfprint0 Version: 1:0.4.0-4-gdfff16f-4 Severity: normal Dear Maintainer, 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. The result is that after installing the package, the fingerprint reader does not work for non-root users. libfprint0 should trigger the udev rules when it installs them. 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= --attr-match=idProduct= Possible dh_installudev should help you with this. Andrew -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libfprint0 depends on: ii libc6 2.13-33 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-02.32.3-1 ii libnspr42:4.9.1-1 ii libnspr4-0d 2:4.9.1-1 ii libnss3 2:3.13.5-1 ii libnss3-1d 2:3.13.5-1 ii libusb-1.0-02:1.0.11-1 ii multiarch-support 2.13-33 libfprint0 recommends no packages. libfprint0 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
