Bug#769058: cups: "/usr/lib/cups/filter/foomatic-rip failed" after last CUPS update
El 26/11/14 11:50, Brian Potkin escribió:
On Tue 25 Nov 2014 at 10:58:01 -0430, Tom Maneiro wrote:
Sorry for the delay, it has been a very busy week for me, and for some reason
my last reply never arrived to the tracker.
No problem.
I tried setting the print queue to raw, but... I can't still print.
I even went and created a separate queue for the CL3005W in raw mode (device
URI is "usb://KONICA%20MINOLTA/mc1600W?serial=06796", and I named the queue
"CL3005Wr"), then I setup one of my remote clients to print to it. Not only
nothing came out of the printer, this time I didn't even got any error on the
server! Dunno if somehow the print job got mangled and the printer rejected the
bad data (I did noticed that the printer "Ready" LED blinked briefly during one
of the failed attempts), or it simply went to nowhere - I'll have to recheck
this later.
I altered the queue on an unstable client we had in a previous mail to
lpadmin -p test -v ipp://192.168.7.65:631/printers/CL3005Wr -E -m<the 1600W foo2zjs PPD>
On a Wheezy server sharing its queues I did
lpadmin -p CL3005Wr -v file:/tmp/TEST -E -m raw
Printing /etc/debian_version produces TEST, which has the same size and
is the same type as the test file produced previously on the client.
With your printer I would expect TEST to print from the server with
something like 'cat TEST> /dev/usb/lp0' and by changing the device URI
to "usb://KONICA%20MINOLTA/mc1600W?serial=06796". I am at a loss to
understand why you have been unable to.
I've tried doing exactly that:
- Modify the server queue to print to a file (in my case: /tmp/dump.prn)
- Modify the client to print to the new raw queue
- Sent a print job from the client to the server (in this case: the
quintessential CUPS test page)
- Checked everything:
tomman@saki:/tmp$ ls -l
total 112
-rw------- 1 root root 107977 nov 30 16:50 dump.prn
tomman@saki:/tmp$ sudo chmod 666 dump.prn
tomman@saki:/tmp$ file dump.prn
dump.prn: HP Printer Job Language data
- Manually sent the print file to the printer:
root@saki:/tmp# cat dump.prn > /dev/usb/lp0
- BAM! A shiny test page came hot out of the printer, in full color!
Sadly, I got nothing when I set the raw print queue on the server to the
usb:/ URI. No errors of any kind are logged into CUPS error_log:
I [30/Nov/2014:16:53:07 -04-30] [Job 354] Started backend
/usr/lib/cups/backend/usb (PID 23391)
D [30/Nov/2014:16:53:07 -04-30] [Job 354] Printing on printer with URI:
usb://KONICA%20MINOLTA/mc1600W?serial=06796
D [30/Nov/2014:16:53:07 -04-30] [Job 354] libusb_get_device_list=3
D [30/Nov/2014:16:53:07 -04-30] [Job 354] STATE: +connecting-to-device
D [30/Nov/2014:16:53:07 -04-30] [Job 354] STATE: -connecting-to-device
D [30/Nov/2014:16:53:07 -04-30] [Job 354] Device protocol: 2
I [30/Nov/2014:16:53:07 -04-30] [Job 354] Enviando datos a la impresora.
D [30/Nov/2014:16:53:07 -04-30] [Job 354] Set job-printer-state-message
to "Enviando datos a la impresora.", current level=INFO
D [30/Nov/2014:16:53:07 -04-30] [Job 354] PAGE: 1 1
D [30/Nov/2014:16:53:07 -04-30] [Job 354] Read 8192 bytes of print data...
D [30/Nov/2014:16:53:07 -04-30] [Job 354] Wrote 8192 bytes of print data...
D [30/Nov/2014:16:53:07 -04-30] [Job 354] Sending print file, 8192 bytes...
...snip...
D [30/Nov/2014:16:53:14 -04-30] [Job 354] Sending print file, 98304 bytes...
D [30/Nov/2014:16:53:14 -04-30] [Job 354] Read 6729 bytes of print data...
D [30/Nov/2014:16:53:15 -04-30] [Job 354] Wrote 6729 bytes of print data...
D [30/Nov/2014:16:53:15 -04-30] [Job 354] Sending print file, 105033
bytes...
D [30/Nov/2014:16:53:15 -04-30] [Job 354] Sent 105033 bytes...
D [30/Nov/2014:16:53:15 -04-30] [Job 354] Waiting for read thread to exit...
D [30/Nov/2014:16:53:22 -04-30] [Job 354] Read thread still active,
aborting the pending read...
I [30/Nov/2014:16:53:23 -04-30] [Job 354] Job completed.
D [30/Nov/2014:16:53:24 -04-30] [Job 354] Unloading...
D [30/Nov/2014:16:53:27 -04-30] [Job 354] Loading attributes...
D [30/Nov/2014:16:54:46 -04-30] [Job 354] Unloading...
Contrast this with a job printed to a file:
I [30/Nov/2014:16:50:04 -04-30] [Job 353] Started filter
/usr/lib/cups/filter/gziptoany (PID 23347)
D [30/Nov/2014:16:50:04 -04-30] [Job 353] PAGE: 1 1
I [30/Nov/2014:16:50:04 -04-30] [Job 353] Job completed.
D [30/Nov/2014:16:50:05 -04-30] [Job 353] Unloading...
D [30/Nov/2014:16:50:05 -04-30] [Job 353] Loading attributes...
D [30/Nov/2014:16:51:07 -04-30] [Job 353] Unloading...
Is the CUPS USB backend acting unexpectedly this time?
Remote Windows clients can still print to the unmodified queue, sane as for
anything running older CUPS versions. In fact, I've been using the same
server/client setup since 2007 or so, in several Linux flavors (including older
Debian Sid servers). using clients both in Windows and several Linux distros,
and only in this year I had CUPS patches break it, because SOMEHOW it's now
considered a "you're doing it wrong" case. At most I think the whole
FINAL_CONTENT_TYPE should be exposed as an user-modifiable option somewhere in
the config files.
Considerations such as altering the behaviour of cups are above my pay
grade. :)
Regards,
Brian.
Reply to: