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

Bug#953419: marked as done (hplip regression: 3.20.2 unable to print on HP_OfficeJet_Pro_8710)

Your message dated Tue, 28 Feb 2023 17:52:23 +0000 (UTC)
with message-id <alpine.DEB.2.21.2302281751510.22245@postfach.intern.alteholz.me>
and subject line Closing this bug (BTS maintenance for debian-printing)
has caused the Debian Bug report #953419,
regarding hplip regression: 3.20.2 unable to print on HP_OfficeJet_Pro_8710
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.)


-- 
953419: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953419
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: cups
Version: 2.3.1-7
Severity: important

Dear Maintainer,

Subject: cups: unable to print after a recent update
Package: cups
Version: 2.3.1-11
Severity: important

Dear Maintainer,

   * What led up to the situation?

After a recent upgrade files could no longer be printed. Printing a test page
through the printer's direct web-interface still works, as does using its
document scan facilities (through xsane). Printing a test-page through the
cups interface no longer works, and neither does the lp command

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

The only thing that changed was a recent update. The debian packages are
regularly updated, usually once a week.

   * What was the outcome of this action?

After a recent update standard print commands no longer worked. When trying to
print a test-page printing is pending, and 'service cups status' reports:

service cups status
● cups.service - CUPS Scheduler
     Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2020-03-09 13:10:31 CET; 16min ago
TriggeredBy: ● cups.path
             ● cups.socket
       Docs: man:cupsd(8)
   Main PID: 13933 (cupsd)
      Tasks: 3 (limit: 4602)
     Memory: 33.0M
     CGroup: /system.slice/cups.service
             ├─13933 /usr/sbin/cupsd -l
             ├─14170 HP_OfficeJet_Pro_8710 606 frank semval.h 1 finishings=3 number-up=1 sides=two-sided-long-edge job-uuid=urn:uuid:b9fe96d0-d6e7-31b2-7c2b-22d0a80a401a job-originating-host-name=localhost date-time-at-creation= date-time-at-proces>
             └─14171 hp:/net/HP_OfficeJet_Pro_8710?hostname=printer.oostum.north 606 frank semval.h 1 finishings=3 number-up=1 sides=two-sided-long-edge job-uuid=urn:uuid:b9fe96d0-d6e7-31b2-7c2b-22d0a80a401a job-originating-host-name=localhost date>

Mar 09 13:10:31 localhost.localdomain systemd[1]: Started CUPS Scheduler.
Mar 09 13:25:40 localhost.localdomain hp[13939]: io/hpmud/jd.c 94: unable to read device-id
Mar 09 13:25:40 localhost.localdomain hp[13939]: prnt/backend/hp.c 630: ERROR: 5012 device communication error!
Mar 09 13:26:15 localhost.localdomain cupsd[13933]: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory
Mar 09 13:26:15 localhost.localdomain cupsd[13933]: pam_unix(cups:auth): Couldn't open /etc/securetty: No such file or directory

I've found several references to /etc/securetty, most of them indicating that
/etc/securetty isn't used anymore, but after asking cups to print a test page
it takes a long while (about 2 minutes) before 'service cups stop' completes.

After 'service cups stop'; 'touch /etc/securetty'; and 'service cups start'
the error message no longer appears in the 'service cups status' command, but
still nothing is printed.

   * What outcome did you expect instead?

After the update I expected the print commands to continue working


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (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.3.1-11
ii  cups-common            2.3.1-11
ii  cups-core-drivers      2.3.1-11
ii  cups-daemon            2.3.1-11
ii  cups-filters           1.27.2-1
ii  cups-ppdc              2.3.1-11
ii  cups-server-common     2.3.1-11
ii  debconf [debconf-2.0]  1.5.73
ii  ghostscript            9.50~dfsg-5
ii  libavahi-client3       0.7-5
ii  libavahi-common3       0.7-5
ii  libc6                  2.29-10
ii  libcups2               2.3.1-11
ii  libgcc-s1              10-20200222-1
ii  libstdc++6             10-20200222-1
ii  libusb-1.0-0           2:1.0.23-2
ii  poppler-utils          0.71.0-6
ii  procps                 2:3.3.15-2+b1

Versions of packages cups recommends:
pn  avahi-daemon  <none>
ii  colord        1.4.3-4

Versions of packages cups suggests:
ii  cups-bsd                                   2.3.1-11
pn  cups-pdf                                   <none>
pn  foomatic-db-compressed-ppds | foomatic-db  <none>
ii  smbclient                                  2:4.11.5+dfsg-1
ii  udev                                       244.3-1

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

--- End Message ---
--- Begin Message --- 
Version: 3.20.2+dfsg0-3

Hi,

according to the discussion, this bug is a duplicate of #953104, which was fixed in version 3.20.2+dfsg0-3.

So I am manually closing this bug now.

Best regards,
Thorsten

--- End Message ---
Reply to: