Description of problem: The lpr print backend library does not close the file descriptor to the lpr command promptly. (cf. GTK+ bug ID #390159, "(gtk_print_backend_lpr_print_stream): Close the io channel on unref."); see http://bugzilla.gnome.org/show_bug.cgi?id=390159 for further details. Version-Release number of selected component (if applicable): evolution28-gtk2-2.10.4-22.el4 (reproduced using firefox-3.0.1-3.el4) How reproducible: Always Steps to Reproduce: 1. Configure gtk+ to use the lpr backend (e.g., by putting the line gtk-print-backends = "file,lpr" into the user's ~/.gtkrc-2.0 file or one of the system gtkrc files 2. Launch Firefox 3.0.1 ("/usr/bin/firefox") 3. Print a page using the "Print to LPR" option in the print dialog. Actual results: The page does not print until the browser has been closed; running "ps" displays that an lpr child process of firefox 3 is still running. Expected results: The page should print immediately and the lpr process should not remain. Additional info: Replacing the libprintbackend-lpr.so library with a more recent version eliminates the symptom, so the bug is definitely in this library and the fix appears to have been added at or around release 2.11.0. We are not able to work around this by using the default CUPS backend, as our accounting procedures require print authentication (and password prompting is not implemented in this GTK+ package either).
Reassigning this to Matthias. (you're welcome :)
So the fix is known; The only work-around is to take an upstream update to the lpr back end, and yet this has sat for five months with no visible forward progress? There are 1000 RHEL 4.7 users at MIT who are going to start calling the help desk wondering why they can't print from Firefox any more. This is a serious regression and deserves high priority remedy, I think.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: * the I/O channel for GTK's Line Printer Remote (LPR) backend remained open even after data transfer was complete. Printing will not start until this channel is closed, so pages from Firefox 3 would not begin to print until the browser closed (since this would also close the channel). GTK's LPR backend now closes the I/O channel when data transfer is complete, and printing commences immediately.
That release note looks 100% accurate to me.
Is there a updated (beta or released) RPM for this? Also this exists in RHEL5 too, does that need a separate bug report?
Richard, Thanks to Tim Waugh, I rolled an rpm from a patch he created for this issue and the results have been positive. RHEL4.8 should have the fix for this and will be going into beta for testing very shortly. Also, there is a hotfix being processed for this issue with RHEL4.8. I would open a support ticket regarding the issue to get the supported bits. I would also advise you to open up a new bugzilla regarding this for RHEL5 but mention this bugzilla in the description. If you have a support contract, I would like to urge you to open a support ticket with RHEL5 and we can try to get a hotfix processed for you and others running into the problem. -- Robin
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1021.html