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

Bug#928838: marked as done (cups: Printing from local queue via remote queue not working any more, jobs just vanish)



Your message dated Mon, 10 Jan 2022 13:40:26 +0000
with message-id <10012022133801.c738dea63988@desktop.copernicus.org.uk>
and subject line Re: Bug#928838: cups: Printing from local queue via remote queue not working any more, jobs just vanish
has caused the Debian Bug report #928838,
regarding cups: Printing from local queue via remote queue not working any more, jobs just vanish
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.)


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

Dear Maintainer,

   * What led up to the situation?

Setup:

Laptop (Client) running Debian 9/10 and CUPS 2.2.1/2.2.10
Server/Router running Debian 10 and CUPS 2.2.10
Printer Samsung Xpress C480W, LAN/WLAN

Laptop is connected to Server via SSID WLAN_1, Subnet 1
Printer is connected to Server via SSID WLAN_2, Subnet 2
Server should act as a print server running CUPS. Clients (laptop, printer) in
different subnets should not communicate directly.

Printer is configured in CUPS on the server as ipp://printername:631/ipp/print,
with Samsung C48x driver, queue name SAMSUNG, printing test pages from the
server's web interface works fine
Printer is configured in CUPS on the Laptop as
ipps://servername:631/printers/SAMSUNG

With Debian 9 and CUPS 2.2.1 on the Server, this setup worked fine.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Upgraded Server to Debian 10, CUPS 2.2.10

   * What was the outcome of this action?

Printing as describes above stopped working. Jobs sent from the laptop just go
into Nirvana, they vanish and do not show up in the server's queue. The servers
access_log reports success, but printing never happens. No errors are reported
neither on the laptop nor on the server.

   * What outcome did you expect instead?

Printing as before.

   * Workaround(s)

- Downgrading CUPS from 2.2.10 to 2.2.1 (debs from Debian 9) on the Debian 10
server fixes this problem, printing works fine again.
- Using a client.conf file with "ServerName servername" makes printing
possible, but without a local queue there's no queue dialog that can report
failures (emtpy tray, paper jam) on the client
- Printing directly to the printer from the laptop works, but is not desired

So, CUPS 2.2.10 is broken when used as a print server for clients running local
queues.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cups depends on:
ii  cups-client            2.2.10-6
ii  cups-common            2.2.10-6
ii  cups-core-drivers      2.2.10-6
ii  cups-daemon            2.2.10-6
ii  cups-filters           1.21.6-5
ii  cups-ppdc              2.2.10-6
ii  cups-server-common     2.2.10-6
ii  debconf [debconf-2.0]  1.5.71
ii  ghostscript            9.27~dfsg-1
ii  libavahi-client3       0.7-4+b1
ii  libavahi-common3       0.7-4+b1
ii  libc6                  2.28-10
ii  libcups2               2.2.10-6
ii  libcupsimage2          2.2.10-6
ii  libgcc1                1:8.3.0-6
ii  libstdc++6             8.3.0-6
ii  libusb-1.0-0           2:1.0.22-2
ii  poppler-utils          0.71.0-3
ii  procps                 2:3.3.15-2

Versions of packages cups recommends:
ii  avahi-daemon                     0.7-4+b1
ii  colord                           1.4.3-4
ii  cups-filters [ghostscript-cups]  1.21.6-5
ii  printer-driver-gutenprint        5.3.1-7

Versions of packages cups suggests:
ii  cups-bsd               2.2.10-6
pn  cups-pdf               <none>
ii  foomatic-db            20181217-2
ii  hplip                  3.18.12+dfsg0-2
ii  printer-driver-hpcups  3.18.12+dfsg0-2
pn  smbclient              <none>
ii  udev                   241-3

-- Configuration Files:
/etc/cups/cupsd.conf [Errno 13] Keine Berechtigung: '/etc/cups/cupsd.conf'

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

--- End Message ---
--- Begin Message ---
On Sun 12 May 2019 at 04:20:12 +0200, Robert Senger wrote:

> Package: cups
> Version: 2.2.10-6
> Severity: normal
>
> Dear Maintainer,
>
>    * What led up to the situation?
>
> Setup:
>
> Laptop (Client) running Debian 9/10 and CUPS 2.2.1/2.2.10
> Server/Router running Debian 10 and CUPS 2.2.10
> Printer Samsung Xpress C480W, LAN/WLAN
>
> Laptop is connected to Server via SSID WLAN_1, Subnet 1
> Printer is connected to Server via SSID WLAN_2, Subnet 2
> Server should act as a print server running CUPS. Clients (laptop, printer) in
> different subnets should not communicate directly.
>
> Printer is configured in CUPS on the server as ipp://printername:631/ipp/print,
> with Samsung C48x driver, queue name SAMSUNG, printing test pages from the
> server's web interface works fine
> Printer is configured in CUPS on the Laptop as
> ipps://servername:631/printers/SAMSUNG
>
> With Debian 9 and CUPS 2.2.1 on the Server, this setup worked fine.
>
>    * What exactly did you do (or not do) that was effective (or
>      ineffective)?
>
> Upgraded Server to Debian 10, CUPS 2.2.10
>
>    * What was the outcome of this action?
>
> Printing as describes above stopped working. Jobs sent from the laptop just go
> into Nirvana, they vanish and do not show up in the server's queue. The servers
> access_log reports success, but printing never happens. No errors are reported
> neither on the laptop nor on the server.
>
>    * What outcome did you expect instead?
>
> Printing as before.
>
>    * Workaround(s)
>
> - Downgrading CUPS from 2.2.10 to 2.2.1 (debs from Debian 9) on the Debian 10
> server fixes this problem, printing works fine again.
> - Using a client.conf file with "ServerName servername" makes printing
> possible, but without a local queue there's no queue dialog that can report
> failures (emtpy tray, paper jam) on the client
> - Printing directly to the printer from the laptop works, but is not desired
>
> So, CUPS 2.2.10 is broken when used as a print server for clients running local
> queues.

Dear Debian User,

Further information on your issue was requested some time ago but there
hasn't been any response from you. Use of our limited, volunteer
supported resources is best served by not keeping open inactive bugs any
longer than desirable, especially in cases where the package concerned
is older than the current stable Debian version. Consequently, the
report is now being closed.

Regards,

Brian.

--- End Message ---

Reply to: