Filed as the following bug in Apple's bug tracker:
rdar://problem/14216472 cups.org: lp and lpr print the document on a
wrong printer
Will see about fixing this in the next 1.6.x update.
On 2013-06-10, at 10:57 AM, Didier 'OdyX' Raboud o...@debian.org wrote:
Hi Michael,
Could you
This may be related, but lpstat with a printer argument gives an
error:
ypig:~ lpstat lipucb-mono-1
lpstat: Bad Request
even though:
ypig:~ lpstat -a | grep lipucb-mono-1
lipucb-mono-1 accepting requests since 2013-06-11T11:04:54 CEST
--
Vincent Lefèvre vinc...@vinc17.net - Web:
Package: cups-client
Version: 1.6.2-8
Severity: grave
Tags: security
Justification: user security hole
I have the following options in .cups/lpoptions:
Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi
Default lipucb-mono-1
The lpq command gives as expected:
lipucb-mono-1 is ready
no entries
Control: severity -1 important
Control: tags -1 +moreinfo +unreproducible
Hi Vincent, and thanks for your bugreport,
Le lundi, 10 juin 2013 11.25:57, Vincent Lefevre a écrit :
I have the following options in .cups/lpoptions:
Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi
Default
On 2013-06-10 11:50:52 +0200, Didier 'OdyX' Raboud wrote:
But when I print a document with lpr file.pdf, I get nothing on
this printer. Then I tried: lp file.pdf, and I get nothing either
on this printer, but the following line was output in the terminal:
When trying here with either lpr
Hi again Vincent,
Le lundi, 10 juin 2013 12.56:33, Vincent Lefevre a écrit :
Well, this may be server dependent. I suspect a bug related to the
authentication mechanism. When I do lpq, authentication is not
required, so that its output is OK. However some printers need
authentication (the
Hi,
On 2013-06-10 13:27:47 +0200, Didier 'OdyX' Raboud wrote:
Can you provide the access rights of .cups/lpoptions?
$ ls -l ~/.cups/lpoptions
ypig:~ ls -l ~/.cups/lpoptions
-rw-r--r-- 1 vlefevre vlefevre 74 2013-02-01 16:29:37
/home/vlefevre/.cups/lpoptions
I've also done a strace
Hi again,
Le lundi, 10 juin 2013 13.27:47, Didier 'OdyX' Raboud a écrit :
Under the current rules, this bug doesn't fit the defintion of serious in my
reading.
As you brought this bug to debian-devel@ [0], let me explain in little more
details (which I thought were obvious) why I think this
If I output some messages in the cupsGetNamedDest() function
of cups/dest.c as shown below:
/*
* Get the printer's attributes...
*/
fprintf (stderr, cupsGetNamedDest: %s\n, name ? name : );
if (!_cupsGetDests(http, op, name, dest, 0, 0))
{
if (op == CUPS_GET_DEFAULT || (name
On 2013-06-10 15:48:18 +0200, Vincent Lefevre wrote:
If I output some messages in the cupsGetNamedDest() function
of cups/dest.c as shown below:
/*
* Get the printer's attributes...
*/
fprintf (stderr, cupsGetNamedDest: %s\n, name ? name : );
if (!_cupsGetDests(http, op,
Hi Michael,
Could you eventually take a look at http://bugs.debian.org/711848 ?
It's apparently a bug introduced with the enumerated destinations API in CUPS
1.6; it would be great if you could chime in. Vincent's analysis is below.
Cheers,
Didier Raboud, Debian CUPS co-maintainer
P.S. If
On 2013-06-10 16:57:22 +0200, Didier 'OdyX' Raboud wrote:
Hi Michael,
Could you eventually take a look at http://bugs.debian.org/711848 ?
It's apparently a bug introduced with the enumerated destinations API in CUPS
1.6; it would be great if you could chime in. Vincent's analysis is
12 matches
Mail list logo
