Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies
On 31/03/2024 22:23, Paul Szabo wrote: (Sadly, my other issues were "declined" upstream. Maybe they know what they are doing...) Where did you report them? Till
Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies
On 30/03/2024 23:19, Paul Szabo wrote: Most issues now reported upstream: https://github.com/OpenPrinting/cups/issues/917 https://github.com/OpenPrinting/cups/issues/918 https://github.com/OpenPrinting/cups/issues/919 The issue with pdftopdf not reported upstream, because I could not find the corresponding "current" source. Cheers, Paul The current source of pdftopdf is libcupsfilters: https://github.com/OpenPrinting/libcupsfilters/issues Till
Bug#1050359: RM: gpr -- RoQA; dead upstream; depends on gtk2
gpr is not only not upstream-maintained any more and depending oon the obsolete GTK2, it is also only used for printing with LPD/gnulpr/LPRng, all these being printing systems which are obsolete for near 2 decades (replaced by CUPS) and all not maintained upstream any more. So it does not actually make sense any more to keep gpr in Debian. So I am in favor of its removal, too.
Bug#1039983: Color Laser-Printer does only print in greyscale after upgrade to Debian 12
Probably you are hitting this bug https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1971242 The bug is fixed upstream in CUPS 2.4.3 and later and I have created 2 Stable Release Updates (SRUs) for Ubuntu Jammy (CUPS 2.4.1) and Lunar (CUPS 2.4.2). So you could try these fixes and they could perhaps also get applied to Debian.
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
On 27/06/2022 19:26, Gareth Evans wrote: "testq" already exists, so I changed the queue name to avoid any potential caching effects etc in case that were possible. $ sudo lpadmin -p testqq -v ipp://192.168.0.14/ipp/print -E -m driverless:ipp://192.168.0.14/ipp/print lpadmin: Printer drivers are deprecated and will stop working in a future version of CUPS. lpadmin: Unable to open PPD "/tmp/075ef62bac756": Missing PPD-Adobe-4.x header on line 0. That's the first time I've seen this error message. Seems that it is able to access the printer for sending a job to it (done as user "lp"?) but not to poll the printer's capabilities via IPP (when running the "lpadmin" command).
Bug#1013437: cups: Nothing prints from driverless IPP queues unless added via lpadmin
And are you able to print now? Till On 27/06/2022 17:57, Gareth Evans wrote: However that is when the laptop is connected to 5GHz wifi. If I change to the 2.5GHz connection (same router) on which (router and frequency) the printer is connected: $ avahi-browse -rt _ipp._tcp + wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer local = wlp1s0 IPv4 Brother MFC-L2740DW seriesInternet Printer local hostname = [mfcl2740dw.local] address = [192.168.0.14] port = [631] txt = ["print_wfds=T" "UUID=e3248000-80ce-11db-8000-30055ca3d8ec" "PaperMax=legal-A4" "kind=document,envelope,label" "URF=W8,CP1,IS4-1,MT1-3-4-5-8,OB10,PQ4,RS200-300-600,V1.3,DM1" "rfo=ipp/faxout" "TBCP=F" "Transparent=T" "Binary=T" "PaperCustom=T" "Scan=T" "Fax=T" "Duplex=T" "Copies=T" "Color=F" "usb_CMD=PJL,PCL,PCLXL,URF" "usb_MDL=MFC-L2740DW series" "usb_MFG=Brother" "priority=25" "adminurl=http://mfcl2740dw.local./net/net/airprint.html; "product=(Brother MFC-L2740DW series)" "ty=Brother MFC-L2740DW series" "note=" "rp=ipp/print" "pdl=application/octet-stream,image/urf,image/pwg-raster" "qtotal=1" "txtvers=1"] $ avahi-browse -rt _uscan._tcp $
Bug#908451: Improved Patch
Tags: Patch
I've improved the submitted patch by André by making it respect the
relevant multistrap setting.
--
Till Robin Zickel | Software Developer
t.zic...@trenz-electronic.de | http://www.trenz-electronic.de
Tel.: 05741 3200-800 (Deutschland) | Phone: +49 5741 3200-800
(International)
--- /usr/sbin/multistrap2022-06-24 08:38:14.404919035 +
+++ /tmp/multistrap 2022-06-24 08:51:19.321226204 +
@@ -319,6 +319,8 @@
$config_str .= " -o Dir::Etc::Trusted=" .
shellescape("${dir}${etcdir}trusted.gpg");
$config_str .= " -o Apt::Get::AllowUnauthenticated=true"
if (defined $noauth);
+$config_str .= " -o Acquire::AllowInsecureRepositories=yes"
+ if (defined $noauth);
$config_str .= " -o Apt::Get::Download-Only=true";
$config_str .= " -o Apt::Install-Recommends=false"
if (not defined $allow_recommends);
OpenPGP_0xF7F2A525B869D387.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1008997: cups: impossible to print on hp envy 5536 from sid
Now run the command driverless and, if you get the URI, run lpadmin -p envy -E -v ipp://localhost:6/ipp/print -m everywhere Does it work now? Till On 06/04/2022 11:28, alain wrote: Package: cups Version: 2.4.1op1-2 Followup-For: Bug #1008997 X-Debbugs-Cc: compte.perso.de-al...@bbox.fr alain@sid:~$ sudo dpkg -l ipp-usb Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder | État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi- installé/W=attend-traitement-déclenchements |/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais) ||/ NomVersion Architecture Description +++-==---=== ii ipp-usb0.9.20-1 amd64Daemon for IPP over USB printer support alain@sid:~$ sudo systemctl status ipp-usb ● ipp-usb.service - Daemon for IPP over USB printer support Loaded: loaded (/lib/systemd/system/ipp-usb.service; static) Active: active (running) since Wed 2022-04-06 11:18:17 CEST; 7min ago Docs: man:ipp-usb(8) Main PID: 66418 (ipp-usb) Tasks: 11 (limit: 38313) Memory: 15.5M CPU: 52ms CGroup: /system.slice/ipp-usb.service └─66418 /sbin/ipp-usb udev avril 06 11:18:17 sid systemd[1]: Started Daemon for IPP over USB printer support. alain@sid:~$ lsusb Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 004: ID 1b1c:1b2e Corsair Corsair Corsair Gaming M65 Pro RGB Mouse Bus 005 Device 003: ID 1b1c:1b3d Corsair Corsair Corsair Gaming K55 RGB Keyboard Bus 005 Device 002: ID 03f0:e807 HP, Inc HP Webcam HD 4310 Bus 005 Device 006: ID 03f0:c311 HP, Inc ENVY 5530 series Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 002: ID 0b05:18f3 ASUSTek Computer, Inc. AURA LED Controller Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0951:16a4 Kingston Technology HyperX 7.1 Audio Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (100, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-6-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups depends on: ii cups-client2.4.1op1-2 ii cups-common2.4.1op1-2 ii cups-core-drivers 2.4.1op1-2 ii cups-daemon2.4.1op1-2 ii cups-filters 1.28.13-1 ii cups-ppdc 2.4.1op1-2 ii cups-server-common 2.4.1op1-2 ii debconf [debconf-2.0] 1.5.79 ii ghostscript9.56.0~dfsg-1 ii libavahi-client3 0.8-5 ii libavahi-common3 0.8-5 ii libc6 2.33-7 ii libcups2 2.4.1op1-2 ii libgcc-s1 12-20220319-1 ii libstdc++6 12-20220319-1 ii libusb-1.0-0 2:1.0.25-1 ii poppler-utils 22.02.0-3 ii procps 2:3.3.17-7+b1 Versions of packages cups recommends: ii avahi-daemon 0.8-5 ii colord1.4.6-1 Versions of packages cups suggests: ii cups-bsd 2.4.1op1-2 pn cups-pdf pn foomatic-db-compressed-ppds | foomatic-db pn smbclient ii udev 250.4-1 -- debconf information: cupsys/raw-print: true cupsys/backend: lpd, socket, usb, snmp, dnssd
Bug#1008997: further information
First step is to go to http://www.openprinting.org/ There you scroll down and find a link to the "Driverless Printers" list. Click "Browse". You get onto https://openprinting.github.io/printers/ into the search field enter "Envy 553". The last digit does not matter. Different last digits usually only mean different power plugs for the different destination countries. So your printer supports AirPrint, one of the driverless IPP standards. Your printer's Wi-Fi is flaky, so use IPP-over-USB. Keep the printer connected to USB and install the "ipp-usb" package. Having done this your printer should appear already in the print dialogs of many applications. If not, create a driverless print queue: First, run driverless You will get an URI for your printer, most probably ipp://localhost:6/ipp/print Create a driverless queue with this URI: lpadmin -p envy -E -v ipp://localhost:6/ipp/print -m everywhere Now all your apps should show your printer with queue name "envy". Can you print on this queue? Till P. S.: Avoid HPLIP if you do not REALLY need it.
Bug#1008175: #1008175
The log message "Unable to do two-sided printing" comes from the "ipp"
CUPS backend, part of CUPS. It seems that the backend does not find the
"sides" attribute in the printer's IPP attributes.
See the code here:
--
if (ipp_status == IPP_STATUS_OK_IGNORED_OR_SUBSTITUTED ||
ipp_status == IPP_STATUS
_OK_CONFLICTING)
{
/*
* One or more options are not supported...
*/
if (ippFindAttribute(response, "sides", IPP_TAG_ZERO))
{
/*
* The sides value is not supported, revert to one-sided as
needed...
*/
const char *sides = cupsGetOption("sides", num_options, options);
if (!sides || !strncmp(sides, "two-sided-", 10))
{
fputs("DEBUG: Unable to do two-sided printing, setting sides
to 'one-sided'.\n", stderr);
num_options = cupsAddOption("sides", "one-sided",
num_options, );
}
}
--
Bug#1006892: cups-browsed: Local queues are not created for discovered printers
Probably cause by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006853 Till
Bug#1006794: mcomix: Package new upstream version 2.0.0
Package: mcomix Version: 1.2.1mcomix3+git20200206-1 Severity: wishlist Tags: upstream X-Debbugs-Cc: pietiplat...@gmail.com Moin Moing, mcomix 2.0.0 was released on 2022-01-29, making mcomix3 obsolete, please consider packaging it. Ciao, Fabio -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/16 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mcomix depends on: ii gir1.2-gtk-3.03.24.31-1 ii python3 3.9.8-1 ii python3-cairo 1.20.1-3 ii python3-gi3.42.0-3 ii python3-gi-cairo 3.42.0-3 ii python3-pil 9.0.0-1 Versions of packages mcomix recommends: ii python3-chardet 4.0.0-1 Versions of packages mcomix suggests: ii mupdf-tools 1.19.0+ds1-2 ii p7zip16.02+dfsg-8 ii unrar1:6.1.5-1 -- no debconf information
Bug#990210: fixed in cups-pdf 3.0.1-12
Sorry, I had overlooked the link in the very first post.
Also thanks for the patch which shows how cups-filters (most probably
pstops) massages the file.
The file has actually 993 pages:
$ gs -q -dBATCH -dNOPAUSE -sDEVICE=bbox all.ps 2>&1 | grep
%%BoundingBox: | wc -l
993
or simply display it with
gs all.ps
(and press Enter 993 times).
evince also shows only the 422 pages which your PostScript viewer shows
to you.
The file has strange internal page numbering:
$ grep -i '%%Page: ' all.ps | wc -l
993
$ grep -i '%%Page: ' all.ps
It redefines "showpage" (the PostScript function to display/print a page
when completed rendering it:
$ grep showpage all.ps | wc -l
1
$ grep showpage all.ps
/p{pop showpage pagesave restore /pagesave save def}def
This makes a single "p" displaying/printing the page.
So let us search for those "p"s:
$ grep ' p$' all.ps | wc -l
993
So Ghostscript (or the print process) outputting 993 pages seems correct
to me, and I do not understand why evince and also your PostScript
viewer only output 422 pages. Perhaps they consider duplicate page
numbers as duplicate pages and skip them.
First numbers in "%%Page:" lines:
$ grep -i '%%Page: ' all.ps | cut -d ' ' -f 2 | sort | uniq | wc -l
422
Second numbers in "%%Page:" lines:
$ grep -i '%%Page: ' all.ps | cut -d ' ' -f 3 | sort | uniq | wc -l
422
The changes coming from cups-filters/the pstops filter mainly only
change the DSC comments, letting the second number in the "%%Page:"
lines going from 1 to 993 instead of being the same as the first number,
starting from 1 again and again. This seems to make the viewers
accepting all pages.
I hope this gives some insight.
On 01/10/2021 13:11, Andre Heider wrote:
Hi Till,
On 01/10/2021 12:32, Till Kamppeter wrote:
Andre, could you attach your PostScript file, once the original and
also the one you get after pre-processing when using "GSCall echo %s
%s %s;
cp %s /tmp"? Thanks.
attached a patch for the original .ps file, see the first post for a link.
But maybe that patch already hints at the problem?
Cheers,
Andre
Bug#990210: fixed in cups-pdf 3.0.1-12
Andre, could you attach your PostScript file, once the original and also the one you get after pre-processing when using "GSCall echo %s %s %s; cp %s /tmp"? Thanks. -- On 28/09/2021 14:20, Andre Heider wrote: Indeed, still only getting an empty pdf on that file too. That's another problem than the empty pdf files I was seeing before. That issue prevented cups-pdf to produce non-empty files at all, no matter what the input was. Even the cups test page failed. Now it seems specific to this file. My pdf viewer atril claims the original ps has 422 pages. If I fix it up with `ps2ps all.ps all2.ps` the new file reports 993 pages, atril even shows another first page... And printing that with `lp -dPDF all2.ps` works just fine. The error handling from cups-pdf sure is funky here. Cheers, Andre -- On 29/09/2021 09:11, Andre Heider wrote: Did some more digging since I reused this bug because I thought it's the same issue... If you set the GSCall config to the default value but append "1>/tmp/gs.out 2>&1" you can see an error in that file: --- 8< --- Error: /nocurrentpoint in --currentpoint-- Operand stack: (--) 80 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1990 1 3 %oparray_pop 1989 1 3 %oparray_pop 1977 1 3 %oparray_pop 1833 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- Dictionary stack: --dict:736/1123(ro)(G)-- --dict:0/20(G)-- --dict:89/200(L)-- --dict:63/140(L)-- Current allocation mode is local Current file position is 10444 GPL Ghostscript 9.54.0: Unrecoverable error, exit code 1 --- 8< --- The reason it fails with lp but succeeds with the manual gs cmdline is that cups preprocesses the input file. If you use "GSCall echo %s %s %s; cp %s /tmp" it'll copy the actual file used for cups-pdf to /tmp, for which you then get the same error if you manually use the gs cmdline on it. I don't know enough about the printing stack/postscript to tell if that's fixable, but it all sounds like a corrupt ps file to me.
Bug#985989: nextcloud-desktop: segmentation fault when trying to open settings
Package: nextcloud-desktop Version: 3.1.1-1 Severity: important X-Debbugs-Cc: till2...@protonmail.com Dear Maintainers, When I try to access the settings of the nextcloud desktop client, it crashes. What I did: 1. run nextcloud 2. right-click on nextcloud tray icon, then click 'Settings' OR click tray icon, then click account name (top left), then click 'Settings' Result: - the client crashes instantly. When running from terminal, "Segmentation fault" is returned. This happens every time. Expectation: - don't crash, open settings window -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-security'), (10, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nextcloud-desktop depends on: ii libc6 2.31-10 ii libcloudproviders0 0.3.0-3 ii libgcc-s1 10.2.1-6 ii libglib2.0-0 2.66.7-2 ii libnextcloudsync0 3.1.1-1 ii libqt5core5a 5.15.2+dfsg-5 ii libqt5dbus55.15.2+dfsg-5 ii libqt5gui5 5.15.2+dfsg-5 ii libqt5keychain10.10.0-1 ii libqt5network5 5.15.2+dfsg-5 ii libqt5qml5 5.15.2+dfsg-5 ii libqt5quick5 5.15.2+dfsg-5 ii libqt5quickcontrols2-5 5.15.2+dfsg-2 ii libqt5sql5-sqlite 5.15.2+dfsg-5 ii libqt5svg5 5.15.2-2 ii libqt5webenginecore5 5.15.2+dfsg-3 ii libqt5webenginewidgets55.15.2+dfsg-3 ii libqt5webkit5 5.212.0~alpha4-11 ii libqt5widgets5 5.15.2+dfsg-5 ii libstdc++6 10.2.1-6 ii nextcloud-desktop-common 3.1.1-1 ii nextcloud-desktop-l10n 3.1.1-1 ii qml-module-qtgraphicaleffects 5.15.2-2 ii qml-module-qtqml-models2 5.15.2+dfsg-5 ii qml-module-qtquick-controls2 5.15.2+dfsg-2 ii qml-module-qtquick-layouts 5.15.2+dfsg-5 ii qml-module-qtquick-window2 5.15.2+dfsg-5 ii qml-module-qtquick25.15.2+dfsg-5 Versions of packages nextcloud-desktop recommends: ii nextcloud-desktop-doc 3.1.1-1 nextcloud-desktop suggests no packages. -- no debconf information
Bug#983474: ipp-usb: breaks scanning with HP Deskjet 5275
Updating SANE (libsane1, sane-backends) from 1.0.31 to 1.0.32 could perhaps fix the scanning with installed ipp-usb and the "escl" backend. 1.0.32 (released upstream a few weeks ago) has a lot of fixes and improvements on the "escl" backend. You could install sane-airscan. This is an extra SANE backend which provides more sophisticated support for driverless scanning (scanning with ipp-usb, "IPP over USB" always uses driverless scanning and printing standards). Classic drivers (as HPLIP's "hpaio" work only without ipp-usb. Till On 24/02/2021 20:47, Tzafrir Cohen wrote: Package: ipp-usb Version: 0.9.17-1 Severity: normal Dear Maintainer, I recenty realised I cannot scan with my scanner (part of a multi-function printer/scanner HP Deskjet 5275). Disabling ipp-usb enabled scanning. With ipp-usb running: $ time scanimage -L device `escl:http://127.0.0.1:6' is a HP DeskJet 5200 series [FC8002] (USB) flatbed scanner device `hpaio:/usb/DeskJet_5200_series?serial=TH8A86C27C' is a Hewlett-Packard DeskJet_5200_series all-in-one real0m7.483s user0m0.102s sys 0m0.087s $ time scanimage -x 100 -y 100 --format=tiff >image.tiff scanimage: open of device escl:http://127.0.0.1:6 failed: Out of memory real0m7.511s user0m0.117s sys 0m0.109s $ time scanimage --device 'hpaio:/usb/DeskJet_5200_series?serial=TH8A86C27C' -x 100 -y 100 --format=tiff >image.tiff scanimage: open of device hpaio:/usb/DeskJet_5200_series?serial=TH8A86C27C failed: Error during device I/O real0m0.051s user0m0.037s sys 0m0.013s With ipp-usb stopped: $ time scanimage -L device `hpaio:/usb/DeskJet_5200_series?serial=TH8A86C27C' is a Hewlett-Packard DeskJet_5200_series all-in-one real0m7.528s user0m0.139s sys 0m0.103s $ time scanimage -x 100 -y 100 --format=tiff >image.tiff real0m9.892s user0m0.165s sys 0m0.105s $ identify image.tiff image.tiff TIFF 295x295 295x295+0+0 1-bit Bilevel Gray 11125B 0.000u 0:00.000 $ dpkg-query -W sane-utils libsane1 libsane1:amd64 1.0.31-4 sane-utils 1.0.31-4 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=en_IL, LC_CTYPE=en_IL (charmap=UTF-8), LANGUAGE=en_IL:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ipp-usb depends on: ii avahi-daemon 0.8-5 ii libavahi-client3 0.8-5 ii libavahi-common3 0.8-5 ii libc6 2.31-9 ii libusb-1.0-0 2:1.0.24-2 ipp-usb recommends no packages. ipp-usb suggests no packages. -- no debconf information
Bug#983349: hplip: while scanning , error 9 : impossible to scan
On 23/02/2021 13:17, Brian Potkin wrote: escl is capable of working with ipp-usb but does not. This seems to be a bug in SANE's libsane-escl, so I am reassigning your report to libsane1. Note that the "escl" backend got improved a lot in sane-backends 1.0.32 which got released recently. I have already packaged it for Ubuntu Hirsute (21.04). I think I had this backend already used with IPP-over-USB. If it does not actively block IPP-over-USB in newer versions it can still be that sane-airscan simply has more quirk exceptions to make IPP-over-USB work on more scanner models. Till
Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)
OK, no I understand, fresh installation or live ISO all works perfectly as intended, old installation shows the problem, so further investigations only on the old installation ... Till
Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)
On 15/02/2021 14:27, mh wrote: I then investigated the LIVE-ISO. To my surprise ipp-usb is installed within the LIVE-ISO. ipp-usb is part of the standard installation in Debian and Ubuntu, to support printers which do driverless IPP printing. Standard-conforming printers should work out-of-the-box with that. All the commands which failed/did have an empty output on my default system work here with the expected output (I guess), except for # avahi-browse -rt _ipp._tcp due to avahi-browse not being installed: # /usr/lib/cups/backend/usb DEBUG: Loading USB quirks from "/usr/share/cups/usb". DEBUG: Loaded 98 quirks. DEBUG: list_devices DEBUG: libusb_get_device_list=9 DEBUG: Failed to detach "usblp" module from 06bc:0357 The "usb" backend probably simply encounters your printer's USB occupied by some process here, not knowing that it is actually ipp-usb and not the "usblp" kernel module. The method for getting rid of the kernel module seems no to remove the connection of ipp-usb. # systemctl list-units "ipp-usb*" | grep service ipp-usb.service loaded active running Daemon for IPP over USB printer support # lpstat -t Zeitplandienst läuft Keine systemvoreingestellten Ziele Gerät für OKI_DATA_CORP_B432: ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/ OKI_DATA_CORP_B432 akzeptiert Anfragen seit Mo 15 Feb 2021 12:45:49 CET Drucker OKI_DATA_CORP_B432 ist im Leerlauf. Aktiviert seit Mo 15 Feb 2021 12:45:49 CET # lpstat -l -e OKI_B432_010E46_USB_ network none ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/ OKI_DATA_CORP_B432 permanent ipp://localhost/printers/OKI_DATA_CORP_B432 ipp://OKI-B432-010E46%20(USB)._ipp._tcp.local/ This looks like that a driverless print queue got created automatically. Could you run these two commands: lp -d OKI_B432_010E46_USB_ ~/.bashrc lp -d OKI_DATA_CORP_B432 ~/.bashrc Do you get something printed? If yes, by the first command? By the second? Both? # avahi-browse -rt _ipp._tcp Command 'avahi-browse' not found, but can be installed with: apt install avahi-utils Install this command by actually doing sudo apt install avahi-utils Then run the command again and post the output here. @ till.kamppeter As much as I'm willing to help, from what I can tell now I assume there is not much to debug *direktly* related to the printer. Tell me if you think otherwise. If the printer is capable of driverless printing via an auto-generated all is OK. But if it is not capable of that but pretends to be capable then somewhere is a bug, in our software or in the printer, in the latter case we caould perhaps work around in our software. BTW (not related the this malfunction): There are already some OKI PPD files available in the cups config, including the PPD file for the preceding model. What do you mean with this? Is there a PPD for your printer included in Debian or Ubuntu? Or did you download it directly from Oki? Could I do anything to help to include the appropriate vendor PPD file for my printer (freely availabe on their webite) in the printer-driver-oki package (or whichever package is the rightone)? If the PPDs are under a free software license we can add them to OpenPrinting (and this way to all distributions and also the PostScript Printer Application). Till
Bug#982742: cups: config of usb printer now impossible due to usblp and libusb conficting (used to work!)
Alexander, on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982742 Michael Hatzold (CCed) reports a problem with ipp-usb. The printer provides a 7/1/4 interface on USB, meaning that it supports IPP-over-USB and with this, according to the standards, driverless printing (and scanning if it is a MFP). This particular model seems to have some bug though. Due to it providing 7/1/4 ipp-usb attaches to it but it does not provide driverless IPP printing then. As this can possibly be a bug in ipp-usb or the need of a quirk exception in ipp-usb, I want to ask you whether you could debug this together with Michael as you also had made my scanner work together with me. Thanks in advance. Till On 15/02/2021 11:26, Brian Potkin wrote: On Sun 14 Feb 2021 at 20:31:28 +0100, mh wrote: [...] # ippfind -T 5 ~# An IPP printer is not found. This would fit the observation that cups-browsed has not set up a print queue. I have come to the conclusion that the B432 does not implement IPP-over-USB correctly. A queue set up with a vendor PPD will not function while ipp-usb is active, so purge it and proceed as you did with the Live ISO. Also see #982190: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982190 Cheers, Brian.
Bug#980973: Cups attempts to probe, configure unsupported Canon USB printers
Please report this to CUPS upstream at https://github.com/OpenPrinting/cups Note trhat CUPS is not maintained at Apple any more but at OpenPrinting now. We need the USB IDs (VID/PID) of all affected devices, at least of as many devices as possible. Till On 24/01/2021 23:46, Chris Bainbridge wrote: Package: cups Version: 2.3.3op1-7 Cups does not support Canon CAPT USB printers (this requires a proprietary driver which uses /dev/usb/lp0), but these printers are not blacklisted, so when one is plugged in, cups sets up a new, non-functional printer, and probes the USB device, the kernel logs as a USB disconnect, and disrupts operation of the Canon driver. Running lpstat also seems to do some probe and cause a USB device disconnect. The kernel logs: Jan 23 23:45:29 debian kernel: usblp0: removed It appears the fix would be to add CAPT printers to /usr/share/cups/usb/org.cups.usb-quirks as so: # Canon, Inc. LBP3010/LBP3018/LBP3050 Printer 0x04a9 0x26da blacklist etc.
Bug#979177: cups-filters-core-drivers: Adding a printer impossible because "driverless" is too slow
I have released cups-filters 1.28.7 with the fix now. https://github.com/OpenPrinting/cups-filters/releases/tag/1.28.7
Bug#979177: cups-filters-core-drivers: Adding a printer impossible because "driverless" is too slow
I have investigated the problem further and the problem is caused by "driverless" sending get-printer-attributes IPP requests to each printer it lists, to check the quality of driverless printing support. See https://github.com/OpenPrinting/cups-filters/pull/235 This makes "driverless" taking too long time, especially if there are many printers. See the investigations on https://github.com/OpenPrinting/cups/issues/65 Therefore I have removed the feature again now, on both master and 1.x branches of cups-filters: https://github.com/OpenPrinting/cups-filters/commit/3fddcf5 https://github.com/OpenPrinting/cups-filters/commit/aae86d2 Please test, this should solve your problem. I will release cups-filter 1.28.7 soon, with this change included.
Bug#979177: cups-filters-core-drivers: Adding a printer impossible because "driverless" is too slow
The problem also got reported upstream: https://github.com/OpenPrinting/cups/issues/65 Could you also see the discussion there and try what got suggested there? I by myself am not able to reproduce it, so I need someone who can reproduce it to find out under which conditions it happens. Till
Bug#964446: sane-airscan stuck in NEW
Great, so I will base my Ubuntu package also on the new version. OdyX, could you update the Debian packaging appropriately, too? Thanks. Till On 04/08/2020 20:10, Alexander Pevzner wrote: I think I will merge -unstable in few hours and will release result as 0.99.12. It would be nice, if Debian will synchronize with .12, not .11 (otherwise we will wait a couple of month before next chance to synchronize). As .12 drops dependency on libsoup and libglib, and adds dependency on gnutls, it will require packaging to be tweaked a little bit.
Bug#964446: sane-airscan stuck in NEW
sane-airscan got uploaded something like 3 weeks ago and is still stuck in NEW. What is happening? What is missing? OdyX, as I like to add sane-airscan to Ubuntu 20.10 and it will most probably not get into unstable in time before Ubuntu's Feature Freeze on August 27, I would like to ask you whether you could send me the source files of your package (current version, 9.99.10-1, tarball, dsc, debian.tar.gz) and/or tell me whether there is a GIT repo for the packaging. Thanks in advance. Till
Bug#965144: ipp-usb replaces ippusbxd; remove?
On 17/07/2020 12:54, Brian Potkin wrote:> I am very much attracted by the idea of a USB connected printer becoming immediately available when it is plugged in, so a Recommends: ipp-usb would be ok with me. Yes, I would very much like this, too, for Ubuntu into which both CUPS and ipp-usb get synced. However, it is as well to be aware that there is a difference in user experience compared to the situation when driverless printing was fully introduced on buster. In the later case, a user who pressed on with the installation of vendor drivers was generally successful in getting to use them with a wireless or ethernet connection. With ipp-usb, on the other hand, printing and scanning can only take place through IPP-over-USB (AFAIK). Users who expect their previous setup methods to work will probably be due a disappointment. We must make users aware of the changes: Most modern printers do not need any more printer drivers specific to manufacturer and model of the printer. They use standard protocols for both printing and scanning, we have here the so-called driverless IPP Printing/Scanning. If it is told that a printer supports AirPrint/AirScan, Mopria, Wi-Fi Direct Print, or IPP Everywhere it is such a printer and if it has a scanner built in, the scanner is also covered and does not need a specific driver. Even fax sending is supported via command line, but the desktop applications do not support this yet. This works both via network connection and via USB. In case of USB a netwwork printer gets emulated on the local machine, on port 6 (and following ports if more than one device is connected). - An existing print queue for a USB printer can cease to work. Such a queue should get removed. - Most probably another queue got already created automatically. This queue should work. - If no queue gets generated, even not after re-plugging the printer, to create a print queue check for detected/discovered printers in the web interface of CUPS or in system-config-printers, always under network printers, even if your device is on USB. Under the model/driver entries look for entries containing "driverless" or "IPP Everywhere". - One can easily rename print queues with system-config-printer, should one want to continue with the old queue's name. - For scanning, select in your scan software an entry which contains "eSCL" or "AirScan". If your device is on USB, the entry which you used previously will not work any more (and perhaps not even appear). If you do not get asked for which scanner to select and the software simply does not work, look for a function to change your scanner in the menus. I believe scanning to be possible only with sane-escl and sane-airscan. sane-escl is not yet in unstable to test. sane-escl is built-in in the sane-backends package from version 1.0.29 on, so it is most probably available. But it is highly recommended to use sane-airscan instead, as the former does not support the ADF on the scanners and does not support WSD, only eSCL. Also all further development is concentrated on sane-airscan now. sane-airscan supports the eSCL and WSD protocols and will soon get IPP Scan added. sane-airscan got already packaged for Debian, it is currently in the NEW queue. Recommends: ipp-usb | ippusbxd is an option that does not seem to benefit a Debian user. ippusbxd is supported upstream but there may be plans for its future we are unaware of. I'm a little unsure about its removal from unstable, but, overall, there does not appear to a glaring downside to it. It would simplify the rewriting of the relevant sections of the wiki if only one daemon was available. :) ippusbxd is still supported upstream on OpenPrinting, but due to the fact that ipp-usb works much better, I highly recommend that - CUPS gets "Recommends: ipp-usb" - ipp-usb and ippusbxd get a mechanism that only one gets installed at a time and the "Recommends: ipp-usb" in CUPS triggers a switch-over to ipp-usb. - Leave ippusbxd in the distro, for experimental, IoT, ... purposes. There are contributors who are working on improving it. I do not actively working on it by myself. Most probably it will get made working well some day because of Chrome OS. Till
Bug#964446: RFP: sane-airscan - SANE backend for AirScan (eSCL) and WSD document scanners
On 07/07/2020 22:25, Didier 'OdyX' Raboud wrote: For the record, I am primarily concerned about the printing support in Debian, which packaging I carry mostly alone (I get great help from Brian Potkin for bug triaging, and Till Kamppeter for upstream and Ubuntu support). I don't really intend to also start carrying the scanning stack on my shoulders too. (While I state this, I also know that I might end up taking on this packaging, just don't wait on me if you're interested!) Thank you for having a look into this. This is not a regular scanner driver but it is a driver which gives support for the scanning parts of practically all modern printer/scanner multi-function devices. And with the soon to be added IPP Scan support an important part of the new IPP-based printing/scanning architecture which is currently under development. Therefore it is especially interesting to have this package maintained by the Debian Printing Team. OdyX, I will not ask you to package arbitrary scanner drivers or SANE itself. WDYT? Till
Bug#964446: RFP: sane-airscan - SANE backend for AirScan (eSCL) and WSD document scanners
Package: wnpp Severity: wishlist * Package name: sane-airscan Version : 0.99.8 Upstream Author : Alexander Pevzner * URL : https://github.com/alexpevzner/sane-airscan * License : GPL-2+ with sane exception (same as sane-backends) Programming Lang: C Description : SANE backend for AirScan (eSCL) and WSD document scanners sane-airscan is a SANE backend (scanner driver) for two manufacturer-neutral, standardized communication protocols (AirScan/eSCL and WSD) which are used by the scanners in most modern printer/scanner multi-function devices and so used by thousands of scanners. . Similar to modern printers (especially the printing parts of the mentioned multi-function devices) using standard protocols and so printing driverless (driver = hardware-model-specific software or data) we are also scanning driverless with this backend using the standard scanning protocols of the multi-function devices. . In the near future even a third standard protocol, IPP Scan of the Printer Working Group (www.pwg.org) will be added. . This all work not only with network-connected devices which advertise themselves via DNS-SD but also with USB devices using IPP-over-USB (with the ipp-usb software, RFP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961218, only needed for USB access, not required for network access) From the original README.md: -- Similar to how most modern network printers support "driverless" printing, using the universal vendor-neutral printing protocol, many modern network scanners and MFPs support "driverless" scanning. Driverless scanning comes in two flavors: Apple AirScan or AirPrint scanning (official protocol name is eSCL) Microsoft WSD, or WS-Scan (term WSD means "Web Services for Devices) This backend implements both protocols, choosing automatically between them. It was successfully tested with many devices from Brother, Canon, Kyocera, Lexmark, Epson, HP, Ricoh, Samsung and Xerox both in WSD and eSCL modes. For eSCL devices, Apple maintains a comprehensive list of compatible devices, but please note, this list contains not only scanners and MFP, but pure printers as well. This backend doesn't require to install and doesn't conflict with vendor-provided proprietary software like ScanGear from Canon, HPLIP from HP and so on. -- sane-airscan is a standard SANE backend and makes all eSCL- and WSD-based scanners immediately available to all SANE-based frontends, like simple-scan, X-SANE, ... It also supports the full functionality of the scanners, especially the ADF (Automatic Document Feeder) which is not supported by the "escl" backend in SANE 1.0.29 and newer. There are also some devices which support only WSD and not eSCL which are therefiore supported only by this backend and not by "escl". As eSCL and WSD is supported by the same backend devices with both eSCL and WSD support get only listed once in SANE frontends (most modern MF devices support both protocols). It is tested already by many users on many devices (see the list in the README.md file). Alexander Pevzner, author of the backend (and of ipp-usb) answers to bug reports (GutHub issues) quickly and works closely together with the user to fix the bug. In addition, the backend is under active development, IPP Scan is planned to be added by end of September. Alexander is also generating and publishing binary packages for all major Linux distributions via the OpenSUSE Build Service. The files for the Debian package, to be found here https://build.opensuse.org/package/show/home:pzz/sane-airscan could be a start for creating a .deb package of sane-airscan. It would be great to have sane-airscan as standard part of Debian, to make thousands of scanners just work. As it will get also synced into Ubuntu I will stay in collaboration with the potential packager/Debian maintainer of it as will be the Debian Printing group. Till
Bug#961218: ipp-usb Packaging some more remarks
[ CCed debian-printing and Alexander Pevzner ] Hi, I have worked a lot with Alexander Pevzner on making ipp-usb what it is now and I also have succeeded to get localhost support into Avahi. Most was already told in the initial report, but I have some additional remarks: - IPP-over-USB is a very important standard to allow printing and scanning without hardware-model-specific drivers when the device is connected via USB. There is no way for driverless USB access to such devices without using IPP-over-USB, Practically all modern printer/scanner-multi-function devices support driverless IPP operation including IPP-over-USB. This way we get thousands of printers and scanners (and even sending fax) working, without needing to develop drivers. ipp-usb is currently the only way to get this working reliably. - The upstream source repository https://github.com/OpenPrinting/ipp-usb (Note: it has moved to OpenPrinting) contains also the debian packaging in its debian/ subdiectory, so packaging for Debian probably needs only some simple corrections. The work load needed is very low. Also maintaining would be easy as Alexander would probably help. - I also want to introduce ipp-usb in Ubuntu, in 20.10 (Groovy Gorilla) which has Feature Freeze Aug 27. It would be great if I could sync from Debian. No one interested? OdyX, could you package/upload it? Till
Bug#961458: ippusbxd: Please consider installing a systemd service file by default
I have done this already for Ubuntu in the 1.34-2ubuntu1 package. "dpkg -L ippusbxd" gives the following 4 non-documentation files in the package: /. /etc /etc/apparmor.d /etc/apparmor.d/usr.sbin.ippusbxd /lib /lib/systemd /lib/systemd/system /lib/systemd/system/ippusbxd@.service /lib/udev /lib/udev/rules.d /lib/udev/rules.d/55-ippusbxd.rules /usr /usr/sbin /usr/sbin/ippusbxd With this USB printers supporting IPP-over-USB will get their ippusbxd started when plugged in. And as ALL IPP-over-USB support driverless printing (and scanning if they have a scanner) you can easily print and scan via the emulated IPP device. Note that for scanning you need SANE 1.0.29 or sane-airscan, and for auto-discovery (independent of whether you want to print or scan) you need Avahi 0.8.0 or newer. You can even fax without driver (at least from the command line) following my simple test described in this GSoC project listing: https://wiki.linuxfoundation.org/gsoc/google-summer-code-2020-openprinting-projects#support_for_ipp_fax_out So you simply need to sync with this Ubuntu package ... Also make sure to overtake the latest changes on system-config-printer from Ubuntu (version 1.5.11-4ubuntu2 or newer, replace 33_ipp-over-usb-support.patch by 33_no-usb-queues-for-ipp-over-usb-printers.patch), so that system-config-printer does not try to start ippusbxd or auto-create print queues for IPP-over-USB-capable printers. Due to not being sure about Debian's system-config-printer I did the ippusbxd change Ubuntu-only, also as it was close before our Feature Freeze for 20.04. Till
Bug#909564: Info received (avahi: Support local-only services via the loopback interface)
Recently Avahi 0.8.0 with my localhost support patch included got released. See https://github.com/lathiat/avahi/releases/tag/v0.8 See also https://bugs.launchpad.net/bugs/1864207 Till
Bug#954885: /dev/bus/usb/*/* device file of printers assigned to "audio" group
Package: libmtp-common
Version: 1.1.17-2
Severity: important
See my original bug report on Ubuntu:
https://bugs.launchpad.net/bugs/1863239
Hi,
When testing HPLIP I found out that CUPS backends can access my printer
only when they are running as root, when they are running as the special
user lp, as it is usually the case, they cannot access the printer.
So I tried to find out why and saw that the /dev/bus/usb/*/* device file
for the printer has group ownership "audio" and not "lp":
till@till-x1yoga:~/ubuntu/hplip/focal/debian/hplip-3.19.12+dfsg0$ ll
/dev/bus/usb/*/*
crw-rw-r-- 1 root root 189, 0 Feb 11 14:17 /dev/bus/usb/001/001
crw-rw-r-- 1 root root 189, 2 Feb 11 14:17 /dev/bus/usb/001/003
crw-rw-r-- 1 root root 189, 3 Feb 11 14:17 /dev/bus/usb/001/004
crw-rw-r-- 1 root plugdev 189, 4 Feb 14 12:23 /dev/bus/usb/001/005
crw-rw-r-- 1 root root 189, 5 Feb 11 14:17 /dev/bus/usb/001/006
crw-rw+ 1 root audio 189, 62 Feb 14 12:37 /dev/bus/usb/001/063
crw-rw-r-- 1 root root 189, 128 Feb 11 14:17 /dev/bus/usb/002/001
crw-rw-r-- 1 root root 189, 130 Feb 13 09:38 /dev/bus/usb/002/003
till@till-x1yoga:~/ubuntu/hplip/focal/debian/hplip-3.19.12+dfsg0$
The printer is the device /dev/bus/usb/001/063:
till@till-x1yoga:~/ubuntu/hplip/focal/debian/hplip-3.19.12+dfsg0$ lsusb
Bus 002 Device 003: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit
Ethernet
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 138a:0097 Validity Sensors, Inc.
Bus 001 Device 004: ID 04f2:b5ce Chicony Electronics Co., Ltd Integrated
Camera
Bus 001 Device 003: ID 8087:0a2b Intel Corp.
Bus 001 Device 006: ID 056a:50b7 Wacom Co., Ltd Pen and multitouch sensor
Bus 001 Device 063: ID 03f0:7a12 HP, Inc HP OfficeJet Pro 8730
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
till@till-x1yoga:~/ubuntu/hplip/focal/debian/hplip-3.19.12+dfsg0$
This turned out to be a bug in the UDEV rules.
The file /lib/udev/rules.d/69-libmtp.rules of the libmtp-common assigns
"audio" group ownership to devices which are supposed to be audio or
video players and allow uploading files to them via USB using the MTP
protocol.
First it includes some devices explicitly and then it lists thousands of
supported devices. In the end there is some rule for passing a wide
range of devices through an auto-probing:
-
# Autoprobe vendor-specific, communication and PTP devices
ENV{ID_MTP_DEVICE}!="1", ENV{MTP_NO_PROBE}!="1",
ENV{COLOR_MEASUREMENT_DEVICE}!="1", ENV{ID_GPHOTO}!="1",
ENV{libsane_matched}!="yes", ATTR{bDeviceClass}=="00|02|06|ef|ff",
PROGRAM="mtp-probe /sys$env{DEVPATH} $attr{busnum} $attr{devnum}",
RESULT=="1", SYMLINK+="libmtp-%k", MODE="660", GROUP="audio",
ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"
-----
And this auto-probing tests positive on my printer:
till@till-x1yoga:~$ /lib/udev/mtp-probe
/sys/devices/pci:00/:00:14.0/usb1/1-1 001 063
1
till@till-x1yoga:~$
Path taken from the output of "sudo udevadm monitor -e", blob with
"ID_MEDIA_PLAYER" in it.
The device path of the printer I have taken from the blob in the udevadm
output (attached to previous comment) which also contains
"ID_MEDIA_PLAYER=1". So mtp-probe identifies my printer as a media
player and assigns the device file to the "audio" group.
I assume that this happens to most or even all HP printers, so an
exclusion of only my device via Vendor and Product ID would not be the
correct solution.
There was already a measure against wrongly identifying HP printers as
media players, but it is a rather dirty workaround which does not work
any more (therefore this bug). The rule in the end of 69-libmtp.rules
checks the absence of the env variable libsane_matched and this variable
is set for all HP printers by HPLIP. First, this rule fails miserably if
HPLIP is not installed, and I cannot imagine that the libmtp package
depends on HPLIP only to identify unsupported devices. Also the libmtp
rules are applied for both "add" and "bind" actions, whereas the rules
of HPLIP (56-hpmud.rules) are only applied for "add" and so the bug
happens on a "bind" action, here the HPLIP rules do not set said env
variable and so the libmtp rules probe the HP printers.
One can theoretically work around this problem by mucking with the UDEV
rules of HPLIP, but this is a REALLY DIRTY workaround, so please DO NOT
add an hplip task to this bug report.
In addition, HPLIP will not be installed by default any more in the not
too far future, as prnting and scanning will get snapped. Also we want
printer driver Snaps (Printer Applications) not to run as root if
possible, so we need to be sure that USB printer device files always
belong to the group "lp" for
Bug#954315: rastertopwg segfault
First, this is definitely a CUPS upstream bug, so please report it on the CUPS GitHub, also supplying all the information which you have gathered and attaching the files which I had asked for. https://github.com/apple/cups/issues/ Probably it can be solved by adding a simple NULL check. At line 273 of rastertopwg.c replace if (pwg_media) strlcpy(outheader.cupsPageSizeName, pwg_media->pwg, sizeof(outheader.cupsPageSizeName)); by if (pwg_media && pwg_media->pwg) strlcpy(outheader.cupsPageSizeName, pwg_media->pwg, sizeof(outheader.cupsPageSizeName)); Please try it if you are familiar with source code and compiling. Tell your result here and also in the upstream bug you are reporting. Till
Bug#954315: rastertopwg segfault
We need a way to reproduce the bug and also a backtrace with line numbers of the source files. So please attach the PDF input file which leads to the crash. Also attach your printer's PPD file, from the /etc/cups/ppd/ directory, named by the name of your print queue. Please also try to reproduce the crash with the "cupsfilter" command: cupsfilter -p /etc/cups/ppd/QUEUE.ppd -i application/pdf -m printer/QUEUE -e FILE.pdf > out Running only a part of the filter chain you can get the data which is fed into rastertopwg: cupsfilter -p /etc/cups/ppd/QUEUE.ppd -i application/pdf -m application/vnd.cups-raster -e FILE.pdf > out.raster Now you can run rastertopwg isolated: ulimit -c unlimited cat out.raster | PPD=/etc/cups/ppd/QUEUE.ppd /usr/lib/cups/filter/rastertopwg 1 1 1 1 "" > out and get a backtrace: gdb -c core /usr/lib/cups/filter/rastertopwg Use the "bt" command at the prompt of gdb. Please post the backtrace here. Till
Bug#946561: hplip: Not installable with python3 >= 3.
This is solved in Ubuntu: https://launchpad.net/ubuntu/+source/hplip/3.19.12+dfsg0-4ubuntu1 You could add the patch for Python 3.8 support to the Debian package. Till
Bug#950669: cups-browsed: segfault at 0 ip 00000000f79ffb5b sp 00000000fffd3828 error 4 in libc-2.29.so
In a very recent commit I have added crash guards to the is_local_hostname() function, which cover also the case of host_name being NULL: https://github.com/OpenPrinting/cups-filters/commit/4157690bf I hope this helps here. But anyway, thanks for the deep analysis of the problem. Till
Bug#951213: Forgotten Build-Depends:
I have forgotten to check the build Build-Depends:. The following need to get added: autoconf-archive, libpng, libcurl4-gnutls-dev, libxml2-dev The first is needed to make the package build at all, the others for the package to build with the newly added backends. Till
Bug#949315: Fixes in CUPS and cups-filters
Hi,
I have found the cause of the printers ignoring the paper tray selection.
The problem is that the paper tray names ("Tray-1", "Tray-2", ...) in
the PPD files got wrongly translated to IPP attribute names ("tray--1",
"tray--2", ... note the double-dash) by the CUPS "ipp" backend when
sending a job off to the printer and also by cupsd when answering a
get-printer-attributes IPP request.
See my CUPS bug report (with patch to fix it):
https://github.com/apple/cups/issues/5740
and also the two issues on cups-filters:
https://github.com/OpenPrinting/cups-filters/issues/193
https://github.com/OpenPrinting/cups-filters/issues/201
I have also added a workaround to cups-filters, so that PPDs generated
by cups-filters do not cause the problem if the above-mentioned CUPS fix
is not applied. Here is the commit:
https://github.com/OpenPrinting/cups-filters/commit/cc1354c11e7bef9725420fb4cb6e707085249e78
As Apple is currently not very active on CUPS, I would kindly ask you to
add the CUPS patch to the Debian package of CUPS.
I will soon make a release of cups-filters with the workaround included,
but note that the workaround only applies to PPDs generated by
cups-filters. PPDs generated by CUPS (temporary queue or "lpadmin ... -m
everywhere") or PPDs from other projects, manufacturers, ... still show
the bug. so the CUPS fix is very important.
Thanks for the bug report and also special thanks to Sambhav for the
investigations on this.
Till
Bug#951313: openprinting-ppds: MemoryError
The problem is discussed here: https://github.com/vitorbaptista/pyppd/issues/2 (Upstream Issue #2 of pyppd) Till
Bug#951062: Please replace the dependency on gsfonts by fonts-urw-base35
Package: python-reportlab Version: 3.5.23-1 Severity: important The binary package python3-renderpm (source: python-reportlab) depends on the gsfonts package and this dependency should be replaced by fonts-urw-base35. The purpose of the gsfonts package is providing the 35 standard PostScript fonts to Ghostscript, so that Ghostscript can render any standards-conforming PostScript file. The gsfonts package got replaced by the fonts-urw-base35 packages. gsfonts is not maintained any more upstream (our package has the last upstream source update in 2007) and the upstream source locations mentioned in debian/copyright do not exist any more. To get rid of the duplication and also of the unmaintained package the dependency in python3-renderpm need to get updated. See also https://bugs.launchpad.net/bugs/1862641 Till
Bug#951063: Please replace the dependency on gsfonts by fonts-urw-base35
Package: libwmf Version: 0.2.8.4-17 Severity: important The binary package libwmf0.2-7 (source: libwmf) depends on the gsfonts package and this dependency should be replaced by fonts-urw-base35. The purpose of the gsfonts package is providing the 35 standard PostScript fonts to Ghostscript, so that Ghostscript can render any standards-conforming PostScript file. The gsfonts package got replaced by the fonts-urw-base35 packages. gsfonts is not maintained any more upstream (our package has the last upstream source update in 2007) and the upstream source locations mentioned in debian/copyright do not exist any more. To get rid of the duplication and also of the unmaintained package the dependency in libwmf0.2-7 need to get updated. See also https://bugs.launchpad.net/bugs/1862641 Till
Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
On 05/02/2020 20:14, Yves-Alexis Perez wrote: So, I'm even more confused. I've upgraded again cups-filters (to 1.27.0-2) in order to do a comparison check, and tried to print, and it did work (with the Brother PPD, unchanged). This looks strange, there is no change in the pdftops filter which could have changed something before the last release. Or try running the command driverless This doesn't return anything. My printer is on the network but I don't think it advertises itself using Bonjour/zeroconf, so I'm unsure if it'd be enough for that to find it. driverless printing is a rather new property in network printers. It started some years ago with AirPrint to make iPhones be able to print when connecting to the local network via the WLAN of the router. Generally printers advertised to print from phones support at least one form of driverless printing, AirPrint in most cases. Typically the network printers launched in the last 5 years do driverless but your printer can be older. "driverless" lists all IPP printers which support driverless printing. Till
Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
I have tried it also and with the command line cupsfilter -p ../HL5250DN.ppd -i text/plain -m application/vnd.cups-postscript -e ~/.bashrc > out.ps 2>log I got valid PostScript output with a PJL header. Note that I had to specify both input and output MIME types. Probably in the cases whenthe printer does not print CUPS sends valid PJL and PostScript but some PostScript interpreter bug in the printer prevents it from printing. You can try to send the PostScript output of the command line above to your printer without further filtering, either do lp -d -o raw out.ps or nc -w1 9100 < out.ps Please try. Till
Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
The warning about not being able to convert color input into grayscale is principally no problem for you, as monochrome PostScript printers can receive color input without any problems, they convert the input by themselves. What this warning tells to me is that you upgraded from a cups-filters version from before the fix of this issue https://github.com/OpenPrinting/cups-filters/issues/169 PS Level 1 forced for grayscale PDF rendering with Poppler/Cairo to one afterwards. Without the fix of this issue your printer had most probably received PostScript Level 1 and happily printed it. Now it is receiving PostScript Level 2. Brother PostScript printers are known to have many bugs in their PostScript interpreters and therefore we have already a big bunch of workarounds in our pdftops filter. Probably the best is to try to print without using PostScript. When creating a print queue and selecting your printer's make, model, and driver manually, have a look at PCL 6/XL (pxlmono) or PCL 5e (ljet4/ljet4d/hpcups/hpijs) options. Or try running the command driverless If it lists a URI (Unified Resource Identifier) for your printer (contains your printers host name, IP, or make/model), try to set up your printer with lpadmin -p Printers -E -v URI -m everywhere replacing URI by your printer's URI from the "driverless" output. Does this work? Till
Bug#946198: Since upgrading to 1.25.13 no remote printer is made available anymore
I have done several fixes on cups-filters upstream now, please try a current GIT snapshot of cups-filters. Till
Bug#943398: linux-perf-5.2: perf report segmentation fault
Package: linux-perf-5.2 Version: 5.2.17-1+b1 Severity: important Dear Maintainer, `perf report` segfaults, making perf unusable. To reproduce, e.g. do ``` # perf record ls # perf report perf.data ``` `perf report` loads the file and the curses gui subsequently segfaults -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/24 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 linux-perf-5.2 depends on: ii libbabeltrace1 1.5.7-1 ii libc6 2.29-2 ii libdw1 0.176-1.1 ii libelf1 0.176-1.1 ii liblzma55.2.4-1+b1 ii libnuma12.0.12-1+b1 ii libperl5.30 5.30.0-7 ii libpython3.73.7.5~rc1-2 ii libslang2 2.3.2-4 ii libunwind8 1.2.1-9 ii perl5.30.0-7 ii python3 3.7.5-1 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages linux-perf-5.2 recommends: ii linux-base 4.6 Versions of packages linux-perf-5.2 suggests: pn linux-doc-5.2 -- no debconf information
Bug#935918: cups: can't read hpcups PPDs
Unfortunately, HP has also invented some page size entries named "Custom", being a copy of US Legal, for some of their inkjets in hpcups.drv. I have fixed this for Ubuntu. See https://launchpad.net/ubuntu/+source/hplip/3.19.6+dfsg0-1ubuntu1 http://launchpadlibrarian.net/443853073/hplip_3.19.6+dfsg0-1_3.19.6+dfsg0-1ubuntu1.diff.gz Till
Bug#940127: ghostscript makes c2esp autopkgtest timeout
On 22/09/2019 13:25, Brian Potkin wrote: Would this do? cat /usr/share/cups/data/form_russian.pdf | gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups -r600x600 -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=4 -scupsPageSizeName=A4 -I/usr/share/cups/fonts -c '<>setpagedevice' -f -_ > out.ras I have tried this command line (with gs 9.27 as of Ubuntu Eoan) and it did neither crash nor error. I got a valid out.ras file without any problem. For the given color space (CMY, -dcupsColorSpace=4) I got broken output (I have checked with rasterview). All other important color spaces (0, 1, 17, 18, 19, 20) give correct output for me (could be another bug in Ghostscript). Till
Bug#939316: cups-browsed: ERROR: Unable to create print queue, ignoring printer.
Fixed upstream. Thanks for the bug report. See https://github.com/OpenPrinting/cups-filters/issues/148 Will be included in the next release, 1.25.5. Till
Bug#935918: cups: can't read hpcups PPDs
This is caused by changes in CUPS 2.2.12. I have already reported an appropriate issue on CUPS upstream: https://github.com/apple/cups/issues/5639 Till
Bug#935435: cups-ipp-utils: Please replace cups-ipp-utils with ippsample
A year ago, I have already started packaging ippsample but did not follow it any further because there were no upstream releases of it yet. Here is the result of my upload to Ubuntu Universe: https://launchpad.net/ubuntu/+source/ippsample Feel free to update it to the current state of the art and add it to Debian so that we can sync it into Ubuntu. Till
Bug#933865: adb crashes on startup with SIGBUS
Package: adb
Version: 1:8.1.0+r23-5
Severity: grave
Justification: renders package unusable
Dear Maintainer,
the problem appears to be a regression between 9 (Stretch) and 10 (Buster) as
adb worked fine under Stretch and doesn't work anymore under Buster.
When I try to start 'adb' using 'adb devices -l' I get
--- snip ---
user@box:~> adb devices -l
List of devices attached
* daemon not running; starting now at tcp:5037
ADB server didn't ACK
Full server startup log: /tmp/adb.1000.log
Server had pid: 16703
--- adb starting (pid 16703) ---
adb I 08-04 11:37:16 16703 16703 main.cpp:57] Android Debug Bridge version
1.0.39
adb I 08-04 11:37:16 16703 16703 main.cpp:57] Version 1:8.1.0+r23-5
adb I 08-04 11:37:16 16703 16703 main.cpp:57] Installed as
/usr/lib/android-sdk/platform-tools/adb
adb I 08-04 11:37:16 16703 16703 main.cpp:57]
adb I 08-04 11:37:16 16703 16703 adb_auth_host.cpp:416] adb_auth_init...
adb I 08-04 11:37:16 16703 16703 adb_auth_host.cpp:174] read_key_file
'/home/till/.android/adbkey'...
adb I 08-04 11:37:16 16703 16703 adb_auth_host.cpp:391] adb_auth_inotify_init...
adb I 08-04 11:37:16 16703 16703 adb_auth_host.cpp:467] Calling
send_auth_response
* failed to start daemon
error: cannot connect to daemon
--- snap ---
Note: /tmp/adb.1000.log shows exactly what's on stdout/stderr (seen above).
The problem appears to be that adb gets killed by SIGBUS:
--- snip ---
user@box:~> strace - -o adb adb devices -l
[...]
* failed to start daemon
error: cannot connect to daemon
user@box:~> grep killed adb.167*
adb.16702:--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=16703,
si_uid=1000, si_status=SIGBUS, si_utime=2, si_stime=8} ---
adb.16703:+++ killed by SIGBUS +++
adb.16705:+++ killed by SIGBUS +++
adb.16706:+++ killed by SIGBUS +++
adb.16713:+++ killed by SIGBUS +++
adb.16715:+++ killed by SIGBUS +++
adb.16716:+++ killed by SIGBUS +++
user@box:~> cat adb.16703
set_robust_list(0xb6b25540, 12) = 0
close(3)= 0
execve("/usr/lib/android-sdk/platform-tools/adb", ["adb", "-L", "tcp:5037",
"fork-server", "server", "--reply-fd", "4"], 0xbecde0d4 /* 30 vars */) = 0
brk(NULL) = 0xde9000
[...]
bind(6, {sa_family=AF_INET, sin_port=htons(5037),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
listen(6, 4)= 0
[...]
futex(0xb6bd9860, FUTEX_WAKE_PRIVATE, 2147483647) = 0
getrandom("\xd6\x33\x59\xbc\xf7\x11\x33\x14\x38\x2d\x14\x48\x24\x14\xfb\xe0\x17\x40\xfd\x73\x07\x9a\xec\x6e\x89\x28\x25\xb6\x3e\x41\x04\x94",
32, 0) = 32
futex(0xb6bd9bec, FUTEX_WAKE_PRIVATE, 2147483647) = 0
getrandom("\xd2\x6f\x66\x87\x1c\x98\x22\x65\xd0\x70\x74\x8d\x8e\xd6\xe6\xa8\x83\xce\xc5\x63\x09\x25\x63\xe4\xbf\x97\x95\xfe\x6c\x3a\x9b\x89"...,
48, 0) = 48
--- SIGBUS {si_signo=SIGBUS, si_code=BUS_ADRALN, si_addr=0xb6b9dba1} ---
+++ killed by SIGBUS +++
--- snap ---
Forcibly installing these packages gives me a working adb:
adb_7.0.0+r33-1_armhf.deb
android-libadb_7.0.0+r33-1_armhf.deb
android-libbase_7.0.0+r33-1_armhf.deb
android-libcutils_7.0.0+r33-1_armhf.deb
-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: armhf (armv7l)
Kernel: Linux 4.19.0-5-armmp-lpae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages adb depends on:
ii android-libadb 1:8.1.0+r23-5
ii android-libbase 1:8.1.0+r23-5
ii libc62.28-10
ii libgcc1 1:8.3.0-6
ii libstdc++6 8.3.0-6
Versions of packages adb recommends:
ii android-sdk-platform-tools-common 27.0.0+10
adb suggests no packages.
-- no debconf information
Bug#926576: ghostscript: printer stopped working: ghostscript fails with ""Unable to determine number of pages"
I have released cups-filters 1.22.5 upstream now with the fix. Till
Bug#926576: ghostscript: printer stopped working: ghostscript fails with ""Unable to determine number of pages"
Thanks for reporting this. I have fixed the problem now by changing the Ghostscript call to count pages in a PDF file. See https://github.com/OpenPrinting/cups-filters/commit/297cc2d I found this solution with the help of a bug report to Arch Linux: https://bugs.archlinux.org/task/62251 There they have found the alternative method and also talked with the Ghostscript developers on IRC to confirm the need of the change. The old call used the undocumented internal "pdfdict" of Ghostscript which from Ghostscript 9.27 on is not accessible any more for security reasons. Now I use the call suggested in the Arch Linux bug report using "runpdfbegin". Till
Bug#926576: ghostscript: printer stopped working: ghostscript fails with ""Unable to determine number of pages"
Does gs -o - -dNODISPLAY using Ghostscript 9.27, with being a PDF file which you do not succeed to print due to this problem, give you a list of "Page XX" lines for each page in the PDF file (plus some other irrelevant lines)? Can you post the output of the command here? Till
Bug#918726: printer-driver-gutenprint: PPD files not updated during upgrade of printer-driver-gutenprint
On 10/01/2019 09:43, Didier Raboud wrote: Le 10.01.2019 09:22, Till Kamppeter a écrit : On 10/01/2019 08:56, Didier 'OdyX' Raboud wrote: 'cups-genppdupdate -x' and restarting cups fixed the problem (-x allows update across major Gutenprint releases). Till: it seems that our trigger is not enough for these. Opinions? For me it looks like that our trigger needs to run "cups-genppdupdate -x" instead of simply "cups-genppdupdate". Well, the CUPS trigger doesn't run "cups-genppdupdate" at all: OK. Now I remember that it works without "cups-genppdupdate". I implemented it this way: if [ "$1" = configure ] && dpkg --compare-versions "$2" lt-nl 5.3.1-7~; then # Force upgrade of gutenprint PPDs accross major versions cups-genppdupdate -x fi So any upgrade from before the current version will get the -x treatment (that's to do it for unstable users with broken PPDs). OK, great. I don't think we should be modifying CUPS' trigger code specifically for gutenprint. If gutenprint needs different treatment, let's make it happen in gutenprint, no? Ok, I did not mean to change anything in the CUPS package here. Tll
Bug#918726: printer-driver-gutenprint: PPD files not updated during upgrade of printer-driver-gutenprint
On 10/01/2019 08:56, Didier 'OdyX' Raboud wrote: 'cups-genppdupdate -x' and restarting cups fixed the problem (-x allows update across major Gutenprint releases). Till: it seems that our trigger is not enough for these. Opinions? For me it looks like that our trigger needs to run "cups-genppdupdate -x" instead of simply "cups-genppdupdate". The "-x" is needed only once for the transition of major versions. So one could perhaps also do a "-x" in postinst depending on the old and new version number and leave the trigger unchanged. Till
Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"
Bernhard, thank you for your patches. I have applied them (slightly changed) to cups-browsed upstream. They actually do not do any functional changes, so if the BrowseFilter facility does not work as expected, this is another bug and this bug was probably there before. Till
Bug#916377: cups-browsed: segfault during upgrade
This I have already fixed upstream. It was already reported as upstream issue #79 and Debian bug #916149. Till
Bug#908500: cups-browsed: Please consider making cups-browsed a Suggests:
On 13/12/2018 19:45, Brian Potkin wrote: On Mon 22 Oct 2018 at 08:54:52 +0200, Didier 'OdyX' Raboud wrote: Control: reopen -1 Control: reassign -1 cups-daemon 2.2.8-5 Control: retitle -1 cups-daemon: Please consider making cups-browsed a Suggests Control: affects -1 +cups-browsed Le dimanche, 21 octobre 2018, 21.21:13 h CEST Debian BTS a écrit : On Mon 10 Sep 2018 at 15:16:44 +0100, Brian Potkin wrote: Package: cups-browsed Version: 1.21.2-1 Severity: wishlist With the introduction of cups 1.6.x the situation in respect to printing to remote print queues and printers would have been dire without the creation of cups-browsed. However, cups 2.2.4 and later has the ability (CUPS Issue #4993) to enumerate queues and printers in print dialogs and to auto-create a temporary print queue. This is used by applications having the Qt dialog and printing from the command line, although the GTK dialog still does its own thing. cups-browsed is installed by default because cups-daemon (quite rightly) recommends it. With the changed situation in CUPS and applications it would appear that cups-browsed has less relevance with regard to printer and print queue discovery and management. The Recommends field lists packages that would be found with the cups package because there is a strong dependency between it and cups-browsed. cups-browsed would still enhance cups if changed to a Suggests:. The installation of cups-browsed almost as a matter of course on many buster systems also masks bugs in CUPS and applications, as it will take over the management of queues/printers. A small example is CUPS Issue #5045. Another example is with okular. For me, it will not print to a temporary queue; with a local cups-browsed queue it will. This would probably pass unnoticed as things stand now. The resounding silence is an indication of the quality of this report. It was probably a naff idea. Closing. I disagree. Although I haven't interacted on the bug, your report sparkled some thoughts, and I had its proper handling on my "to spend some energy on later" list. In the meantime, cups-filters started to FTBFS in unstable; a fix was urgent and I spent the minimal amount of energy to solve that issue. But demoting the cups-daemon ⇒ cups-browsed relationship from a Recommends to a Suggests is something we should consider, and your argumentation makes sense to me. @Till: any opinion? I'll argue against myself by describing how I see the GUI apps handling printing. Apologies in advance for misinformation or misinterpretation in the testing process. 1. cups-browsed is needed by the GTK print dialog for printing to IPP printers (#916267). 2. At present, Qt based apps do not print to remote print queues and IPP printers without cups-browsed (#911702). 3. The native print dialog of the chromium browser enumerates queues (with the help of CUPS) but will not print to them. 4. Only LibreOffice appears to operate in a sane way by promoting printing to any remote queue or IPP printer without cups-browsed. Sending CUPS semi-naked into the world of buster doesn't look like a good idea. To solve all the problems with the print dialogs I have started the Common Print Dialog Backends project in 2017. If Debian adopts it we will at some time really be able to work without cups-browsed. See https://github.com/OpenPrinting/cpdb-libs https://github.com/OpenPrinting/cpdb-backend-cups https://github.com/OpenPrinting/cpdb-backend-gcp https://github.com/OpenPrinting/cpdb-backend-file and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911335 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911340 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911342 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911345 These will centralize the communication with the print systems so that the print dialogs do not need to do this and do not need to be adapted to every change in print technology. Till
Bug#916149: Segfault on systemctl stop or systemctl restart
Thanks for the feedback. Till
Bug#916149: Segfault on systemctl stop or systemctl restart
Fixed upstream in commit f3d48ecd. The checking for HTTP timeouts on queue creation has be done at the wrong place, leading to crashes on queue removal, which happens on shutdown. Till
Bug#915634: printer-driver-hpcups: PPDs for fax functionality
On 06/12/2018 21:57, Didier 'OdyX' Raboud wrote: Control: tags -1 +help Le mercredi, 5 décembre 2018, 13.57:04 h CET Brian Potkin a écrit : The file list for printer-driver-hpcups is: … But the package description says: It does not provide PPDs for the fax functionality of HP's multi- function devices. Shouldn't that be It is also required for HPLIP fax support. as is in the printer-driver-hpijs package? To be fair, I have no idea how Fax functionality is supposed to work; whether it does, and if it's still useful at all. :-) Instead of moving these files around, what would you think about dropping it entirely? Fax is a rather old mean of communication, more and more replaced by e-mails with scanned documents attached. For me it is 4 years ago when I had to send a fax the last time. Perhaps in some countries fax is still more important. As many HP devices support fax and HP supports their fax function with their software I would not simply drop it, but move the PPD files for fax to the part of HPLIP which contains the fax-supporting software (the /usr/lib/cups/backend/hpfax backend). By the way, also some of HP's PPDs for Postscript printers can need a part of HPLIP, the /usr/lib/cups/filter/hpps filter, but this one is already in the printer-driver-postscript-hp package. So what I see has to be done is only moving the fax PPDs into the package with the hpfax backend. Otherwise the printer-driver-... binary packages of HPLIP seem to be OK. Till
Bug#908147: restarting cups-browsed deleted print jobs
Anthony, thanks for testing. The fix is on its way into Debian and Ubuntu. Till
Bug#908147: restarting cups-browsed deleted print jobs
cups-browsed is part of cups-filters, not of CUPS. The patch you find here: https://github.com/OpenPrinting/cups-filters/commit/0d29084a864ca80ada8b4eafc2d36f072e06f984 Till
Bug#908147: restarting cups-browsed deleted print jobs
Anyone suffering this problem, can you apply my upstream fix and check again whether this solves the problem? Thanks. Till
Bug#908147: restarting cups-browsed deleted print jobs
I have (hopefully) fixed this bug upstream now (commit 0d29084a864c). In case of a shutdown of cups-browsed the queues were even removed with jobs. This I have corrected now, now cups-browsed really only removes print queues when they do not have jobs. The problem occurred independent of whether the remote queues are discovered from the local network or via BrowsePoll. Till
Bug#908147: restarting cups-browsed deleted print jobs
Usually cups-browsed does not remove a print queue if it still has jobs. If it is stopped and one of its queues still has jobs, this queue is left intact. Next time it starts it connects the this remaining queue with its printer if it re-discovers the printer, or removes it if the printer has disappered (also only when there are no jobs). Anyone here who can reproduce the vanishing of print jobs when stopping or restarting cups-browsed, please put cups-browsed in debug logging mode by stopping it, editing /etc/cups/cups-browsed.conf to contain a line DebugLogging file and start it again. Then do all the reproducer steps as described in the previous postings here and after that, attach your /etc/cups/cups-browsed.conf to this bug report. Thanks. Till
Bug#910882: cups-browsed: The default for UseCUPSGeneratePPDs should be "Yes"
I have fixed the disappearing queue problem upstream in commit dd862c9b. What happened is that one cannot reliably determine the temporary nature of a CUPS queue via printer-is-temporary. So I check whether the queue is shared instead and as any shared queue is permanent I do the procedure of setting and unsetting the shared bit on any unshared queue as it can be temporary. So with this I am sure that my queue is permanent and I do not interrupt the shared status of a shared queue. Till
Bug#909423: cups-browsed: Unusual behaviour with the default CreateIPPPrinterQueues
So to investigate this further I would need a log file of cups-browsed. You get a log file if there is a line DebugLogging file in cups-browsed.conf The log file will by default be created as /var/log/cups/cups-browsed_log Please attach your log file (from starting cups-browsed until observation of wrong behavior) to this bug report. Also attach your cups-browsed.conf. Till
Bug#910882: cups-browsed: The default for UseCUPSGeneratePPDs should be "Yes"
So to investigate this further I would need a log file of cups-browsed. You get a log file if there is a line DebugLogging file in cups-browsed.conf The log file will by default be created as /var/log/cups/cups-browsed_log Please attach your log file (from starting cups-browsed until observation of wrong behavior) to this bug report. Also attach your cups-browsed.conf. Till
Bug#912768: hplip-data: hp-toolbox fsck
Concerning the scanning, I have done the following observation:
I have the HP OfficeJet Pro 8730.
I have removed all print queues using the "hp" CUPS backend (I print
with a driverless queue). With an HPLIP-based print queue my scanner is
always found.
1. Printer on the network
scanimage -L
does not find the scanner in my MF device, but
scanimage -d hpaio:/net/HP_OfficeJet_Pro_8730?ip=w.x.y.z > x.pnm
scans correctly.
hp-probe finds the URI:
hp:/net/HP_OfficeJet_Pro_8730?ip=w.x.y.z
2. Printer on USB
scanimage -L
finds the scanner with the following URI:
hpaio:/usb/HP_OfficeJet_Pro_8730?serial=xx
and it scans also when specifying this URI.
hp-probe finds the URI:
hp:/usb/HP_OfficeJet_Pro_8730?serial=CN783F60W1
Now I did some debugging and found out that "scanimage -l" discovers the
scanner with the URI (device on network, note the "hp_" missing in the
model name, upper/lower case is ignored by HPLIP):
hpaio:/net/officejet_pro_8730?ip=w.x.y.z
This does not match the model name in
/usr/share/hplip/data/models/models.dat which is "[hp_officejet_pro_8730]".
So I did the following change:
--
--- io/hpmud/model.c~ 2018-08-21 17:42:16.0 +0200
+++ io/hpmud/model.c2018-11-06 17:14:04.302446688 +0100
@@ -420,7 +420,10 @@
strncpy(section, rcbuf+1, sizeof(section)); /* found new
section */
n = strlen(section);
section[n-2]=0; /* remove ']' and CR */
- if (strcasecmp(model, section) == 0)
+ if (strcasecmp(model, section) == 0 ||
+(section[0] == 'h' && section[1] == 'p' &&
+ section[2] == '_' &&
+ strcasecmp(model, section + 3) == 0))
{
/* Found model match. */
*bytes_read = ResolveAttributes(fp, attr, attrSize);
--
This matches the model names both with and without "hp_" in the beginning.
Note that I did not yet upload an Ubuntu package of HPLIP with this
patch as the archive is not yet opened for the disco (19.04) development
cycle.
After applying this change "scanimage -L" discovers also my scanner when
connected to the network and I can scan from any SANE-based application
without needing a print queue using the "hp" CUPS backend of HPLIP.
Cristian, this could solve your scanner problem if the other fixes did
not solve it yet, please try and report back.
In general this patch helps for using driverless printing on HP devices
as long as they are connected by the network. If you do driverless
printing via USB, with ippusbxd (IPP over USB) scanning does not work
while ippusbxd is connected to the printer (it is really time that
manufacturers start with driverless IPP scanning).
So for USB connection you will still need to print with HPLIP if you
want to be able to scan.
Till
Bug#912768: hplip-data: hp-toolbox fsck
In general, it looks like that the HPLIP guys at HP are not testing well the GUI part. This caused the following bugs, all forwarded upstream but no fixes from upstream yet, only distro patches in the Ubuntu Cosmic package of HPLIP (3.18.7+dfsg1-2ubuntu2): https://launchpad.net/bugs/1688684 hp-check does not show distro names correctly but internal index numbers for them https://launchpad.net/bugs/1745383 QMessageBox() is called incorrectly https://launchpad.net/bugs/1789184 hp-toolbox does not start at all The drivers themselves (CUPS filters/PPD files and SANE module) seem to work reasonably well, but for some small part of the device range a proprietary plugin is needed, and some of these devices probably also offer driverless IPP printing and this way one could work around the proprietary plugin at least if it concerns only printing. For diagnostic purposes you can perhaps also use hp-check instead of hp-doctor as it has no GUI. Till
Bug#912768: hplip-data: hp-toolbox fsck
Brian, if the user only wants to print with his printer (is it a print-only device or a multi-function device with scanner) driverless IPP printing works indeed, especially with HP devices. Then this is the recommended solution. Only for scanning one still needs drivers and in case of HP's multi-function devices HPLIP (a driverless IPP scanning standard is already there, but not yet adopted in actual hardware). Till
Bug#912768: hplip-data: hp-toolbox fsck
I have fixed this bug and two others one in the HPLIP package for Ubuntu
Cosmic (18.10). Simply overtake the two patches which I have added.
https://launchpad.net/ubuntu/+source/hplip/+changelog
https://launchpad.net/ubuntu/+source/hplip/3.18.7+dfsg1-2ubuntu2
https://launchpad.net/ubuntu/+source/hplip/3.18.7+dfsg1-2ubuntu1
https://launchpad.net/bugs/1789184
Till
On 03/11/2018 19:20, Cristian Ionescu-Idbohrn wrote:
Package: hplip-data
Version: 3.18.10+dfsg0-1
Severity: grave
Justification: renders package unusable
$ hp-toolbox
HP Linux Imaging and Printing System (ver. 3.18.10)
HP Device Manager ver. 15.0
Copyright (c) 2001-15 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-cii'
\Traceback (most recent call last):
File "/usr/bin/hp-toolbox", line 280, in
toolbox = ui.DevMgr5(__version__, device_uri, None)
File "/usr/share/hplip/ui5/devmgr5.py", line 253, in __init__
self.initUI()
File "/usr/share/hplip/ui5/devmgr5.py", line 324, in initUI
self.DiagnoseQueueAction.setIcon(QIcon(load_pixmap('warning', '16x16')))
AttributeError: 'DevMgr5' object has no attribute 'DiagnoseQueueAction'
Patch here:
https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/1789184/comments/7
seems to help.
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=en_US:en
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages hplip-data depends on:
ii python3 3.6.7-1
ii xz-utils 5.2.2-1.3
hplip-data recommends no packages.
Versions of packages hplip-data suggests:
ii hplip 3.18.10+dfsg0-1
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/share/hplip/ui5/devmgr5.py (from hplip-data package)
Cheers,
Bug#911335: ITP bug reports for the backend packages
CUPS/IPP backend: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911340 Google Cloud Print backend: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911342 Print-to-File backend: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911345
Bug#911345: ITP: cpdb-backend-file -- Common Print Dialog Backends - Print-to-File Backend
Package: wnpp Severity: wishlist Owner: Till Kamppeter * Package name: cpdb-backend-file Version : 1.0.1 Upstream Author : Ayush Bansal * URL : https://github.com/OpenPrinting/cpdb-backend-file * License : MIT Programming Lang: C Description : Common Print Dialog Backends - Print-to-File Backend This package needs cpdb-libs, ITP here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911335 This is already packaged for Ubuntu. This is the long description of the Ubuntu package: This is the Print-to-File backend for print dialogs using the Common Print Dialog Backends concept of OpenPrinting. It makes the dialog list one single print queue and if you print to it, the data is put into a PDF file and not sent to a printer. The idea is to decouple the print dialog's GUI code (GTK, Qt, LibreOffice, ... The frontends) from the code which communicates with actual print technologies (CUPS, IPP, Google Cloud Print, Save to File, ... The backends) to make them independently interchangable. This way one can do things like - Add a new print technology and it is immediately available for all GUI apps. Especially an online print service provider could simply put its backend into the Snap Store and asks his Linux users to install it. - A change in a print technology, for example new functionality in CUPS, can be covered by simply updating the CUPS backend. No need to change all GUI libraries. - User logs in for Google Cloud Print once and not separately for each GUI platform to get his cloud printers into all the apps. - In case of a security bug in the communication code with one print technology only the backend needs to get fixed, not several GUI libs. This package contains a backend which creates a printer entry in all print dialogs (using cpdb-libs) which drops jobs sent to it simply in PDF files. The backend instructs the print dialogs to show a printer entry and to pop-up a "Save as ..." dialog when hitting "Print" (and/or selecting the "Destination File Name" option). For this to work at least one application with a print dialog using cpdb-libs must be installed. Of the GUIs LibreOffice already supports this system and only needs to get rebuilt with this library. Patches for GTK and a modified Qt print dialog are in the works. All packages are already available as Ubuntu packages in Ubuntu's Universe part. The maintenance in Debian should be done in the Debian Printing Team. I am not a Debian Developer but OdyX (Didier Raboud, o...@debian.org) is willing to upload these packages.
Bug#911342: ITP: cpdb-backend-gcp -- Common Print Dialog Backends - Google Cloud Print Backend
Package: wnpp Severity: wishlist Owner: Till Kamppeter * Package name: cpdb-backend-gcp Version : 1.1.0 Upstream Author : Abhijeet Dubey * URL : https://github.com/OpenPrinting/cpdb-backend-gcp * License : MIT Programming Lang: C Description : Common Print Dialog Backends - Google Cloud Print Backend This package needs cpdb-libs, ITP here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911335 This is already packaged for Ubuntu. This is the long description of the Ubuntu package: This is the Google Cloud Print backend for print dialogs using the Common Print Dialog Backends concept of OpenPrinting. It makes the dialog list the Google Cloud Print destinations set by the current user plus the option to drop the job as PDF on the Google Drive and allows printing on these using the dialog. . For a user to be able to use this facility he must set up his Google account in the "Online Accounts" section of GNOME Control Center. The idea is to decouple the print dialog's GUI code (GTK, Qt, LibreOffice, ... The frontends) from the code which communicates with actual print technologies (CUPS, IPP, Google Cloud Print, Save to File, ... The backends) to make them independently interchangable. This way one can do things like - Add a new print technology and it is immediately available for all GUI apps. Especially an online print service provider could simply put its backend into the Snap Store and asks his Linux users to install it. - A change in a print technology, for example new functionality in CUPS, can be covered by simply updating the CUPS backend. No need to change all GUI libraries. - User logs in for Google Cloud Print once and not separately for each GUI platform to get his cloud printers into all the apps. - In case of a security bug in the communication code with one print technology only the backend needs to get fixed, not several GUI libs. This package contains the backend for access the printers and the Google Drive (to save as PDF) of the Google account of the current user. It supplies information about the Google-registered printers, their capabilities, and user-settable options and it passes print jobs on to Google. The print dialogs (using cpdb-libs) connect to this backend via D-Bus. To do so, it is enough to have this backend package installed and each user who wants to use it, logged into his Google account via Online Accounts. For this to work at least one application with a print dialog using cpdb-libs must be installed. Of the GUIs LibreOffice already supports this system and only needs to get rebuilt with this library. Patches for GTK and a modified Qt print dialog are in the works. All packages are already available as Ubuntu packages in Ubuntu's Universe part. The maintenance in Debian should be done in the Debian Printing Team. I am not a Debian Developer but OdyX (Didier Raboud, o...@debian.org) is willing to upload these packages.
Bug#911340: ITP: cpdb-backend-cups -- Common Print Dialog Backends - CUPS/IPP Backend
Package: wnpp Severity: wishlist Owner: Till Kamppeter * Package name: cpdb-backend-cups Version : 1.1.0 Upstream Author : Nilanjana Lodh * URL : https://github.com/OpenPrinting/cpdb-backend-cups * License : MIT Programming Lang: C Description : Common Print Dialog Backends - CUPS/IPP Backend This package needs cpdb-libs, ITP here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911335 This is already packaged for Ubuntu. This is the long description of the Ubuntu package: This is the CUPS/IPP backend for print dialogs using the Common Print Dialog Backends concept of OpenPrinting. It makes the dialog list CUPS print queues and driverless-capable IPP printers and allows printing on these using the dialog. The idea is to decouple the print dialog's GUI code (GTK, Qt, LibreOffice, ... The frontends) from the code which communicates with actual print technologies (CUPS, IPP, Google Cloud Print, Save to File, ... The backends) to make them independently interchangable. This way one can do things like - Add a new print technology and it is immediately available for all GUI apps. Especially an online print service provider could simply put its backend into the Snap Store and asks his Linux users to install it. - A change in a print technology, for example new functionality in CUPS, can be covered by simply updating the CUPS backend. No need to change all GUI libraries. - User logs in for Google Cloud Print once and not separately for each GUI platform to get his cloud printers into all the apps. - In case of a security bug in the communication code with one print technology only the backend needs to get fixed, not several GUI libs. This package contains the backend for access local and remote CUPS print queues and IPP network printers. It supplies information about the printers, their capabilities, and user-settable options and it passes print jobs on to printers. The print dialogs (using cpdb-libs) connect to this backend via D-Bus. To do so, it is enough to have this backend package installed. For this to work at least one application with a print dialog using cpdb-libs must be installed. Of the GUIs LibreOffice already supports this system and only needs to get rebuilt with this library. Patches for GTK and a modified Qt print dialog are in the works. All packages are already available as Ubuntu packages in Ubuntu's Universe part. The maintenance in Debian should be done in the Debian Printing Team. I am not a Debian Developer but OdyX (Didier Raboud, o...@debian.org) is willing to upload these packages.
Bug#911335: ITP: cpdb-libs -- Common Print Dialog Backends - Interface Library for Backends
Package: wnpp Severity: wishlist Owner: Till Kamppeter * Package name: cpdb-libs Version : 1.1.2 Upstream Author : Nilanjana Lodh * URL : https://github.com/OpenPrinting/cpdb-libs * License : MIT Programming Lang: C Description : Common Print Dialog Backends - Interface Library for Backends This is already packaged for Ubuntu. This is the long description of the Ubuntu package: The Common Print Dialog Backends project provides a D-Bus interface so that the print dialogs of GUI applications and the communication with the print technologies (CUPS/IPP, Google Cloud Print, Save to File, ...) are put into separate executables to be separately exchangeable. . The print dialogs of the different GUI toolkits and applications (GTK, Qt, LibreOffice, ...) are the frontends and to communicate with the different print technologies they use common backends. This way one simply adds new backends for new print technologies and updates the backends for changes in the print technologies, and immediately all applications are up-to-date, without need of modifying the code of the GUI toolkits or applications. . This package contains the library which provides the functions needed by both the frontends and the backends. The idea is to decouple the print dialog's GUI code (GTK, Qt, LibreOffice, ... The frontends) from the code which communicates with actual print technologies (CUPS, IPP, Google Cloud Print, Save to File, ... The backends) to make them independently interchangable. This way one can do things like - Add a new print technology and it is immediately available for all GUI apps. Especially an online print service provider could simply put its backend into the Snap Store and asks his Linux users to install it. - A change in a print technology, for example new functionality in CUPS, can be covered by simply updating the CUPS backend. No need to change all GUI libraries. - User logs in for Google Cloud Print once and not separately for each GUI platform to get his cloud printers into all the apps. - In case of a security bug in the communication code with one print technology only the backend needs to get fixed, not several GUI libs. This package contains the general libraries which especially provide a session D-Bus interface between the print dialogs (frontends) and the print technology backends. For this to work at least one print technology backend package is needed. These packages are suggested in separate bug reports. Of the GUIs LibreOffice already supports this system and only needs to get rebuilt with this library. Patches for GTK and a modified Qt print dialog are in the works. All packages are already available as Ubuntu packages in Ubuntu's Universe part. The maintenance in Debian should be done in the Debian Printing Team. I am not a Debian Developer but OdyX (Didier Raboud, o...@debian.org) is willing to upload these packages.
Bug#909564: avahi: Support local-only services via the loopback interface
Thanks, but please get the patch from here: https://github.com/OpenPrinting/ippusbxd or https://github.com/lathiat/avahi/issues/125 Your links were my first post of ippusbxd right after my GSoC student has done this project, long before I decided to move the OpenPrinting projects to GitHub. My links above are the official upstream place of ippusbxd and the feature request to Avahi upstream. Both these have the complete patch, so please only use these ones. Till
Bug#907493: Timeout in autopkgtest also in Ubuntu Cosmic with Ghostscript 9.24
An update: On Ubuntu the timeouts in the CUPS autopkgtest do not happen any more with Ghostscript 9.25 which got released yesterday and is highly recommended by upstream to fix the regressions in 9.24. Till
Bug#907493: Timeout in autopkgtest also in Ubuntu Cosmic with Ghostscript 9.24
I have updated Ubuntu's Ghostscript from 9.23 to 9.24 as upstream recommended it highly for security reasons. The autopkgtests all passed without problems for Ghostscript 9.23 on Ubuntu. On 9.24 I get a timeout on drv:///sample.drv/generic.ppd: -- * Driver drv:///sample.drv/generic.ppd - Create test printer: done. - Print test job with /usr/share/cups/data/classified.pdf: ... [...] ... utopkgtest [00:21:30]: ERROR: timed out on command "su -s /bin/bash root -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true; . ~/.profile >/dev/null 2>&1 || true; buildtree="/tmp/autopkgtest.RrEJnT/build.lFx/src"; mkdir -p -m 1777 -- "/tmp/autopkgtest.RrEJnT/cups-artifacts"; export AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest.RrEJnT/cups-artifacts"; export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 "/tmp/autopkgtest.RrEJnT/autopkgtest_tmp"; export AUTOPKGTEST_TMP="/tmp/autopkgtest.RrEJnT/autopkgtest_tmp"; export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=1; unset LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo $$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f /tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; export AUTOPKGTEST_NORMAL_USER=ubuntu; export ADT_NORMAL_USER=ubuntu; export 'ADT_TEST_TRIGGERS=ghostscript/9.24~dfsg+1-0ubuntu1'; chmod +x /tmp/autopkgtest.RrEJnT/build.lFx/src/debian/tests/cups; touch /tmp/autopkgtest.RrEJnT/cups-stdout /tmp/autopkgtest.RrEJnT/cups-stderr; /tmp/autopkgtest.RrEJnT/build.lFx/src/debian/tests/cups 2> >(tee -a /tmp/autopkgtest.RrEJnT/cups-stderr >&2) > >(tee -a /tmp/autopkgtest.RrEJnT/cups-stdout);" (kind: test) -- Was there already found a solution for Debian? If yes, what has been done? Upstream commit 150c8f69646 (Bug 699658(related): Move recording of temp file names into C) is the very last upstream commit which made it into the 9.24 release. http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=150c8f69646b8 Till
Bug#907900: hplip: Printing is not possible b/c of missing foomatic-rip-hplip filter
On 04/09/18 21:20, Dimitri Chausson wrote: Hello Brian, thanks for your quick reply, following are the results: $> grep -i cupsfilter /etc/cups/ppd/HP_DeskJet_3630_series.ppd *cupsFilter: "application/vnd.cups-postscript 100 foomatic-rip-hplip" *cupsFilter: "application/vnd.cups-pdf 0 foomatic-rip-hplip" AFAIK there is no package providing a foomatic-rip-hplip in Debian or Ubuntu. Probably your PPD comes from an older version of HPLIP installed from the original source (not as Debian package). So removing and re-creating your print queue probably gives you an up-to-date PPD file which does not use foomatic-rip-hplip, but, instead, the hpcups filter of HPLIP. $> ls -l /usr/lib/cups/foomatic-rip ls: cannot access '/usr/lib/cups/foomatic-rip': No such file or directory As it seems (searching for it with apt-file), this file is part of the 'foomatic-filters' package, which is not installed on my system: this package cannot be installed as it conflicts with package 'cups-filters'... Already for some time the upstream home of foomatic-rip is cups-filters and the upstream package foomatic-filters is discontinued. In Debian and Ubuntu foomatic-rip is therefore provided by the cups-filters binary package. If it is missing but cups-filters is installed, run sudo apt install --reinstall cups-filters to refresh your cups-filters installation. Under no circumstances try to install the foomatic-filters package. The Debian folks should remove it. On Ubuntu it is already removed for some time. Till
Bug#907399: Logs with systemd-coredump
cups-filters 1.21.2 is released upstream now. Till
Bug#907399: Logs with systemd-coredump
Thank you very much for the test. So the problem is solved. I will do a 1.21.2 release soon so that a fixed package can be uploaded to Debian. Till
Bug#907399: Logs with systemd-coredump
Bernhard, thank for the patch. I have applied it now (and also done an additional fix for DomainSocket) and committed it to the upstream GIT repo. Please test. Till
Bug#907493: ghostscript breaks cups autopkgtest: test times out
On 31/08/18 15:36, Didier 'OdyX' Raboud wrote: Le vendredi, 31 août 2018, 01.25:24 h CEST Jonas Smedegaard a écrit : Do the freshly released experimental Ghostscript release help anything? It doesn't seem to, unfortunately. :-( To reproduce the issue; just run this as root: /usr/share/cups/test-drivers Surprisingly; it will fail when testing the _second_ printer, always. Also, it doesn't seem to get fixed with the ghostscript from testing. There's something fishy here, but I can't say with certainty that it's ghostscript's fault :-( Which driver is this second printer using? Which version of cups-filters are you using? 1.21.0 has a bug in foomatic-rip which is fixed in 1.21.1. Please update to 1.21.1 if you have 1.21.0 currently. Till
Bug#907026: cups-filters: filter failed on Ricoh MP 3554 SP after upgrading to 1.21.0-1
Wenbin Lv, thank you very much for testing. I have released version 1.21.1 with the fix. It will soon appear in Debian. Till
Bug#904605: cups-ipp-utils: Should depend on avahi-daemon
On 25/07/18 21:40, Brian Potkin wrote: From what I read, ippserver in CUPS is experimental sample code that upstream advises against using in a distribution. https://github.com/apple/cups/issues/5141 https://github.com/apple/cups/issues/5222 Yes, therefore the introduction of the ippsample package with the current developemnt of this code. And ippsample is actually developed, I have currently 3 GSoC students working on it. And it is the sample implementation of the standards of the PWG. Till
Bug#904605: cups-ipp-utils: Should depend on avahi-daemon
I think so, please add a "Recommends: avahi-daemon". By the way, cups-ipp-utils should get replaced by the independent ippsample package. as these tools are now independently maintained by the PWG (Printing Working Group). The "ippsample" package is at least in Ubuntu Universe (https://launchpad.net/ubuntu/+source/ippsample), if it was not yet proposed as a new package for Debian, it should be done so. Also here "Recommends: avahi-daemon" should be added. Till
Bug#895549: cups-browsed: Legacy CUPS (1.5.x and before) broadcasted queues are ignored
Released 1.20.3 upstream now, containing said fix: https://github.com/OpenPrinting/cups-filters/releases/tag/release-1-20-3
Bug#895543: dhelp PostScript file display broken, fixed by using Ghostscript's ps2txt instead of unmaintained pstotext
Package: dhelp
Version: 0.6.24
Hi,
dhelp uses pstotext to display PostScript files on a console or in a
terminal.
pstotext stopped working with the recent update to Ghostscript 9.22.
This is not only due to the deprecation of "-dDELAYBIND" in Ghostscript
(which was withdrawn in 9.23) but also by an additional problem in
Ghostscript.
As pstotext did not get maintained upstream for years it is better to
drop it and replace it by the ps2txt utility of Ghostscript. ps2txt's
compatibility with the Ghostscript it comes with is assured as they are
maintained together.
pstotext is only used by dhelp, so to eliminate it from the distro it is
enough to update the appropriate command lines in dhelp and the
autopkgtest in the doc-rfc package (Debian bug #895541).
See also Debian bug #895513 about the pstotext issue.
Attached is my patch on the dhelp package as I have applied it in Ubuntu
(0.6.24-0ubuntu1).
Till
--- a/scripts/conv-pstotext
+++ b/scripts/conv-pstotext
@@ -6,7 +6,7 @@
#
# $1 = Input file, $2 = Output file
-2>/dev/null pstotext -output "${2}" "${1}"
+2>/dev/null ps2txt "${1}" "${2}"
EXITVAL=$?
if [ ${EXITVAL} -ne 0 ]; then
echo "Error converting file: ${1}"
--- a/src/dsearch
+++ b/src/dsearch
@@ -148,17 +148,17 @@
$text = `/usr/bin/pdftotext "$file" -`;
}
else {
-# pstotext is a dependency, so this should never fail, but we
+# ghostscript is a dependency, so ps2txt should never fail, but we
# recommend the user to install xpdf-utils instead, to get
# pdftotext (better extraction quality and much faster)
-$text = file_to_text("/usr/bin/pstotext '$file'", "PDF", "xpdf-utils");
+$text = file_to_text("/usr/bin/ps2txt '$file'", "PDF", "xpdf-utils");
}
}
elsif ($ext =~ /dvi/) {
$text = file_to_text("/usr/bin/catdvi '$file'", "DVI", "catdvi");
}
elsif ($ext =~ /ps/) {
-$text = file_to_text("/usr/bin/pstotext '$file'", "Postscript", "pstotext");
+$text = file_to_text("/usr/bin/ps2txt '$file'", "Postscript", "ghostscript");
}
else {
open F, $file;
Bug#895541: doc-rfc autopkgtest broken, fixed by using Ghostscript's ps2txt instead of unmaintained pstotext
Package: doc-rfc Version: 20170121-1 Severity: grave Hi, the autopkgtest of doc-rfc passes all PostScript files coming with the package through pstotext to check their integrity for use by dhelp which also uses pstotext. pstotext stopped working with the recent update to Ghostscript 9.22. This is not only due to the deprecation of "-dDELAYBIND" in Ghostscript (which was withdrawn in 9.23) but also by an additional problem in Ghostscript. As pstotext did not get maintained upstream for years it is better to drop it and replace it by the ps2txt utility of Ghostscript. ps2txt's compatibility with the Ghostscript it comes with is assured as they are maintained together. pstotext is only used by dhelp, so to eliminate it from the distro it is enough to update the appropriate command lines in dhelp and in the doc-rfc package. Attached is my change on the Ubuntu package of doc-rfc as a debdiff. Till diff -Nru doc-rfc-20170121/debian/changelog doc-rfc-20170121/debian/changelog --- doc-rfc-20170121/debian/changelog 2017-01-24 23:35:26.0 +0100 +++ doc-rfc-20170121/debian/changelog 2018-04-12 12:08:58.0 +0200 @@ -1,3 +1,12 @@ +doc-rfc (20170121-1ubuntu1) bionic; urgency=medium + + * In the autopkgtest replaced the call of pstotext by ps2txt +as pstotext upstream is unmaintained for years and stopped +working with Ghostscript whereas ps2txt is part of ghostscript +(LP: #1762778). + + -- Till Kamppeter <till.kamppe...@gmail.com> Thu, 12 Apr 2018 12:08:58 +0200 + doc-rfc (20170121-1) unstable; urgency=medium * New upstream version diff -Nru doc-rfc-20170121/debian/tests/control doc-rfc-20170121/debian/tests/control --- doc-rfc-20170121/debian/tests/control 2017-01-24 23:35:26.0 +0100 +++ doc-rfc-20170121/debian/tests/control 2018-04-12 11:59:46.0 +0200 @@ -1,2 +1,2 @@ Tests: simple pspdf-parsing -Depends: @, pstotext, poppler-utils, dhelp, lynx, libcgi-pm-perl +Depends: @, ghostscript, poppler-utils, dhelp, lynx, libcgi-pm-perl diff -Nru doc-rfc-20170121/debian/tests/pspdf-parsing doc-rfc-20170121/debian/tests/pspdf-parsing --- doc-rfc-20170121/debian/tests/pspdf-parsing 2017-01-24 23:35:26.0 +0100 +++ doc-rfc-20170121/debian/tests/pspdf-parsing 2018-04-12 12:08:58.0 +0200 @@ -1,6 +1,6 @@ #!/bin/bash -echo "Tests that all files are parseable by p*totext," +echo "Tests that all files are parseable by p*t*xt," echo "in order to suport dhelp integration." set -e @@ -10,12 +10,12 @@ for i in *.ps; do echo " - testing $i" - pstotext $i > /dev/null + ps2txt $i > /dev/null done for i in *.ps.gz; do echo " - testing $i" - zcat $i | pstotext > /dev/null + zcat $i | ps2txt > /dev/null done for i in *.pdf; do
Bug#883554: cups keeps breaking network printer with implicitclass:
On 12/14/2017 02:54 PM, Brian Potkin wrote: On Thu 14 Dec 2017 at 02:28:18 -0600, David Fries wrote: On Tue, Dec 12, 2017 at 08:01:44PM +, Brian Potkin wrote: 5. 'lpstat -t' should show a print queue with an implicitclass URI which has automatically been set up by cups-browsed, There should be a non-empty PPD in /etc/cups/ppd and you should be able to print to the queue. Does not print. Correct it lists, implicitclass URI, -rw-r- 1 root lp 123838 Dec 14 01:13 /etc/cups/ppd/Canon_BJC-2100.ppd echo "." | lpr -PCanon_BJC-2100 Maybe not significant, but my PPD's size is 24331. On the server it is 24362. This is OK. cups-browsed edits the PPD to avoid duplicate filtering of the job. Please answer my other mail. Till
Bug#883554: cups keeps breaking network printer with implicitclass:
Can you please run the command avahi-browse -v -t -r --all and post its output here? Please also edit /etc/cups/cups-browsed.conf, to have a line DebugLogging file without "#" in the beginning. Restart cups-browsed. Wait some seconds and stop cups-browsed. Then attach the file /var/log/cups/cups-browsed_log to your answer. Till
Bug#871917: hplip-gui: hp-toolbox will not start
Bug reported upstream to HP (and to Ubuntu) as: https://bugs.launchpad.net/debian/+source/hplip/+bug/1710378
Bug#852436: cups-browsed uses 100% CPU - SOLVED (patch attached)
Thank you very much for the patch.
I have applied it now to he upstream code of cups-filters (BZR rev. 7672).
Note that the error message
"Unable to create/modify CUPS queue (Success)!"
is actually caused by another bug which I had already fixed earlier. The
queue has actually been created but CUPS has returned a non-zero value.
In the beginning I assumed all non-zero values as errors, but CUPS has
some non-zero values which are not errors. In cups-filters 1.13.4 I have
fixed this and since then successfully created CUPS queue do not get
re-created repeatedly.
Till
On 08/09/2017 01:00 PM, Cédric Dufour - Idiap Research Institute wrote:
On 09/08/17 10:02, Cédric Dufour - Idiap Research Institute wrote:
I confirm this issue is still present is current Debian Stable/Stretch and
renders CUPS unusable in network printing environments.
I could backport the packages from testing or experimental, but then I would
miss the updates from the Debian Security team (and looking at the updates
history of CUPS filters/browsed in Debian OldStable/Jessie, it is not something
I'm looking forwards to)
I tracked down the issue to a timeout when 'cups-browsed' interacts with the local 'cups'
server ("cupsDoFileRequest" call).
The 'cups-browsed' hard-coded timeout for such operations is 3 seconds.
This timeout is the cause of the witnessed "Unable to create/modify CUPS queue
(Success)!" error messages (and 'cups-browsed' looping infinitely in attempts to add
the failing printers/queues)
For large (fancy ?) PPDs, the local 'cups' server can take up to 8 (!) seconds
to process the addition of a remote printer queue based on the PPD retrieved
from the (BrowsePoll-ed) server (as witnessed on a 3.4GHz Intel I7-2600K test
host, during wich one CPU core is stuck at 100%).
The attached patch file - for cups-filters 1.11.6 (Debian/Stretch) - allows one to configure the
timeouts of both local and remote 'cups-browsed' HTTP connections, thanks to the new
"HttpLocalTimeout" and "HttpRemoteTimeout" configuration settings. Setting the
former to 10 seconds fixed the issue with my troublesome PPDs/printers (INEO+ copiers).
Please note that this issue will still be present in 'cups-browsed' 1.16.0
along 'cups' 2.2.4, as backported from Testing and *verified* on Stretch.
(it should not be difficult to forward-port the attached patch, however)
I hope this patch can meet your approval for its addition in Debian patches
series and considered even for current Stable release (knowing that enterprise
environments with big printing beasts will be bound to stumble on the same
problem).
And do you have a privileged contact to propose this patch be included upstream
?
Best,
Cédric
Bug#723835: cups-browsed: Segfault with multiple BrowsePoll directives
Fixed in cups-filters upstream, BZR rev. 7667, will be included in the cups-filters 1.16.1 release. Thank you for your bug report with backtrace. Problem was an uninitialized pointer which made the crash always happen when a BrowsePolled printer has no "Location" field in its IPP attributes. Till
