On Sat, 2013 Jun 22 4:31+0200, Vincent Lefevre wrote:
>
> At my lab, the admins tell us the hostname of the print server, and
> sometimes the print names, that's all.
Considering that "/version=1.1" is not supported on older CUPS clients,
admins [who know about the directive] could well be disincl
On Fri, 2013 Jun 21 15:44-0400, Michael Sweet wrote:
>
> My experience with large sites has been the opposite - most places
> I've worked with have departmental print servers with manually-added
> queues (either raw queues or the OS X-style local queue/PPD forwarding
> to the server). They typical
On Fri, 2013 Jun 21 9:29-0400, Michael Sweet wrote:
>
> Well, before we go off and spend extra engineering time on this, how
> widespread is the use of client.conf in the Linux world? On OS X it
> was pretty-much non-existent (less than 1% of users, based on bug
> reports) and since 10.8 *is* non-
On Thu, 2013 Jun 20 11:39-0400, Michael Sweet wrote:
>
> In both cases the server is returning a "bad request" error instead of
> "version not supported". We could (and probably should) change lpq to
> report the real error, but that will just yield:
>
> lpq: Bad Request
>
> And since "Bad Req
I've noticed a behavior quite similar to this, on Ubuntu, as a result of
the below-linked bug:
https://bugs.launchpad.net/bugs/1069671
In a nutshell: Running the CUPS 1.6.1 client locally, talking to a
remote CUPS 1.5.x (or older) server. The client cannot communicate with
the server, due to
Package: cups-client
Version: 1.6.2-3
The CUPS client recently gained new configuration logic to allow the IPP
version of a CUPS server to be specified, whether on the command line
(-h option), in the CUPS_SERVER environment variable, or in the
/etc/cups/client.conf config file. Some examples of t
