Bug#769058: cups: "/usr/lib/cups/filter/foomatic-rip failed" after last CUPS update
On Fri, Dec 05, 2014 at 07:17:51PM +0000, Brian Potkin wrote:
>Thank you for your analysis, Tom.
>
>On Mon 01 Dec 2014 at 19:29:22 -0430, Tom Maneiro wrote:
>
>> 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,
>
>Having data compressed by the IPP backend is new(ish) and documented at
>
> http://www.cups.org/str.php?L4168
>
>> 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).
>
>Your previous log records an unhappy USB transaction:
>
> D [30/Nov/2014:16:53:22 -04-30] [Job 354] Read thread still active, aborting the pending read...
>
>I do not know what the significance is.
>
>> 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.
>
>The file backend makes a call to gziptoany, which uncompresses the file
>taken from the spool.
>
>Two other (possibly simpler) methods:
>
>1. On a client have a queue with '-v ipp://<IP>/printers/CL3005W?compression=none'
>
>2. Set up clients and server as you originally had them. Delete the two
> *cupsFilter lines from the foo2zjs PPD on the server and add
>
> *cupsFilter "application/vnd.cups-pdf 0 -"'
>
> '-' passes through the data without doing anything apart from running
> gziptoany when the file is taken out of the spool.
Is there any sign of this being filed/fixed upstream any time soon?
I've just had to change all of my shared printer definitions for my
local network. Wheezy clients were working fine, jessie clients were
just dropping compressed files on the server that it barfed on. I've
just told all my clients explicitly to send as postscript now, and
I've got things working again. This setup had been working fine for
years.
Depressingly, CUPS seems to be getting steadily worse over time for
me. :-(
--
Steve McIntyre, Cambridge, UK. steve@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...
Reply to: