Bug 252304

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.