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

Bug #258104 reported by Nathaniel Smith on 2008-08-15
Affects Status Importance Assigned to Milestone
gtk+2.0 (Ubuntu)
Ubuntu Desktop Bugs
Ubuntu Desktop Bugs

Bug Description

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.

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.

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

Sebastien Bacher (seb128) wrote :

thank you for your bug report and the patch, looks like a good hardy update candidate indeed

Changed in gtk+2.0:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Triaged
Nathaniel Smith (njs) wrote :

Have now verified that the attached patch builds cleanly against gtk+2.0_2.12.9-3ubuntu4 from hardy, and with the resulting library installed, GTK+ apps print correctly. I tested both local and remote printers; remote printers now work when they did not before, while local printers continue to work exactly as they did before.

The redhat bug report linked above lists another confirmation, and the same patch seems to have shipped to fc9. (I say "seems" because fedora is having some infrastructure problems right now.)

The bug is already fixed in intrepid, since it has the latest gtk+ pre-release (2.13.6, released August 6, while the bug was fixed upstream in June).

Let me know if there's anything else I can do to help.

As this has already been fixed in Intrepid, you might want to refer to the SRU wiki page to get this into Hardy:


Nathaniel Smith (njs) wrote :

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: updated
Zakhar (alainb06) wrote :

I wouldn't consider the importance of this bug as "low".
Ubuntu come with Gnome, and therefore has countless programs that rely on the GTK+

This simply means you cannot use remote printers (I confirm the bug!) in Ubuntu... or you switch your printer server to Windows, as there is no bug in samba printing!..

Hardy is a LTR, doesn't it means such bugs ought to be quickly addressed ?

I'm don't have the skills either to patch it myself, but I'm voting for this patch to be in the "proposed"... if some skillful one would kindly apply the above patch and deliver it in "proposed", I'll swiftly download the libgtk2 and report my tests.

Keep up the good job!

Sebastien Bacher (seb128) wrote :

> Hardy is a LTR, doesn't it means such bugs ought to be quickly addressed ?

no, hardy is a LTS and that means the desktop will get 3 years of security support but there is no guaranty about standard bug fix or the speed at which ones issues will be addressed

the work is done on a best effort basis and often by volunteers, I've added this bug to the hardy updates candidates but the activity is somewhat lower during holidays, you are welcome to purchase support contract if you need quick fixing though

Zakhar (alainb06) wrote :

"Best effort" is fine for me: it's not for professional use.

Now I know it's a bug, and not an error I made entering wrong parameters for remote printers, so, as it's a local "home" network, I just copy the files over and go to the room where the server is to print them ;-)

I still volunteer for testing once the package will be in the "proposed" repository, let me know, and I'll test and report the feedback.

Keep up the good job!

Sebastien Bacher (seb128) wrote :

the bug has been fixed in intrepid

Changed in gtk+2.0:
status: Triaged → Fix Released
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: New → Confirmed
Martin Pitt (pitti) wrote :

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in gtk+2.0:
status: Confirmed → Fix Committed
Martin Pitt (pitti) wrote :

Zakhar, anyone else, does the package in -proposed work for you?

Zakhar (alainb06) wrote :

Sorry I'm not in the same location now, and I don't have a printer attached to a Ubuntu PC. I'll try to switch it to my Ubuntu laptop and test it from a Virtualized Ubuntu (best I can do here).
I'll have a chance to test it in the situation I saw the bug on the first Week-end of november.
Sorry again !

Zakhar (alainb06) wrote :

And sorry... now it's working out of the box, from my virtualised Ubuntu to my laptop Ubuntu using Cups and a GTK app like Gedit (or tell me Gedit is not GTK2?)
May be I already had an update (or Microsoft is doing a great job reparing CUPS with MS Virtual PC 2007, which is unlikely!).

Anyway from the virtualized, the only thing updatable under GTK2 was gtk2-engines-pixbuf (version 2.19.9-3ubuntu4) to 2.19.9-3ubuntu5
This implied the upgrade of
libgtk2.0-0 (version 2.12.9-3ubuntu4) to version 2.12.9-3ubuntu5

So it works now with both versions... and then I can confirm there is no regression and it works also with the new version (ubuntu5).

Martin Pitt (pitti) wrote :

Copied to hardy-updates.

Changed in gtk+2.0:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers