[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#868728: marked as done (cups requires do lpadmin configuration to share printers)



Your message dated Wed, 19 Jul 2017 15:27:09 +0100
with message-id <19072017151549.ce289c9ac2df@desktop.copernicus.org.uk>
and subject line Re: Bug#868728: cups requires do lpadmin configuration to share printers
has caused the Debian Bug report #868728,
regarding cups requires do lpadmin configuration to share printers
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
868728: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868728
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: cups
Version: 2.2.1-8
Severity: normal

Hi!

When trying to share my printers with my roommates through the CUPS
web interface, I quickly found the "Share printers connected to this
system" button and clicked it. And lo and behold, other Linux (and
probably Mac, haven't tried) computers just see the printers and can
print to it. Great!

But when they do, they get this mysterious error message: "Filter
failed". Searching for that error message on the web is a dead end:
you end up with all sorts of errors with foomatic-db not being
configured properly and so on. This problem is remote-specific:
printing works fine on the local machine, just not from the remote
CUPS clients.

I have found this bug in the RedHat bugtracker that seems similar to
the situation I'm seeing here:

https://bugzilla.redhat.com/show_bug.cgi?id=1010580

This is another forum with the simple solution:

https://ubuntuforums.org/showthread.php?t=2254352

.. which is to run the following command, in a terminal:

   sudo lpadmin -p HP-LaserJet-p3015 -m raw

where "HP-LaserJet-p3015" is the printer name.

It seems to me a little odd that I would need to do this, as a user. I
would expect the graphical interface to do the right thing, or just
not offer the functionality at all. In the RH bugtracker, there's a
debate regarding whether this is an actual bug, as this seems to be
upstream's behavior of choice, but I fail to see how this is an
appropriate response... I am using what are mostly default
configurations here and didn't do anything special on the remote
computer.

It seems to me it would be essential to be able to share printers
through the GUI in Debian, out of the box. Having people go through
the commandline to workaround such an issue seems to defeat the whole
point of having that GUI in the first place.

Or did I miss something?

Thanks!

-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cups depends on:
ii  cups-client            2.2.1-8
ii  cups-common            2.2.1-8
ii  cups-core-drivers      2.2.1-8
ii  cups-daemon            2.2.1-8
ii  cups-filters           1.11.6-3
ii  cups-ppdc              2.2.1-8
ii  cups-server-common     2.2.1-8
ii  debconf [debconf-2.0]  1.5.61
ii  ghostscript            9.20~dfsg-3.2
ii  libavahi-client3       0.6.32-2
ii  libavahi-common3       0.6.32-2
ii  libc-bin               2.24-11+deb9u1
ii  libc6                  2.24-11+deb9u1
ii  libcups2               2.2.1-8
ii  libcupscgi1            2.2.1-8
ii  libcupsimage2          2.2.1-8
ii  libcupsmime1           2.2.1-8
ii  libcupsppdc1           2.2.1-8
ii  libgcc1                1:6.3.0-18
ii  libstdc++6             6.3.0-18
ii  libusb-1.0-0           2:1.0.21-1
ii  poppler-utils          0.48.0-2
ii  procps                 2:3.3.12-3

Versions of packages cups recommends:
ii  avahi-daemon                     0.6.32-2
ii  colord                           1.3.3-2
ii  cups-filters [ghostscript-cups]  1.11.6-3
ii  printer-driver-gutenprint        5.2.11-1+b2

Versions of packages cups suggests:
ii  cups-bsd                                   2.2.1-8
pn  cups-pdf                                   <none>
ii  foomatic-db-compressed-ppds [foomatic-db]  20161201-1
ii  hplip                                      3.16.11+repack0-3
ii  printer-driver-hpcups                      3.16.11+repack0-3
pn  smbclient                                  <none>
ii  udev                                       232-25

-- debconf information:
  cupsys/backend: lpd, socket, usb, snmp, dnssd
  cupsys/raw-print: true

--- End Message ---
--- Begin Message ---
On Tue 18 Jul 2017 at 19:33:09 -0400, Antoine Beaupré wrote:

> On 2017-07-19 00:23:32, Brian Potkin wrote:
> > Just a normal misconfiguration. Tell them not to do double filtering.
> > It's evil and completely unnecessary.
> 
> I guess this is the root of the problem. I don't even know how they/I
> did that in the first place.
> 
> I wouldn't even know how to undo the `lpadmin raw` thing i did to
> workaround the problem in the first place.

Assuming cups-browsed installed and stopped a non-empty output to
'lpstat -a' might jog your memory as to the queue name. Delete with
'lpadmin -x ....' or use the web interface.

Actually, if the client prints only from GTK applications (Firefox,
Evince etc) you can dispense with cups-browsed and the cups daemon
because the applications will display your printers without any
outside aid.

I do not think we have a cups bug here. So, if you are satisfied, I
will close the report.

Cheers,

Brian.

--- End Message ---

Reply to: