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.