Bug#815807: cups: printing on printers broadcast by old CUPS versions fails
On Sun 04 Sep 2016 at 19:23:53 +0100, Brian Potkin wrote: > tags 815807 moreinfo > thanks > > > On Sun 28 Aug 2016 at 14:51:42 +0100, Brian Potkin wrote: > > > On Mon 22 Aug 2016 at 19:36:32 +0100, Brian Potkin wrote: > > > > > You have duplicate queues being broadcast on the network; is this your > > > intention? cups-browsed combines them into one Implicit Class queue. > > Have you managed to identify these queues so that we can make progress > with this report? Enquiring minds await your response. -- Brian
Bug#815807: cups: printing on printers broadcast by old CUPS versions fails
tags 815807 moreinfo thanks On Sun 28 Aug 2016 at 14:51:42 +0100, Brian Potkin wrote: > On Mon 22 Aug 2016 at 19:36:32 +0100, Brian Potkin wrote: > > > You have duplicate queues being broadcast on the network; is this your > > intention? cups-browsed combines them into one Implicit Class queue. Have you managed to identify these queues so that we can make progress with this report? Regards, Brian.
Bug#815807: cups: printing on printers broadcast by old CUPS versions fails
On Mon 22 Aug 2016 at 19:36:32 +0100, Brian Potkin wrote: > On Fri 19 Aug 2016 at 12:42:51 +0100, Patrick Welche wrote: > > > > > > 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. That could be misleading. The duplicate queues are duplicate in the sense they have identical names. At least two queues called ufs2 should be on the network for cups-browsed to use the implicitclass URI. ufs2 and UFS2 are duplicates because queue names are case-insensitive when it comes to printing. > 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. Let's go with "Maybe I am doing some wrong". It took me some time to realise having cups-browsed running on A and B wasn't exactly conducive to having two broadcast queues. Then I (perhaps rashly) purged and reinstalled all cups related packages. Since then I have been unable to reproduce the previous behaviour; load balancing works as described when A and B are doing Bonjour broadcasting. (I realise this is not your situation but did not want my initial remarks to muddy the waters). Cheers, Brian.
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: > > > DeviceURI socket://... > ... > Accepting Yes > Shared Yes > > on new, presumably having cups-browsed it: > > > 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.
Bug#815807: cups: printing on printers broadcast by old CUPS versions fails
Package: cups Version: 2.1.3-1 Severity: normal I just reproduced this, admittedly between ubuntu rather than vanilla debian boxen, so it sounds like a real cups problem. "Old" cups is 1.4.3 "New" cups is 2.1.3 extract of /etc/cups/printers.conf on old: DeviceURI socket://... ... Accepting Yes Shared Yes on new, presumably having cups-browsed it: DeviceURI implicitclass:ufs2 ... Accepting Yes Shared No So, apparently no longer shared... (is that right?) Rejecting job because "ufs2" is not shared quick round of lpadmin later, changed to Shared Yes, and thereafter held since "No suitable destination host found by cups-browsed." Cheers, Patrick
Bug#815807: cups: printing on printers broadcast by old CUPS versions fails
tags 815807 moreinfo thanks On Thu 25 Feb 2016 at 20:30:02 +, Brian Potkin wrote: > Anything you can provide which would make the behaviour reproducible > would be helpful. Any additional information which would progress this report? Regards, Brian.
Bug#815807: cups: printing on printers broadcast by old CUPS versions fails
On Wed 24 Feb 2016 at 16:57:41 +0100, Dominik George wrote:
> Printing on printers published by CUPS 1.7.5 on a Debian stable print
> server fails with the following:
>
> No suitable destination host found by cups-browsed.
How do you receive this error message? In a log?
> The printers are recorded as being on „luna.local“, which is correct,
> and I can resolve this name via mDNS and reach the host.
>
> This is reproducible with several different print servers and clients,
> always in the combination 2.1.3 client and 1.7.5 server.
Can you say a bit more about your setup? The message is associated with
backend/implicitclass.c of cups-filters. It implies remote queues are
disabled:
if (!strcmp(dest_host, "NO_DEST_FOUND")) {
/* All remote queues are either disabled or not accepting jobs, let
CUPS retry after the usual interval */
fprintf(stderr, "ERROR: No suitable destination host found by
cups-browsed.\n");
Anything you can provide which would make the behaviour reproducible
would be helpful.
Regards,
Brian.
Bug#815807: cups: printing on printers broadcast by old CUPS versions fails
Package: cups Version: 2.1.3-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Printing on printers published by CUPS 1.7.5 on a Debian stable print server fails with the following: No suitable destination host found by cups-browsed. The printers are recorded as being on „luna.local“, which is correct, and I can resolve this name via mDNS and reach the host. This is reproducible with several different print servers and clients, always in the combination 2.1.3 client and 1.7.5 server. - -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cups depends on: ii cups-client2.1.3-1 ii cups-common2.1.3-1 ii cups-core-drivers 2.1.3-1 ii cups-daemon2.1.3-1 ii cups-filters 1.8.2-2 ii cups-ppdc 2.1.3-1 ii cups-server-common 2.1.3-1 ii debconf [debconf-2.0] 1.5.58 ii ghostscript9.18~dfsg-4 ii libavahi-client3 0.6.32~rc+dfsg-1 ii libavahi-common3 0.6.32~rc+dfsg-1 ii libc-bin 2.21-9 ii libc6 2.21-9 ii libcups2 2.1.3-1 ii libcupscgi12.1.3-1 ii libcupsimage2 2.1.3-1 ii libcupsmime1 2.1.3-1 ii libcupsppdc1 2.1.3-1 ii libgcc11:5.3.1-9 ii libstdc++6 5.3.1-9 ii libusb-1.0-0 2:1.0.20-1 ii lsb-base 9.20160110 ii poppler-utils 0.38.0-2 ii procps 2:3.3.11-3 Versions of packages cups recommends: ii avahi-daemon 0.6.32~rc+dfsg-1 ii colord 1.2.12-1 ii cups-filters [ghostscript-cups] 1.8.2-2 ii printer-driver-gutenprint5.2.11-1 Versions of packages cups suggests: ii cups-bsd 2.1.3-1 pn cups-pdf ii foomatic-db-compressed-ppds [foomatic-db] 20160212-1 ii hplip 3.16.2+repack0-3 ii printer-driver-hpcups 3.16.2+repack0-3 pn smbclient ii udev 229-1 - -- debconf information: cupsys/raw-print: true cupsys/backend: lpd, socket, usb, snmp, dnssd -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJOBAEBCAA4BQJWzdLuMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pbFRA//YI0v+RgQ84ROv7lmUyGU /dfQBlnPBL+x3STFtnU4IKZEvTOSO5Xh53eulPypILJTIkOOeUXXwNW9dEjyg+Qr NpnHhr9sUUD31h29La4kpRmv/Ew2aHoEc5SXrfwBP4aQIEXLbEcHGSzs/jWMn65I y796H5dQKJJWTR2Kmb+1B0byifrnaZn0wCH9sdedIh5eqvGqpiF19x23C/YCnsY/ hOP37KpLXlbyVEgU9QjmCNSt2yk+MDpMzu83CeR+REu9m8kKRseelRexgVZAt5tu tKXf84gfTlo2ruQgEPJBEtG/VRtovU7NlrwO9PnmPQXHPR/PFs9TQd1dutcwaYnt xU38L+7YaH9qGelvVeRio6nIwnAVjKlq+8WTntkSyIAw2k4UC8MKFs92Fr0dIVfE RLLAuGC2Kmx/Zkqk7bhFtxItr6NMOBfjFCxSDaYpmGkzctqeThUsRl2wm+elHw3I D14HtChof5L9C3hMvul8MkwlbKHtApAIOJHIYhN2mh8J8PVbkbqQRRhA8R32qE0B D2kElgINSGp1S2pmcYGhj3AmbJtWCjgp94tIzgI61beH1THtyUbfJGhmlLjABDwO Hh5WMssV6A195CiYuyE9aATkbDsfGK3+f42c7pJXv/vVyO76YToh7RQJLO7sYv2B NUkpA4NDqB5ixvvw/ocYoyM= =oHy8 -END PGP SIGNATURE-
