Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 479722 - net-print/cups-1.6 and iscan-data shipped udev rules cause printing to fail
Summary: net-print/cups-1.6 and iscan-data shipped udev rules cause printing to fail
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: Normal normal (vote)
Assignee: Printing Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-04 13:10 UTC by Dimitris Mandalidis
Modified: 2017-02-18 18:35 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info output (emerge.info,4.85 KB, text/plain)
2013-08-04 13:10 UTC, Dimitris Mandalidis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitris Mandalidis 2013-08-04 13:10:31 UTC
Created attachment 355108 [details]
emerge --info output

When CUPS 1.6.x is configured to use libusb, iscan and iscan-data are installed, printing is failing silently, with a 'waiting for printer to become available' message.

It seems to me that that the problem lies into 99-iscan.rules file, as removing completely iscan packages or excluding 'udev' flag from iscan-data solved the problem.

versions:

cups-1.6.2-r5
iscan-2.26.2
iscan-data-1.22.0.1
sane-backends-1.0.23
Comment 1 Dimitris Mandalidis 2013-08-04 13:12:36 UTC
Same problem when using usblp.
Comment 2 Fabio Coatti 2013-12-29 14:31:13 UTC
After some digging, I can confirm this behaviour on my system

Basically the usb device, if iscan-rules are present, is placed "scanner" group, thus preventing cups to work properly.

by no means I'm an expert in udev rules, but this line in 99- iscan.rules seems suspect:

ENV{libsane_matched}=="yes", MODE="664", GROUP="scanner"

(commenting it solves the problem, just try and issue a )

It seems to me that this line sets unconditionally to "scanner" group if libsane_matched is yes.

Looking at other rules files, executed before this one, I spotted this in 56-hpmud.rules:

ATTR{idVendor}=="03f0", ATTR{idProduct}=="????", OWNER="root", GROUP="lp", MODE="0664", ENV{sane_hpaio}="yes", ENV{libsane_matched}="yes", ENV{hp_test}="yes", ENV{ID_HPLIP}
="1"

but my laserjet 1300 triggers this rule, even if it is not a scanner, due to vendor id:

Bus 002 Device 011: ID 03f0:1017 Hewlett-Packard LaserJet 1300

so, if env is preserved across rules files parsing,  libsane_matched is set to yes and the above mentioned rule in 99-iscan.rules makes the device belonging to scanner group and breaking cups.

My guess is that the rule in 56-hpmud.rules (ATTR{idVendor}=="03f0", ATTR{idProduct}=="????", OWNER="root", GROUP="lp", MODE="0664", ENV{sane_hpaio}="yes", ENV{libsane_matched}="yes", ENV{hp_test}="yes", ENV{ID_HPLIP}
="1") makes every device with idVendor =="03f0" a scanner and combined with the rule in iscan file (every device with libsane_matched == yes must be in scanner group) does the rest.

Commenting like I said before makes my setup working, but my guess is that both files must be fixed.
Comment 3 Matthew Schultz 2016-10-12 13:53:45 UTC
If this is still an issue, I don't believe this is a problem with iscan-data.  All iscan-data does is include the same rules coming from 41-libsane.rules which is provided by sane-backends.  If you look at the end of 41-libsane.rules, you'll see the line you're referring to as a problem.