Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 164876

Summary: <media-libs/libgphoto2-2.3.1-r2 messes up USB devices permissions
Product: Gentoo Linux Reporter: David Fellows <fellows>
Component: New packagesAssignee: Gentoo Linux bug wranglers <bug-wranglers>
Status: VERIFIED FIXED    
Severity: normal    
Priority: High    
Version: 2006.1   
Hardware: AMD64   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---

Description David Fellows 2007-02-01 17:20:29 UTC
I run a mostly stable system.
A recent upgrade to newly stable gphoto2-2.2.0 and accompanying glibphoto2-2.2.1-r1. Resulted in CUPSD being unable to access my usb printer.
Investigation showed:
 /dev/usb/lp0 was being created 0660 root.plugdev.
 The only udev rules in /etc/udev/rules.d that mention GROUP plugdev are in /etc/udev/rules.d/99-libgphoto2.rules.
 On amd64 latest stable udev is sys-fs/udev-087-r1.
 man udev mentions the matching key name SYSFS and makes no mention of key name ATTRs
 On x86 latest stable udev is  sys-fs/udev-103 and man udev mentions ATTRS and does not mention SYSFS.
 The libgphoto2.rules file contians lines like
ATTRS{idVendor}=="0553", ATTRS{idProduct}=="0202", MODE="660", GROUP="plugdev"
 In my log file there are entries like:
Jan 31 23:54:53 [udevd] add_to_rules: unknown key 'ATTRS{idProduct}', in 'ATTRS{
idVendor}'
 and the first line in the libgphoto2.rules file is

# udev rules file for libgphoto2 devices (udev >= 0.98)

It would appear that udev is discarding the unknown matching keys leaving an unconditional rule that makes /dev/usb/lp0 group plugdev.

I experimented with a global replace ATTRS with SYSFS in the libgphoto2.rules
and when I unplugged and replugged my printer /dev/usb/lp0 came back as group lp and all was well as far as the printer is concerned.  I haven't tested it with my camera.

suggested resolution:
 add >=sys-fs/udev-098 to RDEPEND in  media-libs/libgphoto2-2.2.1-r1  (and I suppose in 2.3* too)
 Mark  media-libs/libgphoto2-2.2.1-r1  and media-gfx/gphoto2-2.2.0 as unstable for all architectures that do not have udev-098 or higher marked stable.

Finally, unmerging libgphoto2 (and gphoto2) is not sufficient to solve the problem. /etc is protected so you have to manually delete /etc/udev/rules.d/99-libgphoto2.rules too.
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2007-02-01 17:23:38 UTC
(In reply to comment #0)
> It would appear that udev is discarding the unknown matching keys leaving an
> unconditional rule that makes /dev/usb/lp0 group plugdev.

Not udev's fault, the broken rule is installed by libgphoto2 and matches all USB devices. Anyway, fixed in >=libgphoto2-2.3.1-r2

*libgphoto2-2.3.1-r2 (31 Jan 2007)

  31 Jan 2007; Doug Goldstein <cardoe@gentoo.org>
  +files/libgphoto2-2.3.1-udev-rules-fix.diff, +libgphoto2-2.3.1-r2.ebuild:
  Fix for generating udev rules properly. Rather then recursive it just
  changes the device. Also don't accidentally match on VendorID=0.
Comment 2 David Fellows 2007-02-02 01:17:56 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > It would appear that udev is discarding the unknown matching keys leaving an
> > unconditional rule that makes /dev/usb/lp0 group plugdev.
> 
> Not udev's fault, the broken rule is installed by libgphoto2 and matches all
> USB devices. Anyway, fixed in >=libgphoto2-2.3.1-r2
> 
> *libgphoto2-2.3.1-r2 (31 Jan 2007)
> 
>   31 Jan 2007; Doug Goldstein <cardoe@gentoo.org>
>   +files/libgphoto2-2.3.1-udev-rules-fix.diff, +libgphoto2-2.3.1-r2.ebuild:
>   Fix for generating udev rules properly. Rather then recursive it just
>   changes the device. Also don't accidentally match on VendorID=0.
> 

Not really fixed.  The thrust of my bug is that emerging the latest stable libgphoto2 broke a system with the latest stable CUPS and latest stable udev for the amd64 arch.  To my twisted mind this means that the latest "stable" libgphoto2 is not, in fact, stable. The ebuild should be fixed either to really fix the problem or to mark it ~amd64.  

I emerged libgphoto2-2.3.1-r3 just to check it out. Yes, it no longer breaks printing which is good.  No, it is not going to behave as intended on a stable amd64 system because it is still installing a udev rules file full of ATTRS and stable udev on amd64 doesn't know what they are.  I'm not enough of a udev rule expert to know what it will do but it won't be what the implementer intended.

All the ebuilds  for lihgphoto2 packages that spit out udev rules containing ATTRS should explicitly specify >=udev-098 as a run time dep. Then portage will do the right thing.  Potential users can  make a decision  on what they want to do.

Unfortunately I can't test the camera behaviour because I got rid of the camera I originally was using gphoto2 for and my new camera is not on the supported list :-(  I don't have time right now to dig into how to add it. 
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2007-02-02 08:34:01 UTC
Works just fine w/ udev-104-r7 which will be stabilized soon (see Bug 159871)