Description of problem: When using IPP to connect to a Brother HL-1270N printer, the uri created is incorrect. The generated URI is; ipp://hostname/printers/queue_name where as it should be: ipp://hostname/queue_name Version-Release number of selected component (if applicable): system-config-printer-0.7.63.2-2.fc7 How reproducible: Always Steps to Reproduce: 1. Add a new printer 2. Choose Brother, HL-1270N as printer make and model 3. Choose IPP as protocol and fill in hostname and queue name 4. Finish up adding the printer 5. Attempt to print a test page Actual results: Nothing is printed as the URI is incorrect. Expected results: Test page printed without further modification to the URI's Additional info:
Please create a file called test.py with this content: #!/usr/bin/python import cups, os cups.setServer(os.environ["PRINTER"]) c=cups.Connection() c.getPrinters() Then run this command, with hl1270n replaced by the hostname of the printer: PRINTER=hl1270n python test.py and attach the output here. I'd like to verify that the printer (a) can be used with libcups (no reason it shouldn't be), and (b) advertises the correct URIs for the available queues. I'm hoping to change the user interface for system-config-printer so that it queries IPP printers for available queues.
This is the what I want to get working, and running the Python snippet from the previous comment will help me check that it will work: http://cyberelk.net/tim/2007/09/27/ipp-browser/ Although actually please use this snippet, which actually works: #!/usr/bin/python import cups, os, pprint cups.setServer(os.environ["PRINTER"]) c=cups.Connection() pprint.pprint(c.getPrinters())
In both cases I get the following error message; Traceback (most recent call last): File "test.py", line 5, in <module> c.getPrinters() cups.IPPError: (1281, 'server-error-operation-not-supported') Attempting to call other methods on the c object results in similar messages, although in some cases (when passing some args) I get; cups.IPPError: (1030, 'client-error-not-found')
This has been fixed properly upstream (0.7.76).
Version 0.7.78 in F8 did not help. Trying the "Find Queue" button resulted in the following on the stdout; fetchDevices Lock acquired for devices thread Devices thread started Connecting (devices) Fetching devices Closing connection (devices) Releasing devices lock Got devices queryPPDs Lock acquired for PPDs thread PPDs thread started Connecting (PPDs) Fetching PPDs Unhandled exception in thread started by <bound method NewPrinterGUI.browse_ipp_queues_thread of <__main__.NewPrinterGUI instance at 0x9193a2c>> Note the exception; the scanning, please wait message just stayed where it was and only disappeared due to pressing cancel. Typing in the correct details manually and pressing verify resulted in a msg box, with the following; "Inaccessible: This print share is not accessible." The details entered do however allow me to print. I also re-tried the above python script, but I got the same result.
I've checked in some changes to pycups and system-config-printer in SVN that I hope will finally fix this. pycups was constructing a bad IPP URI when trying to fetch the printer attributes (to verify the queue is available). Please try system-config-printer{,-libs}-0.7.78-2.fc9 from rawhide (if you're trying RPMs).
I've not seen any updates, rawhide is the yum development channel, right?
It is. # yum --enablerepo=development check-update 'system-config-printer*' development 100% |=========================| 2.1 kB 00:00 primary.sqlite.bz2 100% |=========================| 6.8 MB 00:33 system-config-printer.x86_64 0.7.78-2.fc9 development system-config-printer-libs.x86_64 0.7.78-2.fc9 development
Ah got it. I somehow managed to update them without noticing. So now when pressing the "Find" button, I get the following pop-up. "" Not Possible It·is·not·possible·to·obtain·a·list·of·queues·from·this·host. ""
Okay, that's expected really -- IPP doesn't seem to provide a way to query the available queues. The important thing is: can you now fill in the type-in fields to get the correct URI? (It should show you the URI it will use below the type-in fields.) And does the 'Verify' button work? Note: I have just discovered that if the queue verification (i.e. fetching the queue attributes) fails then there is a Python traceback, and I have fixed that for the next release. However, I am hopeful that fetching queue attributes works for all IPP implementations.
I can manually enter the queue name to get the correct uri (as I could when I first reported this bug). The verify option also comes back with a positive result.
There really isn't much else we can do -- IPP servers do not have to provide a way for clients to discover the available queues (although some will, notably CUPS-based implementations), only to verify that a given queue URI exists.
When I reported the bug, the uri didn't appear to be constructed until *after* you selected the make and model of printer. You entered the hostname and printer name, then you selected the printer make and model and finally it displayed the uri. In this situation could you not determine the uri pattern from the make and model?
We could, if we knew how various models name their IPP URIs. However, this information is not collected anywhere. I have opend a separate bug report against the foomatic component (the database that collects information about printers and drivers) and suggested that feature there: bug #426351.