Description of problem: When printing from F-17 to another Fedora system running CUPS (F-18, in this case), I see a notification about "cups-remote-processing". Version-Release number of selected component (if applicable): gnome-settings-daemon-3.4.2-3.fc17.x86_64 How reproducible: 100% Steps to Reproduce: 1.Set several jobs printing on an F-18 system (should work on any Fedora system) running as a CUPS server 2.Now print to that CUPS server from an F-17 system (again, probably the same on any Fedora system) Actual results: Notification about "cups-remote-processing" Expected results: No notification about this event, which is not out of the ordinary or anything to take action on. Additional info: All cups-remote-processing means is that the remote CUPS server is still processing jobs. It is no cause for alarm, and the user does not need to be notified about it. I suggest blacklisting these state reasons in the user notification code: "cups-remote-pending", "cups-remote-pending-held", "cups-remote-processing", "cups-remote-stopped", "cups-remote-canceled", "cups-remote-aborted", "cups-remote-completed" (or just anything starting "cups-remote-")
Hi, I've attached patch for this issue to upstream version of this bug (https://bugzilla.gnome.org/show_bug.cgi?id=683577). I've blacklisted there all printer state reasons with prefix "cups-remote-" and also reasons "other" and "com.apple.print.recoverable" (the last 2 are blacklisted in system-config-printer too). Isn't it a bug that cups sends the "cups-remote-*" reasons without proper suffix? I think that the "cups-remote-*" reasons should have "-report" suffix (according to rfc2911). Regards Marek
The patch is part of gnome-settings-daemon 3.4. It will be part of g-s-d 3.4.3 but I'm not sure when it will be released. Regards Marek
Seems to work fine now in gnome-settings-daemon-3.6.4-3.fc18.x86_64.
The problem with this approach is when the printer is really offline, as CUPS errors are ignored, there is no notification to the user. I wouldn't consider this a proper fix.
When the printer is offline, the "connecting-to-device" state reason will be set for a prolonged period (e.g. 60 seconds). If the job fails, the local ipp backend will report the remote printer state before exiting. Have you seen a particular instance where there was no notification about a failed job? If so, it would be useful to know the local and remote values for printer-state-reasons and job-state-reasons.
Hi there: I have reproduces jsalamero comments, and this is true, warnings about printer not being reachable are not being shown. Just in case it helps, I'm showing CUPS messages in debug logging: D [14/Nov/2013:17:19:03 +0100] Returning IPP successful-ok for Get-Jobs (ipp://localhost/printers/Xerox-Phaser-6180MFP-D) from localhost D [14/Nov/2013:17:19:03 +0100] cupsdSetBusyState: newbusy="Active clients and dirty files", busy="Active clients and dirty files" D [14/Nov/2013:17:19:03 +0100] cupsdReadClient: 17 POST / HTTP/1.1 D [14/Nov/2013:17:19:03 +0100] cupsdSetBusyState: newbusy="Active clients and dirty files", busy="Active clients and dirty files" D [14/Nov/2013:17:19:03 +0100] cupsdAuthorize: No authentication data provided. D [14/Nov/2013:17:19:03 +0100] cupsdSetBusyState: newbusy="Active clients and dirty files", busy="Active clients and dirty files" D [14/Nov/2013:17:19:03 +0100] cupsdReadClient: 17 1.1 CUPS-Get-Default 1 D [14/Nov/2013:17:19:03 +0100] CUPS-Get-Default D [14/Nov/2013:17:19:03 +0100] Returning IPP successful-ok for CUPS-Get-Default (no URI) from localhost D [14/Nov/2013:17:19:03 +0100] cupsdSetBusyState: newbusy="Dirty files", busy="Active clients and dirty files" D [14/Nov/2013:17:19:11 +0100] [Job 21] Connection error: No route to host W [14/Nov/2013:17:19:11 +0100] [Job 21] Priter is not being reachable now. (this message has been translated as it was shown in Spanish)
In this case, the "connecting-to-device" printer state reason will be present for an extended period, as described above. This causes a desktop notification (just re-verified with gnome-settings-daemon-3.10.1-2.fc20).