reopen 704238
thanks
Hi,
On Thu, Jun 20, 2013 at 05:44:52PM +0200, Didier 'OdyX' Raboud wrote:
forwarded 704238 rdar://problem/14216262
# That's Apple closed internal bug tracker
thanks
Filed as the following bug in Apple's bug tracker:
rdar://problem/14216262 cups.org: Missing
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 disinclined
Daniel,
On 2013-06-20, at 11:38 PM, Daniel Richard G. sk...@iskunk.org wrote:
...
Now that it is possible to configure a new client to talk with an old
server, and that the means of doing so is documented (in Debian
currently, and upstream soon), we need this problem to be diagnose-able.
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*
Daniel,
On 2013-06-21, at 2:20 PM, Daniel Richard G. sk...@iskunk.org wrote:
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
On 2013-06-21 15:44:07 -0400, Michael Sweet wrote:
Presumably the admins telling them (or configuring their system) to
use the server will instruct them accordingly. Or perhaps run server
software newer than 4 years old?
At my lab, the admins tell us the hostname of the print server, and
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 typically
On 2013-06-20 10:41:56 -0400, Michael Sweet wrote:
On 2013-06-06, at 2:59 AM, Didier 'OdyX' Raboud o...@debian.org wrote:
...
ServerName cups.example.com/version=1.1
Indeed. That's confirmed to address Vincent's issue. Although it's kinda
surprising that it's impossible to detect
On 2013-06-20 10:46:00 -0400, Michael Sweet wrote:
Given that this is only a problem for users depending on the
ServerName directive in client.conf, it seemed much more practical
(and reliable) to have the user/administrator specify any version
limitations there.
The initial problem is that
Vincent,
On 2013-06-20, at 10:55 AM, Vincent Lefevre vinc...@vinc17.net wrote:
...
We *did* try tracking the supported IPP version in the first version
of the patch for this issue, but it didn't work reliably. Forcing
the issue in client.conf seemed the safest approach.
OK. So, the
Didier,
On 2013-06-06, at 2:59 AM, Didier 'OdyX' Raboud o...@debian.org wrote:
...
ServerName cups.example.com/version=1.1
Indeed. That's confirmed to address Vincent's issue. Although it's kinda
surprising that it's impossible to detect that at runtime, but that's an
upstream
Vincent,
On 2013-06-06, at 7:15 AM, Vincent Lefevre vinc...@vinc17.net wrote:
...
Opinions ?
Agreed, though detecting the IPP version would be much better
(isn't the negotiation part of the protocol?).
Not really. There is some support for detecting supported versions and
reporting when
Vincent,
On 2013-06-20, at 11:05 AM, Vincent Lefevre vinc...@vinc17.net wrote:
On 2013-06-20 10:46:00 -0400, Michael Sweet wrote:
Given that this is only a problem for users depending on the
ServerName directive in client.conf, it seemed much more practical
(and reliable) to have the
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 Request can be
forcemerge 704238 711192
severity 704238 important
tags 704238 +patch -moreinfo
thanks
Hi Daniel, and thanks for your bugreport,
Vincent: I'm hereby merging both 704238 and 711192 as the latter is and
occurence of the first. Also, thanks for testing the four possibilities, it
confirms Daniel's
On 2013-06-06 08:59:19 +0200, Didier 'OdyX' Raboud wrote:
Vincent: I'm hereby merging both 704238 and 711192 as the latter is
and occurence of the first. Also, thanks for testing the four
possibilities, it confirms Daniel's documentation below.
I've also tested that the following worked:
On Thu 06 Jun 2013 at 08:59:19 +0200, Didier 'OdyX' Raboud wrote:
Several minor points:
+PThe default IPP version is 2.0 but can be overriden by adding a slash
followed by CODE/version=/CODE and the desired IPP version (can be 1.0 or
1.1)./P
Is '. . by adding a slash followed . . . '
Control: tags -1 +pending
Hi all,
I have pushed the proposed patch with Brian and Vincent's fixes, thank you!
It'll be part of the next upload.
Commit: http://anonscm.debian.org/gitweb/?p=pkg-
cups/cups.git;a=commit;h=123306535e3fade1a0f26699b72dde18437a4d6e
Upstream patch:
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
19 matches
Mail list logo
