Hi,
I am using Bluez 4.48 in Ubuntu Karmic. First thank you for applying my
patches. The bluetooth backend works perfectly now with CUPS 1.3.x and
older. On the new CUPS 1.4.x a new problem appeared: The new CUPS does
device discovery only for a given time frame requested by the client
(printer setup tool, "lpinfo" command). CUPS's default for
CUPS-1.3.x-ish requests without timeout specification seems to be 10
seconds. CUPS startys all backends at once in the beginning (in
parallel) and kills every backend which remains running at the end of
the timeout. It accepts output from the backends whenever it occurs not
only when the backend finishes, so a backend can search for printers
infinitely long if it outputs every found device immediately. Then all
printers found during CUPS' timeout are taken into account.
The bluetooth backend o 4.48 asks the Bluetooth daemon for printers and
collects results for 10 seconds and after that it output them. This
takes a total of 10.5 sec and so CUPS kills the backend right before it
answers (at least with the 10-second default timeout), resulting in
Bluetooth printers never being discovered by CUPS.
I have fixed this now with the attached patch, by making each new
printer added to the list being output immediately. Note that the list
structure cannot be removed from cups/main.c as otherwise we would get
duplicate listings.
Can you please apply this patch to Bluez so that Bluez gets ready for
the new CUPS 1.4.x generation? Thanks.
Till
http://www.openprinting.org/
Hi Mario,
>
> I can't use git am to apply this patch. Someone has to fix
> this for me.
>
> It looks like Till's email client is just beating it up. Applies for
> me with "git am" and the attached patch fine, but the inline is
> corrupt.
can I get this one without touching ChangeLog. That file will only be
touched be me before making the release. You guys make it pretty hard
for me to apply patches. It is not that complicated.
Regards
Marcel
Hi Marcel:
On Thu, Aug 27, 2009 at 14:21, Marcel Holtmann <[email protected]> wrote:
>
> I can't use git am to apply this patch. Someone has to fix this for me.
>
> Regards
>
> Marcel
>
>
It looks like Till's email client is just beating it up. Applies for
me with "git am" and the attached patch fine, but the inline is
corrupt.
--
Mario Limonciello
[email protected]
Sent from Austin, TX, United States
Hi Marcel:
On Thu, Aug 27, 2009 at 14:21, Marcel Holtmann <[email protected]> wrote:
>
> I can't use git am to apply this patch. Someone has to fix this for me.
>
> Regards
>
> Marcel
>
It looks like Till's email client is just beating it up. Applies for me
with "git am" and the attached patch fine, but the inline is corrupt.
--
Mario Limonciello
[email protected]
Sent from Austin, TX, United States
Hi Till,
> The new CUPS 1.4.x does device discovery only for a given time frame
> requested by the client (printer setup tool, "lpinfo" command). CUPS's
> default for CUPS-1.3.x-ish requests without timeout specification
> seems to be 10 seconds. CUPS starts all backends at once in the
> beginning (in parallel) and kills every backend which remains running
> at the end of the timeout. It accepts output from the backends
> whenever it occurs not only when the backend finishes, so a backend
> can search for printers infinitely long if it outputs every found
> device immediately. Then all printers found during CUPS' timeout are
> taken into account.
>
> The bluetooth backend of 4.48 asks the Bluetooth daemon for printers
> and collects results for 10 seconds and after that it outputs
> them. This takes a total of 10.5 sec and so CUPS kills the backend
> right before it answers (at least with the 10-second default timeout),
> resulting in Bluetooth printers never being discovered by CUPS.
>
> This change fixes it by making each new printer added to the list
> being output immediately. Note that the list structure cannot be
> removed from cups/main.c as otherwise we would get duplicate
> listings. Also important is the addition of unbuffered output on
> stdout.
> ---
> ChangeLog | 2 +
> cups/main.c | 63
> +++++++++++++++++++++++-----------------------------------
> 2 files changed, 27 insertions(+), 38 deletions(-)
I can't use git am to apply this patch. Someone has to fix this for me.
Regards
Marcel
The new CUPS 1.4.x does device discovery only for a given time frame
requested by the client (printer setup tool, "lpinfo" command). CUPS's
default for CUPS-1.3.x-ish requests without timeout specification
seems to be 10 seconds. CUPS starts all backends at once in the
beginning (in parallel) and kills every backend which remains running
at the end of the timeout. It accepts output from the backends
whenever it occurs not only when the backend finishes, so a backend
can search for printers infinitely long if it outputs every found
device immediately. Then all printers found during CUPS' timeout are
taken into account.
The bluetooth backend of 4.48 asks the Bluetooth daemon for printers
and collects results for 10 seconds and after that it outputs
them. This takes a total of 10.5 sec and so CUPS kills the backend
right before it answers (at least with the 10-second default timeout),
resulting in Bluetooth printers never being discovered by CUPS.
This change fixes it by making each new printer added to the list
being output immediately. Note that the list structure cannot be
removed from cups/main.c as otherwise we would get duplicate
listings. Also important is the addition of unbuffered output on
stdout.
---
ChangeLog | 2 +
cups/main.c | 63
+++++++++++++++++++++++-----------------------------------
2 files changed, 27 insertions(+), 38 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index d06f494..6c170f6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,5 @@
+ver 4.51:
+ Make discovery mode of bluetooth CUPS backend work with CUPS 1.4.0.
ver 4.50:
Fix issue with missing manual pages in distribution.
Fix issue with the configuration and state directories.
diff --git a/cups/main.c b/cups/main.c
index da757b0..1bbc78c 100644
--- a/cups/main.c
+++ b/cups/main.c
@@ -185,6 +185,27 @@ static char *device_get_ieee1284_id(const char
*adapter, const char *device)
return id;
}
+static void print_printer_details(const char *name, const char *bdaddr,
const char *id)
+{
+ char *uri, *escaped;
+
+ escaped = g_strdelimit(g_strdup(name), "\"", '\'');
+ uri = g_strdup_printf("bluetooth://%c%c%c%c%c%c%c%c%c%c%c%c",
+ bdaddr[0], bdaddr[1],
+ bdaddr[3], bdaddr[4],
+ bdaddr[6], bdaddr[7],
+ bdaddr[9], bdaddr[10],
+ bdaddr[12], bdaddr[13],
+ bdaddr[15], bdaddr[16]);
+ printf("direct %s \"%s\" \"%s (Bluetooth)\"", uri, escaped, escaped);
+ if (id != NULL)
+ printf(" \"%s\"\n", id);
+ else
+ printf("\n");
+ g_free(escaped);
+ g_free(uri);
+}
+
static void add_device_to_list(const char *name, const char *bdaddr,
const char *id)
{
struct cups_device *device;
@@ -212,27 +233,7 @@ static void add_device_to_list(const char *name,
const char *bdaddr, const char
device->id = g_strdup(id);
device_list = g_slist_prepend(device_list, device);
-}
-
-static void print_printer_details(const char *name, const char *bdaddr,
const char *id)
-{
- char *uri, *escaped;
-
- escaped = g_strdelimit(g_strdup(name), "\"", '\'');
- uri = g_strdup_printf("bluetooth://%c%c%c%c%c%c%c%c%c%c%c%c",
- bdaddr[0], bdaddr[1],
- bdaddr[3], bdaddr[4],
- bdaddr[6], bdaddr[7],
- bdaddr[9], bdaddr[10],
- bdaddr[12], bdaddr[13],
- bdaddr[15], bdaddr[16]);
- printf("direct %s \"%s\" \"%s (Bluetooth)\"", uri, escaped, escaped);
- if (id != NULL)
- printf(" \"%s\"\n", id);
- else
- printf("\n");
- g_free(escaped);
- g_free(uri);
+ print_printer_details(device->name, device->bdaddr, device->id);
}
static gboolean parse_device_properties(DBusMessageIter *reply_iter,
char **name, char **bdaddr)
@@ -384,23 +385,6 @@ static void remote_device_found(const char
*adapter, const char *bdaddr, const c
static void discovery_completed(void)
{
- GSList *l;
-
- for (l = device_list; l != NULL; l = l->next) {
- struct cups_device *device = (struct cups_device *) l->data;
-
- if (device->name == NULL)
- device->name = g_strdelimit(g_strdup(device->bdaddr), ":", '-');
- /* Give another try to getting an ID for the device */
- if (device->id == NULL)
- remote_device_found(NULL, device->bdaddr, device->name);
- print_printer_details(device->name, device->bdaddr, device->id);
- g_free(device->name);
- g_free(device->bdaddr);
- g_free(device->id);
- g_free(device);
- }
-
g_slist_free(device_list);
device_list = NULL;
@@ -638,6 +622,9 @@ int main(int argc, char *argv[])
/* Make sure status messages are not buffered */
setbuf(stderr, NULL);
+ /* Make sure output is not buffered */
+ setbuf(stdout, NULL);
+
/* Ignore SIGPIPE signals */
#ifdef HAVE_SIGSET
sigset(SIGPIPE, SIG_IGN);
--
1.6.3.3
Hi Till,
please stop top posting. This is a proper open source mailing list and
we do proper inline quoting.
> Thank you for the quick answer.
>
> Patch in GIT format attached.
So you have time to write a lengthy email with an explanation what is
going on, but the commit message is empty. Please fix the commit message
since that is where it should be. Especially since you wrote it already
anyway.
Regards
Marcel
Thank you for the quick answer.
Patch in GIT format attached.
Till
Marcel Holtmann wrote:
> Hi Till,
>
>> I am using Bluez 4.48 in Ubuntu Karmic. First thank you for applying my
>> patches. The bluetooth backend works perfectly now with CUPS 1.3.x and
>> older. On the new CUPS 1.4.x a new problem appeared: The new CUPS does
>> device discovery only for a given time frame requested by the client
>> (printer setup tool, "lpinfo" command). CUPS's default for
>> CUPS-1.3.x-ish requests without timeout specification seems to be 10
>> seconds. CUPS startys all backends at once in the beginning (in
>> parallel) and kills every backend which remains running at the end of
>> the timeout. It accepts output from the backends whenever it occurs not
>> only when the backend finishes, so a backend can search for printers
>> infinitely long if it outputs every found device immediately. Then all
>> printers found during CUPS' timeout are taken into account.
>>
>> The bluetooth backend o 4.48 asks the Bluetooth daemon for printers and
>> collects results for 10 seconds and after that it output them. This
>> takes a total of 10.5 sec and so CUPS kills the backend right before it
>> answers (at least with the 10-second default timeout), resulting in
>> Bluetooth printers never being discovered by CUPS.
>>
>> I have fixed this now with the attached patch, by making each new
>> printer added to the list being output immediately. Note that the list
>> structure cannot be removed from cups/main.c as otherwise we would get
>> duplicate listings.
>>
>> Can you please apply this patch to Bluez so that Bluez gets ready for
>> the new CUPS 1.4.x generation? Thanks.
>
> send a patch created with git format-patch so we can apply them properly
> without me having to modify the commit message manually.
>
> Regards
>
> Marcel
>
>
>
Hi Till,
> I am using Bluez 4.48 in Ubuntu Karmic. First thank you for applying my
> patches. The bluetooth backend works perfectly now with CUPS 1.3.x and
> older. On the new CUPS 1.4.x a new problem appeared: The new CUPS does
> device discovery only for a given time frame requested by the client
> (printer setup tool, "lpinfo" command). CUPS's default for
> CUPS-1.3.x-ish requests without timeout specification seems to be 10
> seconds. CUPS startys all backends at once in the beginning (in
> parallel) and kills every backend which remains running at the end of
> the timeout. It accepts output from the backends whenever it occurs not
> only when the backend finishes, so a backend can search for printers
> infinitely long if it outputs every found device immediately. Then all
> printers found during CUPS' timeout are taken into account.
>
> The bluetooth backend o 4.48 asks the Bluetooth daemon for printers and
> collects results for 10 seconds and after that it output them. This
> takes a total of 10.5 sec and so CUPS kills the backend right before it
> answers (at least with the 10-second default timeout), resulting in
> Bluetooth printers never being discovered by CUPS.
>
> I have fixed this now with the attached patch, by making each new
> printer added to the list being output immediately. Note that the list
> structure cannot be removed from cups/main.c as otherwise we would get
> duplicate listings.
>
> Can you please apply this patch to Bluez so that Bluez gets ready for
> the new CUPS 1.4.x generation? Thanks.
send a patch created with git format-patch so we can apply them properly
without me having to modify the commit message manually.
Regards
Marcel
Hi Bastien,
> > Could you put them in? Then I do not need to download the git only to
> > format two simple one-point-only-changed patches. Thanks.
>
> Patches attached.
patch have been applied. Thanks.
Regards
Marcel
Hi Bastien,
> > Could you put them in? Then I do not need to download the git only to
> > format two simple one-point-only-changed patches. Thanks.
>
> Patches attached.
>
> > >> Do you have a bug/feature request tracking system?
> > >
> > > There isn't one.
> >
> > As vluez seems to be a part of the kernel project, does the kernel even
> > not have a bug tracking system?
>
> BlueZ's kernel bits probably use the kernel bug tracker. For the
> user-space bits, send mails here[1].
kernel patches and userspace patches should be send to this mailing
list.
Regards
Marcel
On Tue, 2009-08-11 at 14:24 +0200, Till Kamppeter wrote:
<snip>
> Could you put them in? Then I do not need to download the git only to
> format two simple one-point-only-changed patches. Thanks.
Patches attached.
> >> Do you have a bug/feature request tracking system?
> >
> > There isn't one.
>
> As vluez seems to be a part of the kernel project, does the kernel even
> not have a bug tracking system?
BlueZ's kernel bits probably use the kernel bug tracker. For the
user-space bits, send mails here[1].
Cheers
[1]: Note that I've been barking up that tree for a while...
Bastien Nocera wrote:
> You're modifying a file in the Ubuntu package (it's in the debian/
> sub-directory), not the one from bluez (src/bluetooth.conf in the
> sources).
>
For the Ubuntu packaging I did the change in the Ubuntu-provided version
of the file as the Ubuntu (Debian?) package maintainer did other changes
there. Putting my change in the original file then would have resulted
in them being overwritten. In the upstream fix I naturally expect the
change to be applied to src/bluetooth.conf.
>> A Bluetooth printer has to get paired with a computer before the
>> Bluetooth CUPS backend can find it.
>
> I know that, seeing as I wrote the discovery code in the bluetooth
> backend :)
>
OK, I mentioned that only to tell why the Bluetooth printers should be
considered local.
>> This makes it getting assigned to
>> one single computer, whereas a network printer (Ethernet or WLAN) gets
>> discovered by all computers in the network and all computers can have a
>> working queue accessing to the same network printer. Therefore a
>> Bluetooth printer has more the characteristics of a local printer.
>
> Seems fair.
>
OK.
>
> You're right, read the patch in reverse...
>
OK.
>>> In the future, please attach the patches to your mail, and make sure
>>> they apply to the upstream sources.
>> Sorry, was my first patch submission to this project.
>
> Could you rebase your fixes into patches ready for inclusion in the git
> tree? If you don't know git, I'll make those changes myself.
>
Could you put them in? Then I do not need to download the git only to
format two simple one-point-only-changed patches. Thanks.
>> Do you have a bug/feature request tracking system?
>
> There isn't one.
As vluez seems to be a part of the kernel project, does the kernel even
not have a bug tracking system?
Till
Bastien Nocera wrote:
>> Therefore I have modified /etc/dbus-1/system.d/bluetooth.conf
>> to grant this permission.
>>
>> I have added the following lines into the <busconfig> section:
>>
>>
>> <!-- allow users of lp group (printing subsystem) to communicate with
>> hcid -->
>> <policy group="lp">
>> <allow send_destination="org.bluez"/>
>> </policy>
>
> Looks good. What about patching the upstream config file instead?
>
This is my intention, is it another file than
/etc/dbus-1/system.d/bluetooth.conf? I simply want nothing more than
that the access permission for "lp" is there out-of-the-box.
>> Second, the output of the CUPS Bluetooth backend was not very good for
>> the printer setup tools doing the right thing. I have patched the
>> backend to let the device class of the Bluetooth printers to be "direct"
>> and not "network", as users expect a Bluetooth printer rather under the
>> local printers than under the network printers.
>
> That seems like a good idea, but I don't know enough about the internals
> of CUPS to know whether it changes anything but the classification of
> the printer.
>
> If it doesn't change the behaviour wrt. errors and retries, then I'm
> fine with it.
>
The device class only appears in the output of the backends in discovery
mode. It does not enter anywhere into the configuration of the print
queue. So it seems only to server for separating local and network
printers in the listing of detected printers in a printer setup tool.
A Bluetooth printer has to get paired with a computer before the
Bluetooth CUPS backend can find it. This makes it getting assigned to
one single computer, whereas a network printer (Ethernet or WLAN) gets
discovered by all computers in the network and all computers can have a
working queue accessing to the same network printer. Therefore a
Bluetooth printer has more the characteristics of a local printer.
>> I have also filled the
>> make-and-model field instead of putting a hard-coded "Unknown" there.
>> The change is here:
>
> This part is broken. The backend man page says those are possible types
> of output:
> device-class scheme "Unknown" "device-info"
> device-class device-uri "device-make-and-model" "device-info"
> device-class device-uri "device-make-and-model" "device-info" "device-id"
> device-class device-uri "device-make-and-model" "device-info" "device-id" "device-location"
>
> So if you have the device-id, you must have a device-info. Your patch
> removes the device-info even if we have a device-id.
>
Really? What I did is replacing the "Unknown" by "%s" and adding a
second "expanded" for the additional "%s". I have tested it and it works
as expected.
This is the output with my patch:
direct bluetooth://001A0E1769AA "Officejet H470" "Officejet H470
(Bluetooth)" "MFG:HP;MDL:Officejet
H470_BT;CMD:PCL,DW-PCL,DESKJET,DYN;CLS:PRINTER;DES:CB028A;"
It has exactly the 5 items as the second last line of the output schemes
which you show above shows.
>
> In the future, please attach the patches to your mail, and make sure
> they apply to the upstream sources.
Sorry, was my first patch submission to this project.
Do you have a bug/feature request tracking system?
Till
Hello Till,
On Mon, 2009-08-10 at 22:19 +0200, Till Kamppeter wrote:
> Hi,
>
> I am using Bluez 4.47, and I can set up a Bluetooth printer only
> manually by running the "bluetooth" CUPS backend from the command line with
>
> /usr/lib/cups/backend/bluetooth
>
> and then pasting the URI into the field for individual URI input in
> system-config-printer ("Others" in the device list). Then I also need to
> choose manufacturer and model manually. My expectation is that I only
> need to click the printer's make model name in the devices list and
> choose "Bluetooth" under the connection types and then the driver gets
> selected automatically as it is the case for the same printer on USB or
> WLAN.
>
> I have found out why it does not work.
>
> First, the CUPS Bluetooth backend asks the bluez D-Bus service whether
> there are printers available and which device ID they have. The access
> permissions for the bluez D-Bus service do not permit the CUPS system
> user "lp" to access, and exactly as this user the Bluetooth backend is
> running. Therefore I have modified /etc/dbus-1/system.d/bluetooth.conf
> to grant this permission.
>
> I have added the following lines into the <busconfig> section:
>
>
> <!-- allow users of lp group (printing subsystem) to communicate with
> hcid -->
> <policy group="lp">
> <allow send_destination="org.bluez"/>
> </policy>
Looks good. What about patching the upstream config file instead?
> Second, the output of the CUPS Bluetooth backend was not very good for
> the printer setup tools doing the right thing. I have patched the
> backend to let the device class of the Bluetooth printers to be "direct"
> and not "network", as users expect a Bluetooth printer rather under the
> local printers than under the network printers.
That seems like a good idea, but I don't know enough about the internals
of CUPS to know whether it changes anything but the classification of
the printer.
If it doesn't change the behaviour wrt. errors and retries, then I'm
fine with it.
> I have also filled the
> make-and-model field instead of putting a hard-coded "Unknown" there.
> The change is here:
This part is broken. The backend man page says those are possible types
of output:
device-class scheme "Unknown" "device-info"
device-class device-uri "device-make-and-model" "device-info"
device-class device-uri "device-make-and-model" "device-info" "device-id"
device-class device-uri "device-make-and-model" "device-info" "device-id" "device-location"
So if you have the device-id, you must have a device-info. Your patch
removes the device-info even if we have a device-id.
<snip>
> See also my Ubuntu bug report:
>
> https://bugs.launchpad.net/bugs/411610
>
> I am very grateful if you could apply these changes to Bluez upstream,
> as this makes the bluetooth CUPS backend just work.
>
> Thank you very much in advance.
In the future, please attach the patches to your mail, and make sure
they apply to the upstream sources.
Cheers
On Tue, 2009-08-11 at 13:19 +0200, Till Kamppeter wrote:
> Bastien Nocera wrote:
> >> Therefore I have modified /etc/dbus-1/system.d/bluetooth.conf
> >> to grant this permission.
> >>
> >> I have added the following lines into the <busconfig> section:
> >>
> >>
> >> <!-- allow users of lp group (printing subsystem) to communicate with
> >> hcid -->
> >> <policy group="lp">
> >> <allow send_destination="org.bluez"/>
> >> </policy>
> >
> > Looks good. What about patching the upstream config file instead?
> >
>
> This is my intention, is it another file than
> /etc/dbus-1/system.d/bluetooth.conf? I simply want nothing more than
> that the access permission for "lp" is there out-of-the-box.
You're modifying a file in the Ubuntu package (it's in the debian/
sub-directory), not the one from bluez (src/bluetooth.conf in the
sources).
> >> Second, the output of the CUPS Bluetooth backend was not very good for
> >> the printer setup tools doing the right thing. I have patched the
> >> backend to let the device class of the Bluetooth printers to be "direct"
> >> and not "network", as users expect a Bluetooth printer rather under the
> >> local printers than under the network printers.
> >
> > That seems like a good idea, but I don't know enough about the internals
> > of CUPS to know whether it changes anything but the classification of
> > the printer.
> >
> > If it doesn't change the behaviour wrt. errors and retries, then I'm
> > fine with it.
> >
>
> The device class only appears in the output of the backends in discovery
> mode. It does not enter anywhere into the configuration of the print
> queue. So it seems only to server for separating local and network
> printers in the listing of detected printers in a printer setup tool.
>
> A Bluetooth printer has to get paired with a computer before the
> Bluetooth CUPS backend can find it.
I know that, seeing as I wrote the discovery code in the bluetooth
backend :)
> This makes it getting assigned to
> one single computer, whereas a network printer (Ethernet or WLAN) gets
> discovered by all computers in the network and all computers can have a
> working queue accessing to the same network printer. Therefore a
> Bluetooth printer has more the characteristics of a local printer.
Seems fair.
> >> I have also filled the
> >> make-and-model field instead of putting a hard-coded "Unknown" there.
> >> The change is here:
> >
> > This part is broken. The backend man page says those are possible types
> > of output:
> > device-class scheme "Unknown" "device-info"
> > device-class device-uri "device-make-and-model" "device-info"
> > device-class device-uri "device-make-and-model" "device-info" "device-id"
> > device-class device-uri "device-make-and-model" "device-info" "device-id" "device-location"
> >
> > So if you have the device-id, you must have a device-info. Your patch
> > removes the device-info even if we have a device-id.
> >
>
> Really? What I did is replacing the "Unknown" by "%s" and adding a
> second "expanded" for the additional "%s". I have tested it and it works
> as expected.
>
> This is the output with my patch:
>
> direct bluetooth://001A0E1769AA "Officejet H470" "Officejet H470
> (Bluetooth)" "MFG:HP;MDL:Officejet
> H470_BT;CMD:PCL,DW-PCL,DESKJET,DYN;CLS:PRINTER;DES:CB028A;"
>
> It has exactly the 5 items as the second last line of the output schemes
> which you show above shows.
You're right, read the patch in reverse...
> > In the future, please attach the patches to your mail, and make sure
> > they apply to the upstream sources.
>
> Sorry, was my first patch submission to this project.
Could you rebase your fixes into patches ready for inclusion in the git
tree? If you don't know git, I'll make those changes myself.
> Do you have a bug/feature request tracking system?
There isn't one.
On Thu, 2009-08-27 at 11:33 +0200, Till Kamppeter wrote:
> The new CUPS 1.4.x does device discovery only for a given time frame
> requested by the client (printer setup tool, "lpinfo" command). CUPS's
> default for CUPS-1.3.x-ish requests without timeout specification
> seems to be 10 seconds. CUPS starts all backends at once in the
> beginning (in parallel) and kills every backend which remains running
> at the end of the timeout. It accepts output from the backends
> whenever it occurs not only when the backend finishes, so a backend
> can search for printers infinitely long if it outputs every found
> device immediately. Then all printers found during CUPS' timeout are
> taken into account.
>
> The bluetooth backend of 4.48 asks the Bluetooth daemon for printers
> and collects results for 10 seconds and after that it outputs
> them. This takes a total of 10.5 sec and so CUPS kills the backend
> right before it answers (at least with the 10-second default timeout),
> resulting in Bluetooth printers never being discovered by CUPS.
>
> This change fixes it by making each new printer added to the list
> being output immediately. Note that the list structure cannot be
> removed from cups/main.c as otherwise we would get duplicate
> listings. Also important is the addition of unbuffered output on
> stdout.
Looks fine to me, although I'd have the stdout unbuffered change in a
separate patch instead.
Cheers