Bug 252304

Summary: Incorrect ipp address for brother hl-1270n
Product: [Fedora] Fedora Reporter: Simon Goodall <simon>
Component: system-config-printerAssignee: Tim Waugh <twaugh>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 7Keywords: Reopened
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 0.7.78-2.fc9 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-12-18 08:37:15 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 235705    

Description Simon Goodall 2007-08-15 04:36:45 EDT
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:
Comment 1 Tim Waugh 2007-09-25 13:26:51 EDT
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.
Comment 2 Tim Waugh 2007-09-27 10:00:07 EDT
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())
Comment 3 Simon Goodall 2007-09-29 06:05:59 EDT
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')


Comment 4 Tim Waugh 2007-10-30 14:05:11 EDT
This has been fixed properly upstream (0.7.76).
Comment 5 Simon Goodall 2007-11-26 16:25:43 EST
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.
Comment 6 Tim Waugh 2007-11-27 10:27:18 EST
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).
Comment 7 Simon Goodall 2007-12-06 17:01:54 EST
I've not seen any updates, rawhide is the yum development channel, right?
Comment 8 Tim Waugh 2007-12-11 09:11:49 EST
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
Comment 9 Simon Goodall 2007-12-11 14:08:03 EST
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.
""
Comment 10 Tim Waugh 2007-12-12 07:40:09 EST
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.
Comment 11 Simon Goodall 2007-12-17 16:03:21 EST
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.
Comment 12 Tim Waugh 2007-12-18 08:37:15 EST
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.
Comment 13 Simon Goodall 2007-12-18 15:47:09 EST
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?
Comment 14 Tim Waugh 2007-12-20 07:19:48 EST
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.