Bug 248245 - cups client printing from gnome applications fail
Summary: cups client printing from gnome applications fail
Alias: None
Product: Fedora
Classification: Fedora
Component: gtk2
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Marek Kašík
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 449379
TreeView+ depends on / blocked
Reported: 2007-07-14 04:30 UTC by Jussi Eloranta
Modified: 2008-07-07 11:45 UTC (History)
3 users (show)

Fixed In Version: gtk2-2.12.8-4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-07-07 11:45:33 UTC
Type: ---

Attachments (Terms of Use)
Patch fixing hostname of broadcasted printer. (500 bytes, patch)
2008-05-23 14:18 UTC, Marek Kašík
no flags Details | Diff
untested-fix.patch (677 bytes, patch)
2008-06-02 15:25 UTC, Tim Waugh
no flags Details | Diff

Description Jussi Eloranta 2007-07-14 04:30:45 UTC
Description of problem: 

I have a cups server which has a USB printer attached to it and a bunch of
clients print through this server. After I boot a client, it shows the remote
printer in the following format name@server in the client. Printing from most
applications work OK but many gnome based applications fail to print (for
example, evince). The client side shows no error messages on the screen but when
I inspect the client cups logs, I can seen that it complains that the printer
could not be found. The name of the printer is shown correctly in the error
message. If I remove the printer using the print manager graphical application
(System->Administration->Printing menu), the remote printer shows up again
automatically but now without the @ notation. If I print from evince now, it
works correctly. So apparently some gnome based applications don't like the
name@server notation?? -> This could be a gnome problem too...

Version-Release number of selected component (if applicable): f7 with up to date

How reproducible: Set up a cups print server and try to print from a client
using evince. If the remote printer shows up in the @ notation, remote printing
will fail.

Steps to Reproduce: see above.
Actual results: see above.

Expected results: see above.

Additional info:

Comment 1 Tim Waugh 2007-07-16 08:44:01 UTC
It sounds like you are setting up a remote queue with a certain name, then also
a local queue with the same name.  Is that what you're doing?

Please show me:

1. 'lpstat -s' output from the client
2. the exact error message you found in the client CUPS log file
3. the output of 'rpm -q gtk2 cups'

Comment 2 Jussi Eloranta 2007-10-16 17:41:56 UTC
I am seeing this too - however, sometimes. After boot it seems to work
but then something happens and it stops working.

In the following, I tried printing from evince (a PDF file that printed from
evince correctly before the problem showed up). At this point printing from
non-gnome apps still work correctly. I tried to print to Lexmark_E234@chemserv
Lexmark_E234 is a USB printer hooked up to the server.

lpstat -s on client gives:

system default destination: Lexmark_E234@chemserv
device for hp2327: ipp://chemserv.csun.edu:631/printers/hp2327
device for Lexmark_E234@chemserv: ipp://chemserv.csun.edu:631/printers/Lexmark_E234

On the client, this is what shows up in the access_log file:
localhost - - [16/Oct/2007:10:31:55 -0700] "POST /printers/Lexmark_E234@chemserv
HTTP/1.1" 200 623324 Print-Job client-error-not-found

The client error_log shows:
D [16/Oct/2007:10:31:55 -0700] Print-Job
D [16/Oct/2007:10:31:55 -0700] print_job: auto-typing file...
D [16/Oct/2007:10:31:55 -0700] print_job: request file type is
D [16/Oct/2007:10:31:55 -0700] Print-Job client-error-not-found: The printer or
class was not found.
D [16/Oct/2007:10:31:55 -0700] cupsdProcessIPPRequest: 9 status_code=406
D [16/Oct/2007:10:31:55 -0700] cupsdCloseClient: 9

Output from rpm -q gtk2 cups on both server and the client:


Comment 3 Jussi Eloranta 2007-10-16 21:56:03 UTC
I have another machine (identical installation) where the printing works.
On this machine I see the following

lpstat -s 
system default destination: Lexmark_E234
device for hp2327: ipp://chemserv.csun.edu:631/printers/hp2327
device for Lexmark_E234: ///dev/null

In access_log I see:
localhost - - [16/Oct/2007:14:51:37 -0700] "POST /printers/Lexmark_E234
HTTP/1.1" 200 1053652 Print-Job successful-ok

This is printing to the same server. Also rpm -q gtk2 cups gives:

So the only obvious difference is the device which here is pointing to /dev/null
and in the other one is ipp://...

So is gnome having some sort of problem with this ipp://... format device.
And also, why do these two computers have two different devices anyway???

Comment 4 Jussi Eloranta 2007-10-16 22:12:04 UTC
On the above machine printing to ipp:// address works too (hp2327) - so this is
not apparently the issue. On the server hp2327 is a network printer using HP's
IP printing protocol.

Comment 5 Tim Waugh 2007-10-17 12:29:06 UTC
Please attach /etc/cups/printers.conf from the client and from the server.  It
sounds like you are setting up a remote queue with a certain name, then also
a local queue with the same name, and I'd like to understand if that is the case.

Comment 6 Jussi Eloranta 2007-10-17 15:02:12 UTC
On the client /etc/cups/printers.conf is essentially empty:

