Public bug reported: Binary package hint: libgtk2.0-0
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. --- more details --- 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 ** Affects: gtk+2.0 (Ubuntu) Importance: Undecided Status: New -- [PATCH] gtk apps cannot use remote ipp:// printers https://bugs.launchpad.net/bugs/258104 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
