Ubuntu
bluez package

bluetooth CUPS backend should output device listings immediately when it discovers the devices (in discovery mode)

Bug #418465 reported by Till Kamppeter on 2009-08-25

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	bluez (Ubuntu)	Fix Released	Medium	Mario Limonciello

Bug Description

Binary package hint: bluez-cups

I have packaged CUPS 1.4.0 now and soon (before feature freeze, today or tomorrow) it will appear in Karmic. This CUPS version has changed the device discovery procedure to make the discovery faster. Instead of calling all CUPS backends without arguments one after the other, always waiting for one backend to finish before starting the next one, now all backends are started at the same time and run in parallel. Then CUPS waits 10 seconds collecting all output of the backends. After the 10 seconds it kills all backends which are still running.

The bluetooth backend seems to send out some broadcast and then wait 10 seconds for Bluetooth printers to answer. As it needs something like half a second to prepare it misses always the timeout of CUPS and so under CUPS 1.4.0 Bluetooth printers do never get discovered.

I tried to reduce the timeout of the bluetooth CUPS backend to 8 seconds, but I did not find any timeout value in the source code of bluez. Can someone change this timeout? Thanks in advance.

Related branches

lp:ubuntu/lucid/bluez

Revision history for this message

Till Kamppeter (till-kamppeter) wrote on 2009-08-25:

Hint: If you do not want to wait for CUPS 1.4.0 to arrive for testing this, run

time /usr/lib/cups/backend/bluetooth

on the command line.

Changed in bluez (Ubuntu):
importance:	Undecided → Medium

Till Kamppeter (till-kamppeter) on 2009-08-26

summary:	- bluetooth CUPS backend should not take more than 10 seconds in discovery - mode + bluetooth CUPS backend should output device listings immediately when it + discovers the devices (in discovery mode)
Changed in bluez (Ubuntu):
status:	New → In Progress

Revision history for this message

Till Kamppeter (till-kamppeter) wrote on 2009-08-26:

debdiff to make bluetooth CUPS backend working with CUPS 1.4.x Edit (3.6 KiB, text/plain)

Attached is a debdiff for a fix on bluez which solves this problem. The patch makes the backend when it is run in discovery mode (no command line arguments) outputting printer entries as soon as it discovers the printers instead of waiting for the end of the Bluetooth timeout and then output all devices at once. This way the entries for the found printers are usually already put out when CUPS kills the backend after 10 seconds (or whatever timeout is requested from CUPS).

Changed in bluez (Ubuntu):
status:	In Progress → Fix Committed

Revision history for this message

Till Kamppeter (till-kamppeter) wrote on 2009-08-26:

Mario, can you upload the patched bluez package to Karmic? Thanks.

Changed in bluez (Ubuntu):
assignee:	nobody → Mario Limonciello (superm1)

Revision history for this message

Mario Limonciello (superm1) wrote on 2009-08-26:

Once upstream ack's it, i'll be glad to sponsor it in.

Revision history for this message

Till Kamppeter (till-kamppeter) wrote on 2009-08-26:

Upstream (Marcel Holtmann) has accepted the patch.

Revision history for this message

Till Kamppeter (till-kamppeter) wrote on 2009-09-01:

Got committed upstream to the GIT repository as rev 74799904f87.

Revision history for this message

Martin Pitt (pitti) wrote on 2009-09-01:

Uploaded with adding the bug # to changelog and fixing the "backenmd" typo.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2009-09-01:

This bug was fixed in the package bluez - 4.48-0ubuntu2

---------------
bluez (4.48-0ubuntu2) karmic; urgency=low

  * debian/patches/10_bluetooth-cups-backend-report-printers-immediately.patch:
    Let bluetooth CUPS backend immediately output a printer entry when it
    discovers a printer instead of outputtting the whole printer list after the
    timeout. This is needed for the new device discovery environment of CUPS.
    (LP: #418465)

-- Till Kamppeter <email address hidden> Wed, 26 Aug 2009 18:42:33 +0200