Bug 883401
| Summary: | Notification about "cups-remote-processing" while printing | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tim Waugh <twaugh> |
| Component: | gnome-settings-daemon | Assignee: | Marek Kašík <mkasik> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 17 | CC: | bnocera, jbahillo, jsalamero, kem, mkasik, rstrode |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-06-21 11:40:45 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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). |
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-")