Processing commands for cont...@bugs.debian.org:
> reopen 704238
Bug #704238 {Done: Didier Raboud } [cups-client] Need to
document the CUPS client's new server-version option
Bug #711192 {Done: Didier Raboud } [cups-client] cups-client:
clients (lpstat, lpq...) no longer work via http
'reopen' m
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:
> >
> > cups.org: Missing documentation fo
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 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
som
Daniel,
On 2013-06-21, at 2:20 PM, "Daniel Richard G." 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 non-existent (l
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-
Daniel,
On 2013-06-20, at 11:38 PM, Daniel Richard G. 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.
Well, before we
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
Vincent,
On 2013-06-20, at 11:05 AM, Vincent Lefevre 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 user/administrator s
Vincent,
On 2013-06-06, at 7:15 AM, Vincent Lefevre 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 a version i
Processing commands for cont...@bugs.debian.org:
> forwarded 704238 rdar://problem/14216262
Bug #704238 {Done: Didier Raboud } [cups-client] Need to
document the CUPS client's new server-version option
Bug #711192 {Done: Didier Raboud } [cups-client] cups-client:
clients (lpstat, lpq...) no long
Didier,
On 2013-06-06, at 2:59 AM, Didier 'OdyX' Raboud 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 decision…
It i
Vincent,
On 2013-06-20, at 10:55 AM, Vincent Lefevre 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 protocol doesn't
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 tha
On 2013-06-20 10:41:56 -0400, Michael Sweet wrote:
> On 2013-06-06, at 2:59 AM, Didier 'OdyX' Raboud 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
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: http://anonscm.debia
Processing control commands:
> tags -1 +pending
Bug #704238 [cups-client] Need to document the CUPS client's new server-version
option
Bug #711192 [cups-client] cups-client: clients (lpstat, lpq...) no longer work
via http
Added tag(s) pending.
Added tag(s) pending.
--
704238: http://bugs.debi
On Thu 06 Jun 2013 at 08:59:19 +0200, Didier 'OdyX' Raboud wrote:
Several minor points:
> +The default IPP version is 2.0 but can be overriden by adding a slash
> followed by /version= and the desired IPP version (can be 1.0 or
> 1.1).
Is '. . by adding a slash followed . . . ' needed if
cont
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:
Se
Processing commands for cont...@bugs.debian.org:
> forcemerge 704238 711192
Bug #704238 [cups-client] Need to document the CUPS client's new server-version
option
Bug #711192 [cups-client] cups-client: clients (lpstat, lpq...) no longer work
via http
Severity set to 'normal' from 'grave'
Marked
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
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
23 matches
Mail list logo
