Okay, added the required items to the description above. That page
appears aimed at Ubuntu developers, though, which I'm not, so I haven't
e.g. uploaded a fixed package to hardy-proposed :-). (I don't have time
to become one right now either, FWIW.)
** Description changed:
- 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 ---
+ --- 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
--
[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
