Bug 248245

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'

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
ipp://chemserv.csun.edu:631/printers/Lexmark_E234
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
application/postscript.
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
(client-error-not-found)
D [16/Oct/2007:10:31:55 -0700] cupsdCloseClient: 9

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

gtk2-2.10.14-3.fc7
cups-1.2.12-4.fc7

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:
gtk2-2.10.14-3.fc7
cups-1.2.12-4.fc7

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???

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.

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.

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://130.166.119.94:9100
State Idle
StateTime 1177632607
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</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
</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
print.

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.

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.

(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+.

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)

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:
http://docs.fedoraproject.org/release-notes/

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

Still fails in Fedora 8.
gtk2-2.12.5-1.fc8

Created attachment 306501 [details]
Patch fixing hostname of broadcasted printer.

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

    Marek

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.

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
'Duplexer@printserv'.

Created attachment 307378 [details]
untested-fix.patch

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

Hi,
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.

  Marek

Looks fine here.

gtk2-2.12.10-5.fc9 has been submitted as an update for Fedora 9

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

Fix confirmed here.