[cups-devel] [UNKN] STR #4743: lpoption wrongly tries to fetch PPD directly from the printer
Richard Neuboeck <[email protected]>
| Newsgroups | gmane.comp.printing.cups.devel |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Description of problem: lpoptions -l should show the available printer options. Instead it fails with 'lpoptions: Unable to get PPD file for Printername: Not Found'. Tracing the network traffic shows that the client tries to fetch the PPD file directly from the printer instead of the print server. Of course the printer does not provide the PPD file so the request fails. Version-Release number of selected component (if applicable): According to a Debian Bug Report (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729713) it was introduced in 1.6.1-1 (http://cups.org/str.php?L4178). I'm currently testing cups-client-2.0.3-1.fc22.x86_64 running on Fedora (Fedora Bug Report: https://bugzilla.redhat.com/show_bug.cgi?id=1287585) How reproducible: always. Steps to Reproduce: 1. Set up printer server using IPP to access the network printer (i.e.: ipp://X.X.X.X/ipp) 2. Set up the client /etc/cups/client.conf to access 'ServerName printerserver'. Disable local printer server on the client. 3. Run lpoptions -l on the client. Actual results: [hawk@iconia ~]$ lpoptions -l lpoptions: Unable to get PPD file for Canon_PS: Not Found Expected results: [hawk@denobula ~]$ lpoptions -l Opt2CF/Cassette Feeding Unit: False *True ... Additional info: The problem does not seem to be new. This (old) Debian bug report describes the same problem and shows when the problematic code was introduced: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729713 The conclusion from the mentioned report is that due to the use of IPP cups thinks there is another cups server. Of course this works if you run a local cups daemon that needs to fetch the PPD from the 'real' server. In this case it mistakenly thinks it needs to fetch the PPD directly from the printer. Removing the two lines accessing ipp:// and ipps:// device-uri directly introduced here http://cups.org/str.php?L4178 resolves the problem. Link: https://www.cups.org/str.php?L4743 Version: 2.0.3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWYBj2AAoJENujp6sI12IjhbAP/2ezztLQUnYfuot8FnatkIiD lmHSr6nsQn4M2/pIXueIkXfwFBm7JBUoC+oeANp9d1RMb/u9od1s9BhHGUrHdDZX QKoLTBL2bi9lw+J4yQFcR241JqLfsPQHBoF5nYLngUsTdCuOTIrfCFmeEIamtlzI xgq12K7Kw5hCMqGxamwkQB9Tq0pMSC5S4Q/OqjaTBRi1IiPj70in7KUOdF+LY4i9 m+ZzhsTgUeQ/69bjnWe61pvRJwq66hthu9CppoJ5j+Y57A6ib0DF5dgon1Gam0u2 QP5e07dFwP9/LYSYCscWQdQUdvInVLa4DuwP/9Q4yPH2y2CLZfbbJMhz56Wd0gtP 8bl5RGphLhxpWh8bvtZnip8gWwr/knqsNuf1CrFNmAcxzfveI59T0AW3fUh6xhVd qiGcDgQVY3AKmIi20Guz1Gh6Ge+K95WF8Qb8jpNZP80ibchyQbJ+wqd1oKaEFwxQ QALXb9Six5StFjcNLDUjUlrhXWsn0mg/NqKOtJ4ffP6UmsFWFM0IjS3dkwL5KPN7 0CxUykZoo4Q+Khrw+QRrm9UdrKX+K2erv9WaBrVYM50D3AO5fbsiWIu4NKqO4oH7 jzbSuAtlSCtCiU8qyc2k/k2UlJEVz3n6GiuTfJhshqZ36Q7NJa8oke79N6uDq4dH HTvVYQ5Fwz658NmT3G1Z =2AjZ -----END PGP SIGNATURE-----