Bug 252304 - Incorrect ipp address for brother hl-1270n
Summary: Incorrect ipp address for brother hl-1270n
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-printer (Show other bugs)
(Show other bugs)
Version: 7
Hardware: All Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
Depends On:
Blocks: F9Target
TreeView+ depends on / blocked
Reported: 2007-08-15 08:36 UTC by Simon Goodall
Modified: 2007-12-20 12:19 UTC (History)
0 users

Fixed In Version: 0.7.78-2.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-18 13:37:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Simon Goodall 2007-08-15 08:36:45 UTC
Description of problem:
When using IPP to connect to a Brother HL-1270N printer, the uri created is
incorrect. The generated URI is;


where as it should be:


Version-Release number of selected component (if applicable):

How reproducible:

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 17:26:51 UTC
Please create a file called test.py with this content:

import cups, os

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 14:00:07 UTC
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:


Although actually please use this snippet, which actually works:

import cups, os, pprint

Comment 3 Simon Goodall 2007-09-29 10:05:59 UTC
In both cases I get the following error message;

Traceback (most recent call last):
  File "test.py", line 5, in <module>
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 18:05:11 UTC
This has been fixed properly upstream (0.7.76).

Comment 5 Simon Goodall 2007-11-26 21:25:43 UTC
Version 0.7.78 in F8 did not help. Trying the "Find Queue" button resulted in
the following on the stdout;

Lock acquired for devices thread
Devices thread started
Connecting (devices)
Fetching devices
Closing connection (devices)
Releasing devices lock
Got devices
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

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 15:27:18 UTC
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 22:01:54 UTC
I've not seen any updates, rawhide is the yum development channel, right?

Comment 8 Tim Waugh 2007-12-11 14:11:49 UTC
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 19:08:03 UTC
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


Comment 10 Tim Waugh 2007-12-12 12:40:09 UTC
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 21:03:21 UTC
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 13:37:15 UTC
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 20:47:09 UTC
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 12:19:48 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.