GNOME Bugzilla – Bug 743323
avahi-discovered CUPS printers don't work
Last modified: 2015-03-02 09:57:14 UTC
Printers attached to a Fedora 21 system and announced by CUPS via DNS-SD, can't be used in gtk/gnome apps on another Fedora 21 system on the same network. Specifically, 1) in the printer list such printers are shown but their status is not 2) when such a printer is selected, the controls related to their PPD properties are updated, but the status and some of the controls, specifically covers before and after, remain unpopulated 3) clicking "Print" appears to have successfully submitted the job; however, nothing gets printed, and the cupsd on the destination host reports "bad request" in its error_log and doesn't actually queue the job. This is a regression compared to Fedora 20 (gtk+-3.10), where everything worked fine. Package version: gtk3-3.14.6-1.fc21.x86_64
With increased log verbosity in cupsd, it turned out that the request is considered bad because "job-sheets" option had no value at all. AFAICS that was the result of issue (2): since the selection lists for covers before and covers after had no items in them, the corresponding GtkPrinterOptionSet object didn't receive "gtk-cover-before" and "gtk-cover-after" options at all, and cups_printer_get_settings_from_options() didn't translate them into "cups-job-sheets" setting which is then used as "job-sheets" option in the CUPS request. That, in turn, was due to the issue (1): the selection lists for covers are populated in cups_printer_get_options() with items from a predefined list up to the number of covers reported by cups in "job-sheets-supported" option. The backend never made a request to obtain this and other relevant options, including status (confirmed both by logging on the server side and by not seeing cups_request_avahi_printer_info_cb when running with GTK_DEBUG=printing on the client side). So the number of covers remained initialized to 0.
AFAICT the regression was introduced in commit 376e2c003d02405cb0a62b90f4e2a0cab88f9650 Author: Marek Kasik <mkasik@redhat.com> Date: Thu Nov 21 15:27:33 2013 +0100 printing: Don't wake up Avahi printers unnecessarily Use info available in Avahi TXT records for creation of gtk printer and request details when needed (through gtk_printer_request_details()). If there is a printer advertised on Avahi by a remote CUPS server try to get its PPD file at first or get its capabilities through an IPP request if it fails. https://bugzilla.gnome.org/show_bug.cgi?id=712751 This was included in 3.11.4. (The conclusion is based on code inspection only; I don't have the capacity to set up the build environment and do proper bisecting, sorry.)
So the current code has two problems (both introduced by that commit): 1) the printer state for avahi-discovered printers never gets fully populated. It's supposed to be done by cups_request_avahi_printer_info(). One of its call sites was replaced in that commit by create_cups_printer_from_avahi_data(), with the idea not to do a CUPS request when populating the printer list. Now cups_request_avahi_printer_info() may only be called from cups_request_ppd_cb() and only if PPD downloading failed, which is not the case for normally configured remote CUPS servers. I guess cups_request_avahi_printer_info() has to be stuck somewhere in cups_printer_request_details(), before cups_request_ppd(). 2) the printer status data from dns-sd TXT record isn't used in the printer list. "printer-state" (3 - idle, 4 - processing, 5 - stopped) is parsed but never used. "printer-type" is parsed and checked against CUPS_PRINTER_REJECTING; however, the resulting value ->is_accepting_jobs is not used in set_info_state_message(), because ->state_msg is NULL and stays this way forever.
Created attachment 297356 [details] [review] Get covers for each printer individually Hi, I couldn't reproduce this because of the problem fixed by the attached patch. It gets covers for each printer individually. The covers was stored directly to print backend before so if there was another printer which successfully got the covers then the covers were populated. Marek
Created attachment 297357 [details] [review] Always get details of Avahi printers via IPP This patch requests details of each Avahi printer over IPP even if it already got its PPD.
Roman, do these patches fix the problem for you ?
Review of attachment 297356 [details] [review]: Looks fine to me ::: modules/printbackends/cups/gtkprintbackendcups.c @@ +2827,1 @@ g_slice_free (PrinterSetupInfo, info); Might be nice to have a printer_setup_info_free() for this repeated freeing code, but not a big deal.
Review of attachment 297357 [details] [review]: ok
Thank you for the reviews. I'll just add the printer_setup_info_free() function and will push it to master.
Comment on attachment 297356 [details] [review] Get covers for each printer individually I've pushed the patches to master. Maybe we should get them also to 3.14. What do you think? (The second patch would be a little different since we've already worked on this code for 3.16).
sounds like a good idea
I've pushed a modified version of the patches to 3.14. I'll look whether I can get some useful information from the "printer-state" tomorrow to improve the status yet.
(In reply to Matthias Clasen from comment #6) > Roman, do these patches fix the problem for you ? Sorry, I don't have the capacity to do heavy build & test activities in my home network; certainly not for the 3.16 stack. AFAICS you've built gtk3-3.14.9 for Fedora21 with the fixes included; I'll try to fetch it and test soon and report back.
Created attachment 298097 [details] [review] Set printer state correctly Hi, the attached patch fixes the setting of printer state message. It considers NULL printer state message as empty now so we can set it. And after discussion with Tim Waugh the backend also handles IPP_PRINTER_STOPPED state as paused now. Another problem was that the CUPS_PRINTER_REJECTING flag was not set in the "printer-type" TXT record for DNSSD printers by CUPS. Tim prepared a patch which fixes the problem. See https://bugzilla.redhat.com/show_bug.cgi?id=1196730 for additional info. The patch is also applicable to 3.14. Regards Marek
Unfortunately the CUPS fix was rejected upstream. Though the patch still makes sense at least for the paused state.
Review of attachment 298097 [details] [review]: ok
Comment on attachment 298097 [details] [review] Set printer state correctly Thank you for the review. I've pushed the patch to master and 3.14 branches. I'm closing this bug as fixed now.