[PATCH] gtk apps cannot use remote ipp:// printers

Summary: I can't print, due to a well-understood bug already fixed in upstream gtk+; please backport the bugfix to hardy. A minimal backport patch is attached.

--- SRU checklist ---

User impact: If, for instance, a user runs Ubuntu on their printer server and also on their desktop, then they will not be able to print from the desktop to their print server. (Other situations will also cause this, e.g. it probably even happens if the print server is a Mac.)

Status in intrepid: Intrepid includes a pre-release version of GTK+ that already has the bug fixed upstream (full details of the upstream fix including SVN revisions below).

Minimal patch: Attached to this bug.

TEST CASE:
On computer A:
  1) Run system-config-printer
  2) select "Server Settings -> Share published printers"
  3) Select one of the printers listed under "Local Printers" (for instance, the PDF print-to-file printer) and check the box "Policies -> State -> Shared".
Then on computer B:
  4) run system-config-printer
  5) add the remote printer: select "New Printer -> Internet Printing Protocol (ipp)", type the name of computer A into the "Host:" field, click "Find Queue", select the printer you exported before, and click Forward, Apply.
  6) use any application that uses the gtk+ print system -- e.g. evince or firefox -- and attempt to print something.
without the patch: nothing will happen; an error will appear in computer B's /var/log/cups/error_log, but the job will not actually appear in any print queue, etc.
with the patch: the file will print correctly
to verify lack of regression: also attempt to print to a local printer, e.g. the PDF printer on computer B.

Risks: The worst-case regression for this bug would be that it would somehow break local printers, making it impossible for users to print at all. However, the fix looks correct -- it simply constructs the correct ipp:// URL by hand, instead of using the one stored in the printer struct; for local printers this should lead to identical results. Also, Fedora appears to have included this fix without ill effect. Also, I tried it on my computer and everything worked fine.

--- original bug report ---

Here's the setup: I have a printer attached via usb to the server 'algernon', which is sharing the printer via CUPS. So the printer is accessible as ipp://algernon/printer/<blahblah>. I want to print to this printer from my laptop, 'ged'. So I went to System -> Administration -> Printing on ged, hit "New Printer" -> "Internet Printing Protocol", entered "algernon" as the host, etc. So at the end of it, cups on ged knows about the printer on algernon, and printing to it works fine.

BUT, ged is running up-to-date hardy, which has a buggy gtk, so gtk apps still cannot print.

The problem is a bug in gtk's cups print backend, where if you have a local queue which feeds a remote cups-hosted (ipp) printer, then the gtk print dialog will let you attempt to print to that local queue, but then it will screw up in actually submitting the print job, and as far as the user can tell it just vanishes without a trace. (You hit "Print", the dialog box disappears, nothing else happens.)

The exact problem is that the gtk cups backend submits connects to the local cups daemon on ged and attempts to submit the job, but when it comes time to tell the local cups daemon which printer it is submitting to, it gives it the remote url (ipp://algernon.localnet/blahblah) rather than the local url (ipp://localhost/blahblah). The local host, of course, has no clue what to do when asked for a printer on a different server entirely. The symptom of this is that ged's /var/log/cups/error_log says:
  D [15/Aug/2008:03:10:32 -0400] Print-Job ipp://algernon.localnet:631/printers/HP_LaserJet_2200_USB_1
  D [15/Aug/2008:03:10:32 -0400] Print-Job client-error-not-found: The printer or class was not found.

Apparently a workaround is to print to the remote printer directly, and take the local cups daemon out of the loop; however, you can only do this if you have mdns autodiscovery for the remote printer (otherwise it doesn't show up as an option in the print dialog at all), and my print server is running etch, which doesn't have a new enough cups for that. Also, relying on autodiscovery for the printer I use all day is sort of silly.

This bug was first noticed on Redhat[1], and the fix is in upstream (pre-release) GTK+[2].

The upstream fix took two tries; the first attempt was r20185[3], then r20360[4] reverted r20185 and added the correct fix. As a result, the patch from r20360 does not apply trivially to the version of GTK+ in Ubuntu. I'm attaching a reduced patch that includes the bugfix without the reversion.

Thanks,
-- Nathaniel

[1] https://bugzilla.redhat.com/show_bug.cgi?id=248245
[2] http://svn.gnome.org/viewvc/gtk%2B?view=revision&revision=20360
[3] http://svn.gnome.org/viewvc/gtk%2B/trunk/modules/printbackends/cups/gtkprintbackendcups.c?r1=20185&r2=20184&pathrev=20185
[4] http://svn.gnome.org/viewvc/gtk%2B/trunk/modules/printbackends/cups/gtkprintbackendcups.c?r1=20360&r2=20359&pathrev=20360