Bug 435084 - CUPS backend: classes support
CUPS backend: classes support
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: bluez-utils (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: David Woodhouse
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-27 04:49 EST by Tim Waugh
Modified: 2008-03-14 13:09 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-14 13:09:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tim Waugh 2008-02-27 04:49:28 EST
Description of problem:
The bluetooth CUPS backend should check whether the 'CLASS' environment variable
is set the first time it fails to establish contact with the device.  If the
environment variable is set, it should do this:

  fputs ("INFO: Unable to contact printer, queuing on "
         "next printer in class...\n", stderr);
  sleep (5);
  exit (CUPS_BACKEND_FAILED);

Version-Release number of selected component (if applicable):
3.20-6.fc8
Comment 1 Bastien Nocera 2008-03-13 20:03:01 EDT
So, we should only loop when the CLASS envvar is present, and exit as above
otherwise?
Comment 2 Tim Waugh 2008-03-14 06:56:38 EDT
The other way around: if the CLASS environment variable is present and it fails
to contact the printer, it needs to exit.  That way, the scheduler will re-queue
it on the next available printer in that class.

If CLASS is not set, it should loop as normal.
Comment 3 Bastien Nocera 2008-03-14 13:09:32 EDT
Fixed upstream.

Note You need to log in before you can comment on or make changes to this bug.