There are no lpoptions files anywhere on the clients. inetd.conf also
yields nothing interesting (nothing at all regarding CUPS/printing).
Running "lpoptions" yields this on my Jessie clients:
auth-info-required=none copies=1
device-uri=usb://KONICA%20MINOLTA/mc1600W?serial=06796 finishings=3
job-hold-until=no-hold job-priority=50 job-sheets=none,none
marker-change-time=0 number-up=1
printer-commands=AutoConfigure,Clean,PrintSelfTestPage
printer-info='DELCOP CL3005W' printer-is-accepting-jobs=true
printer-is-shared=true printer-location='TSDX Base ETG'
printer-make-and-model='KONICA MINOLTA magicolor 1600W Foomatic/foo2lava
(recommended)' printer-state=3 printer-state-change-time=1375290613
printer-state-reasons=none printer-type=8556572
printer-uri-supported=ipp://192.168.0.254:631/printers/CL3005W
On a Wheezy client I get a mostly identical output:
auth-info-required=none copies=1
device-uri=ipp://192.168.0.254:631/printers/CL3005W ICM=km2530_0
job-hold-until=no-hold job-priority=50 marker-change-time=0 number-up=1
printer-info='DELCOP CL3005W' printer-is-accepting-jobs=true
printer-is-shared=false printer-location='TSDX Base ETG'
printer-make-and-model='KONICA MINOLTA magicolor 1600W Foomatic/foo2lava
(recommended) on 192.168.0.254' printer-state=3
printer-state-change-time=1377000845 printer-state-reasons=none
printer-type=27430942
printer-uri-supported=ipp://192.168.0.254:631/printers/CL3005W
uuid=urn:uuid:94b24f15-aa7a-31fc-5cc7-5336fb7b3bdf
El 18/08/13 07:00, Brian Potkin escribió:
tags 719946 moreinfo
thanks
Hello Tom,
Your comprehensive report is appreciated.
On Fri 16 Aug 2013 at 23:28:44 -0430, Tom Maneiro wrote:
The problem with my Jessie/CUPS 1.6 clients is that they can't print to the
Wheezy/CUPS 1.5 printserver. After enabling debug logging on everything
(including the printserver, a Wheezy client which can print, and a Jessie
client that CAN'T print), I've noticed that while the Wheezy (and Windows)
clients send the print job data as "application/octet-stream" (so the server
does nothing but to directly pipe the data into the printer), while the exact
Are you sure the jobs are *sent* as application/octet-stream? The server
usually auto-types the file received?
same data (LAVAFLOW encapsulted into PJL) is sent by the Jessie clients as
"application/vnd.cups-pdf" (the server assumes that it's receiving a PDF... and
The likely case here is that the job is *sent* as application/vnd.cups-pdf.
Relevant log entries from the Wheezy print server:
- This Wheezy client can print:
D [16/Aug/2013:22:30:06 -04-30] [Job 169] Auto-typing file...
D [16/Aug/2013:22:30:06 -04-30] [Job 169] Request file type is
application/octet-stream.
I [16/Aug/2013:22:30:06 -04-30] [Job 169] File of type application/octet-stream queued by
"tomman".
The client sent the file without specifying its mime type. The server
sorted out the type.
- On the other side, this Jessie client can't print at all on the same server
I [16/Aug/2013:22:38:33 -04-30] [Job 171] File of type application/vnd.cups-pdf queued by
"tomman".
No first two lines as with the Wheezy client. The Jessie client has
informed the server about the mime type. This could be done with
lp -d<print_QUEUE> -o document-format=application/vnd.cups-pdf<file>
Please examine the client for an lpoptions file in /etc/cups or ~/.cups
which contains "document-format". /etc/inetd.conf may be worth a look at
too.
Regards,
Brian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