# Printer configuration file for CUPS v1.2.11
# Written by cupsd on 2007-07-06 08:17

On the server the two shared printers are defined as:

# Printer configuration file for CUPS v1.2.11
# Written by cupsd on 2007-07-05 08:28
<Printer hp2327>
Info HP laser printer with 64MB memory
Location Room 2327 (science 2)
DeviceURI socket://
State Idle
StateTime 1177632607
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
<DefaultPrinter Lexmark_E234>
Info Lexmark / eloranta
Location Eloranta group
DeviceURI usb://Lexmark/E234
State Idle
StateTime 1183648614
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer

And also note that somehow *only* GNOME applications are affected by this
problem. lpr/lp and other apps (like firefox, acrobat reader etc.) are able to

Comment 7 Jussi Eloranta 2007-10-17 15:06:24 UTC
One more odd thing. I just noticed that from the client that fails to print to
the lexmark (via usb on the server), it *can* print to the HP printer (via HPs
IP printing on the server; see above). Maybe just a coincidence but still could
be relevant information.

Comment 8 Jussi Eloranta 2007-10-17 15:08:20 UTC
Argh.. sorry this is coming in pieces now... But the hp printer queue does not
show up using the @ notation whereas the Lexmark does. This is in agreement with
the original poster. Whenever the @ notation appeared, the printer stops working.

Comment 9 Tim Waugh 2007-10-19 16:23:40 UTC
(In reply to comment #2)
> On the client, this is what shows up in the access_log file:
> localhost - - [16/Oct/2007:10:31:55 -0700] "POST /printers/Lexmark_E234@chemserv
> HTTP/1.1" 200 623324 Print-Job client-error-not-found

This is the significant bit.  The GTK+ print dialog is fetching the PPD from the
correct machine (i.e. the server, chemserv.csun.edu), but trying to print the
job to the wrong machine (i.e. the client).

This needs to be fixed in GTK+.

Comment 10 Tim Waugh 2007-10-19 16:32:45 UTC
Steps to reproduce:

1. Add 'BrowseShortNames Off' to the end of /etc/cups/cupsd.conf
2. Stop CUPS
3. rm -f /var/cache/cups/remote.cache
4. Start CUPS
5. Wait for remote printers to be discovered
6. Using evince, print something to a remote printer (they should all contain
'@' in the name)

Comment 11 Bug Zapper 2008-05-14 13:32:38 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 12 Tim Waugh 2008-05-14 14:45:17 UTC
Still fails in Fedora 8.

Comment 13 Marek Kašík 2008-05-23 14:18:17 UTC
Created attachment 306501 [details]
Patch fixing hostname of broadcasted printer.

Comment 14 Marek Kašík 2008-05-23 14:21:23 UTC
The fix is included in gtk2 2.12.8-4, which will ship in next update of the package.

  Thank you for reporting this bug


Comment 15 Tim Waugh 2008-06-02 15:06:44 UTC
This patch looks wrong to me.  The problem isn't that we're talking to the wrong
server; the problem is that we're using the wrong queue name.

Comment 16 Tim Waugh 2008-06-02 15:18:03 UTC
Here's a more detailed analysis:

When CUPS has the 'BrowseShortNames' option set to 'Off', discovered network
CUPS queues will appear like this: 'Duplexer@printserv'.  The GTK+ print dialog
makes two distinct CUPS requests:

1. It needs to fetch the PPD for this queue in order to show the printer options
available for printing

2. It submits the print job when the user clicks OK.

For the 'fetch PPD' step it had been parsing the queue name to see the '@', then
connecting directly to 'printserv' and asking for the PPD for the queue named
'Duplexer@printserv'.  This fails, because printserv knows that queue as 'Duplexer'.

The the 'submit print job' step, it connects to the default CUPS server
(normally the locally CUPS server).

Your change in comment #13 altered the wrong step -- it caused the job to be
submitted directly to printserv, causing bug #449379.

The correct fix is to perform all communication with the default CUPS server,
including fetching the PPD.  Don't try parsing the queue name.  To fetch the
PPD, connect to the default CUPS server and ask for the PPD for

Comment 17 Tim Waugh 2008-06-02 15:25:10 UTC
Created attachment 307378 [details]

Here's an untested patch to be used instead of printer-hostname.patch.

Comment 18 Marek Kašík 2008-06-12 14:07:58 UTC
I committed reworked patch into Fedora 8 CVS, rawhide CVS and also into Fedora 9
CVS. Their releases are 2.12.8-5 (Fedora 8), 2.12.10-3 (Fedora 9) and 2.13.2-2
(rawhide). It is also in upstream.


Comment 19 Tim Waugh 2008-06-13 11:24:27 UTC
Looks fine here.

Comment 20 Fedora Update System 2008-06-17 03:27:11 UTC
gtk2-2.12.10-5.fc9 has been submitted as an update for Fedora 9

Comment 21 Fedora Update System 2008-06-18 03:14:49 UTC
gtk2-2.12.10-5.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update gtk2'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-5419

Comment 22 Tim Waugh 2008-06-19 07:50:11 UTC
Fix confirmed here.

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