search

michaelrsweet / pappl

PAPPL - Printer Application Framework
https://www.msweet.org/pappl
Apache License 2.0
309 stars 49 forks source link

Print queue setup fails. URI rejected. #253

Closed debiantriage closed 1 year ago

debiantriage commented 1 year ago

Describe the bug

I submitted this issue at https://github.com/OpenPrinting/pappl-retrofit/issues/8 first. Basically, installation of a print queue within gutenprint-printer-app fails.

Steps to reproduce the behavior:

  1. Find URI: root@test-new:~# gutenprint-printer-app devices usb://EPSON/Stylus%20Photo%20RX420?serial=LJ4O40407152301540
  2. Establish queue: gutenprint-printer-app add -d RX420 -m epson--stylus-photo-rx-420--en -v usb://EPSON...

Outcome gutenprint-printer-app: Unable to add printer: Unsupported smi55357-device-uri uri value.

Resolution Use cups:usb://EPSON... for the URI.``

Expected behavior Establish a queue as documented.

System Information:

michaelrsweet commented 1 year ago

Hmm, so a couple things to try:

  1. Make sure to put quotes around the device URI ('%' and '?' can be interpreted by the shell)
  2. Check the gutenprint-printer-app log file/syslog for details of what URI was seen
debiantriage commented 1 year ago

Hmm, so a couple things to try:

1. Make sure to put quotes around the device URI ('%' and '?' can be interpreted by the shell)

Tried that, without success

2. Check the gutenprint-printer-app log file/syslog for details of what URI was seen

The relevant lines from the log in /var/snap appear to be

D [2023-02-09T14:00:38.141Z] [Client 8] Create-Printer request:   smi55357-device-uri uri usb://EPSON/Stylus%20Photo%20RX420?serial=LJ4O40407152301540
I [2023-02-09T14:00:38.141Z] [Client 8] Create-Printer client-error-attributes-or-values-not-supported (Unsupported smi55357-device-uri uri value.)
D [2023-02-09T14:00:38.141Z] [Client 8] Create-Printer response:   status-message textWithoutLanguage Unsupported smi55357-device-uri uri value.

Anyway, I get the same outcome with ps-printer-app and a networked printer. Log attached.

psq.log.txt

michaelrsweet commented 1 year ago

OK, so I just can't get it to fail with the test suite. What version of PAPPL are you using?

debiantriage commented 1 year ago

OK, so I just can't get it to fail with the test suite. What version of PAPPL are you using?

Thanks for the effort. I still get what I described on Ubuntu/

I am using gutenprint-printer-app and hplip-printer-app from the snapstore. I thought snaps are self-contained. libpappl1 is not on this system.

debiantriage commented 1 year ago

As I said elsewhere though: I can add the printer if I preface the URI with cups:.

tillkamppeter commented 1 year ago

As I said elsewhere though: I can add the printer if I preface the URI with cups:.

@debiantriage if the URI without cups: prefix (usb://EPSON/...) does not work for you but cups:usb://EPSON/... works for you, this is because the PAPPL backends (URI usb:...) are not used by the mentioned Printer Applications (gutenprint-printer-app and hplip-printer-app from Snap Store).

Does

gutenprint-printer-app devices

list the usb://EPSON/... URI? Does it list BOTH the usb://EPSON/... and cups:usb://EPSON/... URIs? It should list ONLY the cups:usb://EPSON/... URI.

debiantriage commented 1 year ago

@tillkamppeter It lists the URIs without a cups:prefix:

root@ubuntu:~# root@ubuntu:~# gutenprint-printer-app devices snmp://NPI2CA3D7 usb://EPSON/Stylus%20Photo%20RX420?serial=LJ4O40407152301540 root@ubuntu:~#

tillkamppeter commented 1 year ago

The problem was in PAPPL, the "devices" subcommand was broken. Calling a PAPPL-based Printer Application with "devices" simply lets the command line client poll all the default schemes of PAPPL, regardless whether the Printer Application has their own custom schemes, and always only as the calling user, not as root if the Printer Application's server has to run as root to discover (and have access to) the printers. This gives wrong results in many cases, especially with the retro-fitting Printer Applications based on pappl-retrofit.

@debiantriage the URIs without cups: in the beginning are from PAPPL's own backends (schemes) and those are not used by the retro-fitting Printer Applications. They use a custom scheme named cups: which is implemented in libpappl-retrofit. This scheme uses CUPS backends, to get best compatibility with the classic CUPS drivers, especially also supports drivers which bring their own CUPS backends (like HPLIP for example, and Gutenprint with Dye-Sub printers). Therefore the URIs without cups: do not work with retro-fitting Printer Applications, only those with cups: do.

When applying PR #262 the "devices" subcommand issues an IPP_OP_PAPPL_FIND_DEVICES to the server and the server does the discovery run, with whatever backends/schemes it is using, and as the user as which the server is running (in most cases root), and answers back its results to the command line client. And in case of a retro-fitting Printer Applications the URIs correctly start with cups: as this is what the server is actually using.

I also fixed the IPP_OP_PAPPL_FIND_DEVICES and IPP_OP_PAPPL_CREATE_PRINTERS as they only handled the first entry of the list of discovered devices, giving incomplete results if more than one (supported/not yet set up) printer is present.