Bug#815807: cups: printing on printers broadcast by old CUPS versions fails
Reassign 815807 cups-browsed
thanks
Thank you for this additional information, Patrick.
On Fri 19 Aug 2016 at 12:42:51 +0100, Patrick Welche wrote:
> I just reproduced this, admittedly between ubuntu rather than vanilla debian
> boxen, so it sounds like a real cups problem.
The work involved in testing with Ubuntu installs and an ancient version
of CUPS didn't exactly thrill me. So I used two servers, A and B.
A has cups 1.7.5-11+deb8u1 (Jessie) and B cups 2.1.2-2. The client is an
up-to-date unstable.
> "Old" cups is 1.4.3
> "New" cups is 2.1.3
>
> extract of /etc/cups/printers.conf on old:
>
> <Printer ufs2>
> DeviceURI socket://...
> ...
> Accepting Yes
> Shared Yes
>
> on new, presumably having cups-browsed it:
>
> <Printer ufs2>
> DeviceURI implicitclass:ufs2
You have duplicate queues being broadcast on the network; is this your
intention? cups-browsed combines them into one Implicit Class queue.
> ...
> Accepting Yes
> Shared No
>
>
> So, apparently no longer shared... (is that right?)
Not shared by the client is what it means, I think.
> Rejecting job because "ufs2" is not shared
>
> quick round of lpadmin later, changed
> to Shared Yes, and thereafter
I'm not very sure I appreciate what you did here and whether it is
important. What command? Which machine was it executed on.
Servers A and B were set up with identical print queues. A largish file
was sent five times in rapid succession from the client. I expected the
printing to be distributed between A and B because of load balancing.
It wasn't; everything went to A.
I then disabled the queue on A, expecting B to be used. Then came
No suitable destination host found by cups-browsed.
in 'lpstat -t'.
Maybe I am doing some wrong but it does look like a bug in cups-browsed.
You will have to explain what you think is happening at your end and
whether it fits our experiences.
Regards,
Brian.
Reply to: