Bug#769058: cups: "/usr/lib/cups/filter/foomatic-rip failed" after last CUPS update
Package: cups
Followup-For: Bug #769058
Looks like my ISP mailservers are acting funky lately. Ah well, time for an
angry phone call to CS. (thanks for bouncing the message, guys!). I'm using
Reportbug this time.
Anyway, I've found the last missing piece on this puzzle. I decided to peek at
/var/spooler/cups while a print job was in transit down to the printer. And
sure enough, instead of uncompresssed PJL+LAVAFLOW data, I found that the job
data was compressed (gzipped, actually). Of course, my printer doesn't know
what to do with gzipped LAVAFLOW, because it can only deal with raw
uncompressed streams (luckily for me, this mishap didn't ended into a ton of
printed garbage sheets - the printer just silently discarded the data assuming
it was corrupt, and this also explains why there were no errors logged by the
CUPS USB backend since the printer didn't tell that something went wrong with
the data sent). This also explains why the simple cat print.file > /dev/usb/lp0
worked fine, yet a simple CUPS backend script [1] doing exactly the same
yielded more failure
Sadly, disabling gzip compression in CUPS isn't straigtforward, instead you're
expected to use a dummy shell script to force decompression if you're dealing
with raw queues [2]. The file:/ backend seems to do decompression due to its
nature, yet none of the other backends do it. After applying the workaround
noted in that message, I'm now able to print just fine.
Although there is no bug on CUPS this time, such recent changes (the whole
thing regarding FINAL_CONTENT_TYPE) aren't really documented in any end-user-
facing documentation - same as for the tidbit regarding gzip compression and
raw print queues. Again, I've been using the same print setup across all my
clients (several versions of Windows, Debian, Fedora, and even Mac), and
servers (all the way from Debian Lenny, up to Wheezy), but I haven't see
nowhere that such setup (send formatted print data to a non-raw print queue) is
no longer supported upstream. Expect breakage and pain for a lot of users (not
that dealing with printers is funny nowadays, but I digress).
Feel free to close this bug, but please make sure to point such things
somewhere in the documentation, where end-users can actually find it.
[1]
https://en.opensuse.org/SDB:Using_Your_Own_Backends_to_Print_with_CUPS#A_careless_backend_for_a_single_USB_printer
[2] http://www.cups.org/pipermail/cups/2011-September/023699.html
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-updates')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=es_VE.UTF-8, LC_CTYPE=es_VE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages cups depends on:
ii cups-client 1.7.5-7
ii cups-common 1.7.5-7
ii cups-core-drivers 1.7.5-7
ii cups-daemon 1.7.5-7
it cups-filters 1.0.61-4
ii cups-ppdc 1.7.5-7
ii cups-server-common 1.7.5-7
ii debconf [debconf-2.0] 1.5.54
ii ghostscript 9.06~dfsg-1.1
ii libavahi-client3 0.6.31-4+b1
ii libavahi-common3 0.6.31-4+b1
ii libc-bin 2.19-13
ii libc6 2.19-13
ii libcups2 1.7.5-7
ii libcupscgi1 1.7.5-7
ii libcupsimage2 1.7.5-7
ii libcupsmime1 1.7.5-7
ii libcupsppdc1 1.7.5-7
ii libgcc1 1:4.9.1-19
ii libstdc++6 4.9.1-19
ii libusb-1.0-0 2:1.0.19-1
ii lsb-base 4.1+Debian13+nmu1
ii poppler-utils 0.26.5-2
ii procps 2:3.3.9-8
Versions of packages cups recommends:
ii avahi-daemon 0.6.31-4+b1
ii colord 1.2.1-1+b1
it cups-filters [ghostscript-cups] 1.0.61-4
ii printer-driver-gutenprint 5.2.10-3
Versions of packages cups suggests:
ii cups-bsd 1.7.5-7
pn cups-pdf <none>
ii foomatic-db-compressed-ppds [foomatic-db] 20141016-1
ii hplip 3.14.6-1+b2
ii printer-driver-hpcups 3.14.6-1+b2
ii smbclient 2:4.1.13+dfsg-2
ii udev 215-6
-- debconf information:
cupsys/raw-print: true
cupsys/backend: lpd, socket, usb, snmp, dnssd
Reply to: