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

Bug#769058: cups: "/usr/lib/cups/filter/foomatic-rip failed" after last CUPS update



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.

Regards,

Brian.


Reply to: