After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 743323 - avahi-discovered CUPS printers don't work
avahi-discovered CUPS printers don't work
Product: gtk+
Classification: Platform
Component: Printing
Other Linux
: Normal major
: ---
Assigned To: gtk-bugs
Depends on:
Reported: 2015-01-21 23:18 UTC by Roman Kagan
Modified: 2015-03-02 09:57 UTC
See Also:
GNOME target: 3.16
GNOME version: ---

Get covers for each printer individually (7.04 KB, patch)
2015-02-20 10:21 UTC, Marek Kašík
committed Details | Review
Always get details of Avahi printers via IPP (4.28 KB, patch)
2015-02-20 10:25 UTC, Marek Kašík
committed Details | Review
Set printer state correctly (1.43 KB, patch)
2015-02-27 15:55 UTC, Marek Kašík
committed Details | Review

Description Roman Kagan 2015-01-21 23:18:11 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.


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
Comment 1 Roman Kagan 2015-01-21 23:39:57 UTC
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.
Comment 2 Roman Kagan 2015-01-21 23:45:02 UTC
AFAICT the regression was introduced in

commit 376e2c003d02405cb0a62b90f4e2a0cab88f9650
Author: Marek Kasik <>
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.

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.)
Comment 3 Roman Kagan 2015-01-22 00:40:07 UTC
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.
Comment 4 Marek Kašík 2015-02-20 10:21:30 UTC
Created attachment 297356 [details] [review]
Get covers for each printer individually


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.

Comment 5 Marek Kašík 2015-02-20 10:25:48 UTC
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.
Comment 6 Matthias Clasen 2015-02-23 18:53:45 UTC
Roman, do these patches fix the problem for you ?
Comment 7 Matthias Clasen 2015-02-25 14:39:02 UTC
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.
Comment 8 Matthias Clasen 2015-02-25 14:40:28 UTC
Review of attachment 297357 [details] [review]:

Comment 9 Marek Kašík 2015-02-25 14:42:59 UTC
Thank you for the reviews. I'll just add the printer_setup_info_free() function and will push it to master.
Comment 10 Marek Kašík 2015-02-25 15:01:42 UTC
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).
Comment 11 Matthias Clasen 2015-02-25 15:37:55 UTC
sounds like a good idea
Comment 12 Marek Kašík 2015-02-25 17:17:09 UTC
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.
Comment 13 Roman Kagan 2015-02-26 11:21:44 UTC
(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.
Comment 14 Marek Kašík 2015-02-27 15:55:35 UTC
Created attachment 298097 [details] [review]
Set printer state correctly


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 for additional info.

The patch is also applicable to 3.14.


Comment 15 Marek Kašík 2015-02-27 17:01:45 UTC
Unfortunately the CUPS fix was rejected upstream. Though the patch still makes sense at least for the paused state.
Comment 16 Matthias Clasen 2015-02-27 18:01:12 UTC
Review of attachment 298097 [details] [review]:

Comment 17 Matthias Clasen 2015-02-27 18:01:14 UTC
Review of attachment 298097 [details] [review]:

Comment 18 Marek Kašík 2015-03-02 09:57:04 UTC
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.