Your message dated Tue, 28 Feb 2023 17:52:23 +0000 (UTC) with message-id <[email protected]> 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 [email protected] immediately.) -- 953419: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953419 Debian Bug Tracking System Contact [email protected] 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 ---
