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

[Brian Potkin <claremont102@gmail.com>]

On Mon 17 Nov 2014 at 19:09:50 -0430, Tom Maneiro wrote:

> tomman@tomman-lp:~$ ls -l /etc/debian_version
> -rw-r--r-- 1 root root 11 may  5  2013 /etc/debian_version
> 
> tomman@tomman-lp:~$ ls -l /home/tomman/test
> -rw-rw-rw- 1 root root 1126 nov 17 18:59 /home/tomman/test
> 
> tomman@tomman-lp:~$ file /home/tomman/test
> /home/tomman/test: HP Printer Job Language data
> 
> (actually, it's the raw LAVAFLOW stream, encapsulated into PJL)
> 
> And here is the PPD listing on the print server (the old box running
> Wheezy):

All good. I get this and a very similar error_log to yours. Note that
there is no failure in any filter, so processing on the client is not
suspect. Your previous error_log showed a filter failure on the server
and this one confirms that.

> tomman@saki:~$ ls -l /etc/cups/ppd
> total 52
> -rw-r--r-- 1 root root 25044 jun 12  2013 CL3005W.ppd
> -rw-r--r-- 1 root root 20956 feb 26  2013 PDF.ppd

The client produces a file 'test' which is LAVAFLOW stream encapsulated
into PJL. This file is in an ideal state to be sent *directly* to the
printer. However, 'ls -l /etc/cups/ppd' indicates that it is subject to
further processing by CL3005W.ppd on the server. This is a questionable
practice.

Looking at the error_log we see

> D [17/Nov/2014:18:59:19 -04-30] [Job 55] envp[29]="FINAL_CONTENT_TYPE=application/vnd.cups-pdf"

This is fine but, in the light of the extra processing taking place on
the server, it leads to printing not taking place.

Now let's look at the changelog for cups

   cups (1.7.5-6) unstable; urgency=medium

     * Dropped the FINAL_CONTENT_TYPE revert, stick back to upstream, following
       RedHat's analysis

and at

   https://bugzilla.redhat.com/show_bug.cgi?id=1149245

There is no bug in cups but you have been caught out by having a less
than ideal setup on your server.

1. Determine the present device URI for the printer with 'lpstat -t'.

2. Delete the print queue with 'lpadmin -x CL3005W'.

3. Re-establish the print queue with

       lpadmin -p CL3005W -v <whatever> -E -m raw

Can you now print?

Regards,

Brian.