Debian Bug report logs - #704238
Need to document the CUPS client's new server-version option

version graph

Package: cups-client; Maintainer for cups-client is Debian Printing Team <debian-printing@lists.debian.org>; Source for cups-client is src:cups.

Reported by: "Daniel Richard G." <skunk@iSKUNK.ORG>

Date: Sat, 30 Mar 2013 06:21:01 UTC

Severity: important

Tags: patch

Merged with 711192

Found in versions cups/1.6.2-3, cups/1.6.2-8

Fixed in version cups/1.6.2-10

Done: Didier Raboud <odyx@debian.org>

Bug is archived. No further changes may be made.

Forwarded to rdar://problem/14216262

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Sat, 30 Mar 2013 06:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Daniel Richard G." <skunk@iSKUNK.ORG>:
New Bug report received and forwarded. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Sat, 30 Mar 2013 06:21:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: "Daniel Richard G." <skunk@iSKUNK.ORG>
To: Debian BTS <submit@bugs.debian.org>
Subject: Need to document the CUPS client's new server-version option
Date: Sat, 30 Mar 2013 02:17:23 -0400
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 the syntax:

    $ lpr -h cups.example.com/version=1.1 foo.ps

    $ CUPS_SERVER=cups.example.com/version=1.1 lpr foo.ps

    ServerName cups.example.com/version=1.1

Being able to specify the server's IPP version is vitally important---
the CUPS client currently defaults to IPP 2.0, and if the server talks
1.1 or older, the client cannot downgrade the protocol automatically and
thus cannot communicate at all with the server. Details of the problem
are described in this upstream bug report:

    https://www.cups.org/str.php?L4231

This information should be of interest to anyone using CUPS in a client-
only configuration, because the IPP version default changed for the new
1.6.x series and thus client-only users upgrading from 1.5.x may find
that they mysteriously can't print anymore. (Indeed, this happened to
me, and the problem was *not* easy to diagnose.)

The new server-version option needs to be documented in the cups-client
package's example client.conf file. Mention of it should probably be
added to README.Debian. Furthermore, because of the potential for
breakage when upgrading from 1.5.x, I believe a notice in a package
maintainer script would be warranted (perhaps limited to systems that do
not have the "cups" server package installed).



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Thu, 06 Jun 2013 07:00:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Didier 'OdyX' Raboud" <odyx@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Thu, 06 Jun 2013 07:00:13 GMT) Full text and rfc822 format available.

Message #10 received at 704238@bugs.debian.org (full text, mbox):

From: "Didier 'OdyX' Raboud" <odyx@debian.org>
To: "Daniel Richard G." <skunk@iskunk.org>, 704238@bugs.debian.org, 711192@bugs.debian.org, Vincent Lefevre <vincent@vinc17.net>
Cc: Michael Sweet <msweet@apple.com>
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Thu, 6 Jun 2013 08:59:19 +0200
[Message part 1 (text/plain, inline)]
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 documentation below.

CC'ing Michael as cups's STR bug tracker is not online yet.

Le samedi, 30 mars 2013 07.17:23, Daniel Richard G. a écrit :
> 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 the syntax:
> 
>     $ lpr -h cups.example.com/version=1.1 foo.ps
> 
>     $ CUPS_SERVER=cups.example.com/version=1.1 lpr foo.ps
> 
>     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…

> This information should be of interest to anyone using CUPS in a client-
> only configuration, because the IPP version default changed for the new
> 1.6.x series and thus client-only users upgrading from 1.5.x may find
> that they mysteriously can't print anymore. (Indeed, this happened to
> me, and the problem was *not* easy to diagnose.)

I can't disagree. ;)

> The new server-version option needs to be documented in the cups-client
> package's example client.conf file. Mention of it should probably be
> added to README.Debian. Furthermore, because of the potential for
> breakage when upgrading from 1.5.x, I believe a notice in a package
> maintainer script would be warranted (perhaps limited to systems that do
> not have the "cups" server package installed).

Maintainer script prompt for a remote server incompatibility is probably 
overkill (and we usually try very hard to avoid these prompts), but I propose 
the attached patch which mentions this /version= possibility in two places 
upstream: man client.conf and doc/help/ref-client-conf.html.

On the Debian packaging side, I propose to add a cups-client NEWS entry (which 
one is _really_ supposed to read across upgrades), and amend the client.conf 
example file shipped in the source as debian/client.conf (which I'm not sure 
is installed or used anywhere, but that at least makes the source consistent). 

Opinions ?

Cheers,

OdyX
[mention-ipp-version-specifier-in-man-and-ref.patch (text/x-patch, attachment)]
[0001-Add-a-cups-client.NEWS-notice-a-cups-client-manpage-.patch (text/x-patch, attachment)]

Marked as found in versions cups/1.6.2-8. Request was from "Didier 'OdyX' Raboud" <odyx@debian.org> to control@bugs.debian.org. (Thu, 06 Jun 2013 07:00:24 GMT) Full text and rfc822 format available.

Added tag(s) moreinfo. Request was from "Didier 'OdyX' Raboud" <odyx@debian.org> to control@bugs.debian.org. (Thu, 06 Jun 2013 07:00:25 GMT) Full text and rfc822 format available.

Merged 704238 711192 Request was from "Didier 'OdyX' Raboud" <odyx@debian.org> to control@bugs.debian.org. (Thu, 06 Jun 2013 07:00:26 GMT) Full text and rfc822 format available.

Severity set to 'important' from 'normal' Request was from "Didier 'OdyX' Raboud" <odyx@debian.org> to control@bugs.debian.org. (Thu, 06 Jun 2013 07:00:27 GMT) Full text and rfc822 format available.

Added tag(s) patch. Request was from "Didier 'OdyX' Raboud" <odyx@debian.org> to control@bugs.debian.org. (Thu, 06 Jun 2013 07:00:29 GMT) Full text and rfc822 format available.

Removed tag(s) moreinfo. Request was from "Didier 'OdyX' Raboud" <odyx@debian.org> to control@bugs.debian.org. (Thu, 06 Jun 2013 07:00:31 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Thu, 06 Jun 2013 11:18:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Lefevre <vincent@vinc17.net>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Thu, 06 Jun 2013 11:18:04 GMT) Full text and rfc822 format available.

Message #27 received at 704238@bugs.debian.org (full text, mbox):

From: Vincent Lefevre <vincent@vinc17.net>
To: Didier 'OdyX' Raboud <odyx@debian.org>
Cc: "Daniel Richard G." <skunk@iskunk.org>, 704238@bugs.debian.org, 711192@bugs.debian.org, Michael Sweet <msweet@apple.com>
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Thu, 6 Jun 2013 13:15:33 +0200
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:

ServerName lip-printserver1.lip.ens-lyon.fr:631/version=1.1

> Maintainer script prompt for a remote server incompatibility is
> probably overkill (and we usually try very hard to avoid these
> prompts), but I propose the attached patch which mentions this
> /version= possibility in two places upstream: man client.conf and
> doc/help/ref-client-conf.html.

There's a small mistake:

+<P>The 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>

You should say either "by adding <CODE>/version=</CODE> and the
desired IPP version [...]" or "by adding a slash followed by
<CODE>version=</CODE> and the desired IPP version [...]",
otherwise there would be 2 slashes.

and in cups-client.NEWS, replace "explicitely" by "explicitly".

> On the Debian packaging side, I propose to add a cups-client NEWS
> entry (which one is _really_ supposed to read across upgrades), and
> amend the client.conf example file shipped in the source as
> debian/client.conf (which I'm not sure is installed or used
> anywhere, but that at least makes the source consistent).
> 
> Opinions ?

Agreed, though detecting the IPP version would be much better
(isn't the negotiation part of the protocol?).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Thu, 06 Jun 2013 11:39:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Brian Potkin <claremont102@gmail.com>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Thu, 06 Jun 2013 11:39:09 GMT) Full text and rfc822 format available.

Message #32 received at 704238@bugs.debian.org (full text, mbox):

From: Brian Potkin <claremont102@gmail.com>
To: Didier 'OdyX' Raboud <odyx@debian.org>, 711192@bugs.debian.org
Cc: "Daniel Richard G." <skunk@iskunk.org>, 704238@bugs.debian.org, Vincent Lefevre <vincent@vinc17.net>, Michael Sweet <msweet@apple.com>
Subject: Re: Bug#711192: Bug#704238: Need to document the CUPS client's new server-version option
Date: Thu, 6 Jun 2013 12:36:09 +0100
On Thu 06 Jun 2013 at 08:59:19 +0200, Didier 'OdyX' Raboud wrote:

Several minor points:

> +<P>The 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 . . . ' needed if <CODE></CODE>
contains '/version='?

> +  From Cups 1.6, the default IPP version for requests is now 2.0. For
> +  remote connections such as configured with an explicit ServerName in
> +  /etc/cups/cups-client.conf, an older IPP version such as 1.1 or even
> +  1.0 might need to be explicitely set for printing to keep working, for
> +  example:
> +
> +    ServerName remote-print-server.example.com/version=1.1
> +
> + -- Didier Raboud <odyx@debian.org>  Thu, 06 Jun 2013 08:05:57 +0200

     From cups 1.6 the default IPP version for requests is 2.0. For
     remote connections configured with ServerName in
     /etc/cups/cups-client.conf, an older IPP version such as 1.1 or even
     1.0 might need to be explicitly set for printing to keep working. For
     example:

1. 'cups' or 'CUPS', surely?

2. A comma isn't needed after '1.6'.

3. I'd remove what may be seen as some redundant words and phrases.

4. 'explicitely' should be 'explicitly'.

5. A full stop or semi-colon is better after 'working'.

Regards,

Brian.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Thu, 06 Jun 2013 12:51:25 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Didier 'OdyX' Raboud" <odyx@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Thu, 06 Jun 2013 12:51:25 GMT) Full text and rfc822 format available.

Message #37 received at 704238@bugs.debian.org (full text, mbox):

From: "Didier 'OdyX' Raboud" <odyx@debian.org>
To: Brian Potkin <claremont102@gmail.com>, Vincent Lefevre <vincent@vinc17.net>
Cc: "Daniel Richard G." <skunk@iskunk.org>, 704238@bugs.debian.org, Michael Sweet <msweet@apple.com>
Subject: Re: Bug#711192: Bug#704238: Need to document the CUPS client's new server-version option
Date: Thu, 6 Jun 2013 14:48:44 +0200
[Message part 1 (text/plain, inline)]
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.debian.org/gitweb/?p=pkg-
cups/cups.git;a=blob;f=debian/patches/mention-ipp-version-specifier-in-man-and-
ref.patch;h=47f465699030da04cd716501963c78ed321cb05b;hb=123306535e3fade1a0f26699b72dde18437a4d6e

Cheers,

OdyX
[signature.asc (application/pgp-signature, inline)]

Added tag(s) pending. Request was from "Didier 'OdyX' Raboud" <odyx@debian.org> to 704238-submit@bugs.debian.org. (Thu, 06 Jun 2013 12:51:25 GMT) Full text and rfc822 format available.

Reply sent to Didier Raboud <odyx@debian.org>:
You have taken responsibility. (Sun, 16 Jun 2013 15:21:05 GMT) Full text and rfc822 format available.

Notification sent to "Daniel Richard G." <skunk@iSKUNK.ORG>:
Bug acknowledged by developer. (Sun, 16 Jun 2013 15:21:05 GMT) Full text and rfc822 format available.

Message #44 received at 704238-close@bugs.debian.org (full text, mbox):

From: Didier Raboud <odyx@debian.org>
To: 704238-close@bugs.debian.org
Subject: Bug#704238: fixed in cups 1.6.2-9
Date: Sun, 16 Jun 2013 15:18:41 +0000
Source: cups
Source-Version: 1.6.2-9

We believe that the bug you reported is fixed in the latest version of
cups, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 704238@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Didier Raboud <odyx@debian.org> (supplier of updated cups package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sun, 16 Jun 2013 15:32:29 +0200
Source: cups
Binary: libcups2 libcupsimage2 libcupscgi1 libcupsmime1 libcupsppdc1 cups cups-daemon cups-client libcups2-dev libcupsimage2-dev libcupscgi1-dev libcupsmime1-dev libcupsppdc1-dev cups-bsd cups-common cups-server-common cups-ppdc cups-dbg
Architecture: source amd64 all
Version: 1.6.2-9
Distribution: unstable
Urgency: low
Maintainer: Debian Printing Team <debian-printing@lists.debian.org>
Changed-By: Didier Raboud <odyx@debian.org>
Description: 
 cups       - Common UNIX Printing System(tm) - server
 cups-bsd   - Common UNIX Printing System(tm) - BSD commands
 cups-client - Common UNIX Printing System(tm) - client programs (SysV)
 cups-common - Common UNIX Printing System(tm) - common files
 cups-daemon - Common UNIX Printing System(tm) - daemon
 cups-dbg   - Common UNIX Printing System(tm) - debugging symbols
 cups-ppdc  - Common UNIX Printing System(tm) - PPD manipulation utilities
 cups-server-common - Common UNIX Printing System(tm) - server common files
 libcups2   - Common UNIX Printing System(tm) - Core library
 libcups2-dev - Common UNIX Printing System(tm) - Development files CUPS library
 libcupscgi1 - Common UNIX Printing System(tm) - CGI library
 libcupscgi1-dev - Common UNIX Printing System(tm) - Development files for CGI libra
 libcupsimage2 - Common UNIX Printing System(tm) - Raster image library
 libcupsimage2-dev - Common UNIX Printing System(tm) - Development files CUPS image li
 libcupsmime1 - Common UNIX Printing System(tm) - MIME library
 libcupsmime1-dev - Common UNIX Printing System(tm) - Development files MIME library
 libcupsppdc1 - Common UNIX Printing System(tm) - PPD manipulation library
 libcupsppdc1-dev - Common UNIX Printing System(tm) - Development files PPD library
Closes: 704238 711192 711709 711868
Changes: 
 cups (1.6.2-9) unstable; urgency=low
 .
   [ Helge Kreutzmann ]
   * Update German manpages translation.
   * In ipptoolfile manpage, mention that possible attribute-name are
     defined in RFC2911, for clarity. (Closes: #711709)
 .
   [ Didier Raboud ]
   * Add a cups-client.NEWS notice, a cups-client manpage patch and amend
     the client.conf example file to inform about IPP default version
     change to 2.0 and circumvention measures. (Closes: #704238, #711192)
     - thanks to Brian Potkin
   * Reorder patches to have the manpages translation patch higher on the
     patch queue
   * Fix hyphen-correction typo
   * Update manpage translations with the recent changes
   * Drop outdated and not-applied colord-support patch.
 .
   [ Alexey Galakhov ]
   * Add patch to fix printer icc profiles registration in colord
     (Closes: #711868)
Checksums-Sha1: 
 29870b7d4709541a13faf681898f06a87a0e3483 3221 cups_1.6.2-9.dsc
 3506dba07b5174afb3a79c2390aa2cb1af160110 429377 cups_1.6.2-9.debian.tar.gz
 e54b49c68ff4d30caefda11b5816701a85fe1b11 281608 libcups2_1.6.2-9_amd64.deb
 7fe76ee2a04a8c3fade33251c71355337a888fa8 106382 libcupsimage2_1.6.2-9_amd64.deb
 9628e6cf0f8baea1048975a7bde548c276c62b0a 119978 libcupscgi1_1.6.2-9_amd64.deb
 bde35bc72d4c5f59b3a462c94a86ca9e80d40598 103128 libcupsmime1_1.6.2-9_amd64.deb
 32d331351213f0abe16b89fd0c6cf96d16b00026 142434 libcupsppdc1_1.6.2-9_amd64.deb
 bffdec67e8807a6d7cdabf62b0325f30462db5f6 355948 cups_1.6.2-9_amd64.deb
 568a8d14b2e068d82d2d00469d877844298a6b45 402152 cups-daemon_1.6.2-9_amd64.deb
 533c275f2802e044820d5860fafbb77a64b73bf6 201080 cups-client_1.6.2-9_amd64.deb
 7db89103674d36adcb10220decb6be0f37a0679e 351188 libcups2-dev_1.6.2-9_amd64.deb
 fd8d97dabcccc337a451b04fce48ca7b95710b42 21938 libcupsimage2-dev_1.6.2-9_amd64.deb
 29fa9fdd22dc47f1d94c3eceb8e438743789dc0b 125546 libcupscgi1-dev_1.6.2-9_amd64.deb
 3a6f0912d4bd13fa319b2a49f7b7ef3638722f31 103814 libcupsmime1-dev_1.6.2-9_amd64.deb
 25370ebc59a0015193870381d751958848f0c5f2 159472 libcupsppdc1-dev_1.6.2-9_amd64.deb
 d6e91ab560b73033a353533af772069914ae0186 30402 cups-bsd_1.6.2-9_amd64.deb
 4625e6ecea7f2db74883a409670322a81092c1c7 287826 cups-common_1.6.2-9_all.deb
 658a7e3c5773a216d2597a7a124150f239bce774 747500 cups-server-common_1.6.2-9_all.deb
 c41f546bbea52f279ea367d973aa5cf67781da48 120040 cups-ppdc_1.6.2-9_amd64.deb
 8301c236743e05e90290b757a05418266c45205b 2065538 cups-dbg_1.6.2-9_amd64.deb
Checksums-Sha256: 
 d5938320b954862eb02d46d15610a7e81ba54c87ee0dac80db7f041dfd437cea 3221 cups_1.6.2-9.dsc
 d2481352b99f7377cf149147cd0b80dd039f3c951feff7a7eceac3e93d653126 429377 cups_1.6.2-9.debian.tar.gz
 928d58886e4c3832e4404d46beb320b74a841d20982d35dc66bdb95d29d84174 281608 libcups2_1.6.2-9_amd64.deb
 1d4c875b153bca75264447e4069c652a256d9f9227c33a54e496e46f07d10cb4 106382 libcupsimage2_1.6.2-9_amd64.deb
 75b22c8a7da4ff0e994fc4acc7e8c33b39c662d4c6d3491713e5985e790f9679 119978 libcupscgi1_1.6.2-9_amd64.deb
 2646fae6cec5f45d567ad09b167265423dd09bf5ef8b18df8ada1149832cdbc5 103128 libcupsmime1_1.6.2-9_amd64.deb
 72179bee5cfc3f0561c2f55ddafe83e8e55e2271f48c75864987973cd3651f1a 142434 libcupsppdc1_1.6.2-9_amd64.deb
 117a8e872a100a6a72714b35b1706d94c56993316258c01506d2e555a1e80e5f 355948 cups_1.6.2-9_amd64.deb
 3cbe1ac8d3f0cdf3c845b92a031d4c5e4f3d47c1db5ea9ee4f0c2796ed142d28 402152 cups-daemon_1.6.2-9_amd64.deb
 3ad1dde87d13295facfafd05164771174dce27dfdaf0f8a72ba866c14fda969e 201080 cups-client_1.6.2-9_amd64.deb
 2535c99893bc59e1ae4612aa271d0fd93abe5b674996e17bb22b00b752f6c0ca 351188 libcups2-dev_1.6.2-9_amd64.deb
 ab18f5f44f78677e5241036535ee5e7ae9e93441cf38da60eec8f01e0ec3d02b 21938 libcupsimage2-dev_1.6.2-9_amd64.deb
 ceec5f24f4e4f3a5c533f3a91363ffc6f8c6201c0b0aacd3c707fe971d25e274 125546 libcupscgi1-dev_1.6.2-9_amd64.deb
 a00f262eb07bfa6583adba6e6fe4b3f9a085fb670e6d961a07f16bfff98cad21 103814 libcupsmime1-dev_1.6.2-9_amd64.deb
 e285a89c86df45e84d21252d932fdbb9d63f76f5811cf8ef938577ddffc2140b 159472 libcupsppdc1-dev_1.6.2-9_amd64.deb
 9a3893438d707618d4467ca32fad04315c222752223027ba15704438b038c417 30402 cups-bsd_1.6.2-9_amd64.deb
 dd5ddab9a3ff230026ed9d87a94565e8d2e3082949770d24b1275840788864a3 287826 cups-common_1.6.2-9_all.deb
 2e346be3741d5b366ff76d79cf2458be0d20b29a86311896cc3170dfe8adadf2 747500 cups-server-common_1.6.2-9_all.deb
 7c13707cb5c0a748c797a8ca459bff6e7a04c1b400195f31233b2c638368fe9f 120040 cups-ppdc_1.6.2-9_amd64.deb
 737cea8b09eb5bc3de7549c2be27b07af8ae1776cfc522927bff88fc97175cba 2065538 cups-dbg_1.6.2-9_amd64.deb
Files: 
 306c13e514baff93e07790340d5b9c04 3221 net optional cups_1.6.2-9.dsc
 b00b9eb08b94da26f3d3fd4ac0c5e3d8 429377 net optional cups_1.6.2-9.debian.tar.gz
 b9c76b5663c7370806eb78b8e2a0ae6f 281608 libs optional libcups2_1.6.2-9_amd64.deb
 9f675b50a116727041ed24043310454a 106382 libs optional libcupsimage2_1.6.2-9_amd64.deb
 234f7aac3c39dc455989fbc5fae70525 119978 libs optional libcupscgi1_1.6.2-9_amd64.deb
 fb4e739263b0a25b19be40416a4ad7e2 103128 libs optional libcupsmime1_1.6.2-9_amd64.deb
 80f4e1475925d44359b7203afb939624 142434 libs optional libcupsppdc1_1.6.2-9_amd64.deb
 d88c9e41609ca1bbc8e19c1d1fd9c52b 355948 net optional cups_1.6.2-9_amd64.deb
 1aa9c9c1a8e61374ac71483c16f6177b 402152 net optional cups-daemon_1.6.2-9_amd64.deb
 660fa726bea19c79ed0aecd42cef8227 201080 net optional cups-client_1.6.2-9_amd64.deb
 9e73d38dba6cef41080214465e33618f 351188 libdevel optional libcups2-dev_1.6.2-9_amd64.deb
 e24ff2e4d166a37e9c86089013f48457 21938 libdevel optional libcupsimage2-dev_1.6.2-9_amd64.deb
 1e2fd694652aea65ee81184868d2106c 125546 libdevel optional libcupscgi1-dev_1.6.2-9_amd64.deb
 96de378dce23743ae6627718837b2766 103814 libdevel optional libcupsmime1-dev_1.6.2-9_amd64.deb
 0f5cbcaf6d9aa83d9b9b29289be90f99 159472 libdevel optional libcupsppdc1-dev_1.6.2-9_amd64.deb
 c53c744edd323029a100c2b8957bd07b 30402 net extra cups-bsd_1.6.2-9_amd64.deb
 300d6ecf25ca92e73b98c2efd00f17af 287826 net optional cups-common_1.6.2-9_all.deb
 60c5dd0fa299270c60aa41828288c7c2 747500 net optional cups-server-common_1.6.2-9_all.deb
 c6812ee5c13420301f29c8356c73ad8f 120040 utils optional cups-ppdc_1.6.2-9_amd64.deb
 d36df440b8fbd9a353358dfb6573afbe 2065538 debug extra cups-dbg_1.6.2-9_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQGcBAEBCAAGBQJRvcSjAAoJEIvPpx7KFjRVHyIL/RQhOre+ECWs4gBt3xO9uQMu
ROie7x2pYg4jD4dTS6tTNGZL1Sn6Hr29WyY0U2bfh8u/W+Dz5mgOXnf/EoPuXSsb
ONj84Ajsk6JSVN9i++CCBgy1tZQvwOjARj3tr1wfCE7jovxlaxGo1yRLp0+Eg0z7
H/SUuuhCC3pp0gjtXpcCIjp6t2SurArDQCNeiZdLkWQ+5UKdzJeSsBrruo0dUKaj
AOuf/i0YdA0Q+X5MZI3I0koyKUp/zJI3Hgg3D+/WrtcpLAOjStkmXDbQyj+4YkD7
ZI9J8h/jeHdesWP5V4K92WJPYGJM1e02ti9ylMXf29XpnCjahAvmuXsZgNeroO4F
XYtO7iZEa2JOsl2eIAMpiCRrfGg0M9BkzzB8uAwXcO0FjlwyI77wJLH15wkaawIy
rhv9uFhIAU715sLIkY6nSO2pQX+Kc9c1vNavc5FZJpMd0Nt1Tiy6of7bm3PXsu84
XERLUgwqbwGW+MAZUDagFeMob6MYvmXvwOumxLs+vQ==
=MQ3R
-----END PGP SIGNATURE-----




Reply sent to Didier Raboud <odyx@debian.org>:
You have taken responsibility. (Sun, 16 Jun 2013 15:21:06 GMT) Full text and rfc822 format available.

Notification sent to Vincent Lefevre <vincent@vinc17.net>:
Bug acknowledged by developer. (Sun, 16 Jun 2013 15:21:06 GMT) Full text and rfc822 format available.

Message #49 received at 711192-close@bugs.debian.org (full text, mbox):

From: Didier Raboud <odyx@debian.org>
To: 711192-close@bugs.debian.org
Subject: Bug#711192: fixed in cups 1.6.2-9
Date: Sun, 16 Jun 2013 15:18:41 +0000
Source: cups
Source-Version: 1.6.2-9

We believe that the bug you reported is fixed in the latest version of
cups, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 711192@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Didier Raboud <odyx@debian.org> (supplier of updated cups package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sun, 16 Jun 2013 15:32:29 +0200
Source: cups
Binary: libcups2 libcupsimage2 libcupscgi1 libcupsmime1 libcupsppdc1 cups cups-daemon cups-client libcups2-dev libcupsimage2-dev libcupscgi1-dev libcupsmime1-dev libcupsppdc1-dev cups-bsd cups-common cups-server-common cups-ppdc cups-dbg
Architecture: source amd64 all
Version: 1.6.2-9
Distribution: unstable
Urgency: low
Maintainer: Debian Printing Team <debian-printing@lists.debian.org>
Changed-By: Didier Raboud <odyx@debian.org>
Description: 
 cups       - Common UNIX Printing System(tm) - server
 cups-bsd   - Common UNIX Printing System(tm) - BSD commands
 cups-client - Common UNIX Printing System(tm) - client programs (SysV)
 cups-common - Common UNIX Printing System(tm) - common files
 cups-daemon - Common UNIX Printing System(tm) - daemon
 cups-dbg   - Common UNIX Printing System(tm) - debugging symbols
 cups-ppdc  - Common UNIX Printing System(tm) - PPD manipulation utilities
 cups-server-common - Common UNIX Printing System(tm) - server common files
 libcups2   - Common UNIX Printing System(tm) - Core library
 libcups2-dev - Common UNIX Printing System(tm) - Development files CUPS library
 libcupscgi1 - Common UNIX Printing System(tm) - CGI library
 libcupscgi1-dev - Common UNIX Printing System(tm) - Development files for CGI libra
 libcupsimage2 - Common UNIX Printing System(tm) - Raster image library
 libcupsimage2-dev - Common UNIX Printing System(tm) - Development files CUPS image li
 libcupsmime1 - Common UNIX Printing System(tm) - MIME library
 libcupsmime1-dev - Common UNIX Printing System(tm) - Development files MIME library
 libcupsppdc1 - Common UNIX Printing System(tm) - PPD manipulation library
 libcupsppdc1-dev - Common UNIX Printing System(tm) - Development files PPD library
Closes: 704238 711192 711709 711868
Changes: 
 cups (1.6.2-9) unstable; urgency=low
 .
   [ Helge Kreutzmann ]
   * Update German manpages translation.
   * In ipptoolfile manpage, mention that possible attribute-name are
     defined in RFC2911, for clarity. (Closes: #711709)
 .
   [ Didier Raboud ]
   * Add a cups-client.NEWS notice, a cups-client manpage patch and amend
     the client.conf example file to inform about IPP default version
     change to 2.0 and circumvention measures. (Closes: #704238, #711192)
     - thanks to Brian Potkin
   * Reorder patches to have the manpages translation patch higher on the
     patch queue
   * Fix hyphen-correction typo
   * Update manpage translations with the recent changes
   * Drop outdated and not-applied colord-support patch.
 .
   [ Alexey Galakhov ]
   * Add patch to fix printer icc profiles registration in colord
     (Closes: #711868)
Checksums-Sha1: 
 29870b7d4709541a13faf681898f06a87a0e3483 3221 cups_1.6.2-9.dsc
 3506dba07b5174afb3a79c2390aa2cb1af160110 429377 cups_1.6.2-9.debian.tar.gz
 e54b49c68ff4d30caefda11b5816701a85fe1b11 281608 libcups2_1.6.2-9_amd64.deb
 7fe76ee2a04a8c3fade33251c71355337a888fa8 106382 libcupsimage2_1.6.2-9_amd64.deb
 9628e6cf0f8baea1048975a7bde548c276c62b0a 119978 libcupscgi1_1.6.2-9_amd64.deb
 bde35bc72d4c5f59b3a462c94a86ca9e80d40598 103128 libcupsmime1_1.6.2-9_amd64.deb
 32d331351213f0abe16b89fd0c6cf96d16b00026 142434 libcupsppdc1_1.6.2-9_amd64.deb
 bffdec67e8807a6d7cdabf62b0325f30462db5f6 355948 cups_1.6.2-9_amd64.deb
 568a8d14b2e068d82d2d00469d877844298a6b45 402152 cups-daemon_1.6.2-9_amd64.deb
 533c275f2802e044820d5860fafbb77a64b73bf6 201080 cups-client_1.6.2-9_amd64.deb
 7db89103674d36adcb10220decb6be0f37a0679e 351188 libcups2-dev_1.6.2-9_amd64.deb
 fd8d97dabcccc337a451b04fce48ca7b95710b42 21938 libcupsimage2-dev_1.6.2-9_amd64.deb
 29fa9fdd22dc47f1d94c3eceb8e438743789dc0b 125546 libcupscgi1-dev_1.6.2-9_amd64.deb
 3a6f0912d4bd13fa319b2a49f7b7ef3638722f31 103814 libcupsmime1-dev_1.6.2-9_amd64.deb
 25370ebc59a0015193870381d751958848f0c5f2 159472 libcupsppdc1-dev_1.6.2-9_amd64.deb
 d6e91ab560b73033a353533af772069914ae0186 30402 cups-bsd_1.6.2-9_amd64.deb
 4625e6ecea7f2db74883a409670322a81092c1c7 287826 cups-common_1.6.2-9_all.deb
 658a7e3c5773a216d2597a7a124150f239bce774 747500 cups-server-common_1.6.2-9_all.deb
 c41f546bbea52f279ea367d973aa5cf67781da48 120040 cups-ppdc_1.6.2-9_amd64.deb
 8301c236743e05e90290b757a05418266c45205b 2065538 cups-dbg_1.6.2-9_amd64.deb
Checksums-Sha256: 
 d5938320b954862eb02d46d15610a7e81ba54c87ee0dac80db7f041dfd437cea 3221 cups_1.6.2-9.dsc
 d2481352b99f7377cf149147cd0b80dd039f3c951feff7a7eceac3e93d653126 429377 cups_1.6.2-9.debian.tar.gz
 928d58886e4c3832e4404d46beb320b74a841d20982d35dc66bdb95d29d84174 281608 libcups2_1.6.2-9_amd64.deb
 1d4c875b153bca75264447e4069c652a256d9f9227c33a54e496e46f07d10cb4 106382 libcupsimage2_1.6.2-9_amd64.deb
 75b22c8a7da4ff0e994fc4acc7e8c33b39c662d4c6d3491713e5985e790f9679 119978 libcupscgi1_1.6.2-9_amd64.deb
 2646fae6cec5f45d567ad09b167265423dd09bf5ef8b18df8ada1149832cdbc5 103128 libcupsmime1_1.6.2-9_amd64.deb
 72179bee5cfc3f0561c2f55ddafe83e8e55e2271f48c75864987973cd3651f1a 142434 libcupsppdc1_1.6.2-9_amd64.deb
 117a8e872a100a6a72714b35b1706d94c56993316258c01506d2e555a1e80e5f 355948 cups_1.6.2-9_amd64.deb
 3cbe1ac8d3f0cdf3c845b92a031d4c5e4f3d47c1db5ea9ee4f0c2796ed142d28 402152 cups-daemon_1.6.2-9_amd64.deb
 3ad1dde87d13295facfafd05164771174dce27dfdaf0f8a72ba866c14fda969e 201080 cups-client_1.6.2-9_amd64.deb
 2535c99893bc59e1ae4612aa271d0fd93abe5b674996e17bb22b00b752f6c0ca 351188 libcups2-dev_1.6.2-9_amd64.deb
 ab18f5f44f78677e5241036535ee5e7ae9e93441cf38da60eec8f01e0ec3d02b 21938 libcupsimage2-dev_1.6.2-9_amd64.deb
 ceec5f24f4e4f3a5c533f3a91363ffc6f8c6201c0b0aacd3c707fe971d25e274 125546 libcupscgi1-dev_1.6.2-9_amd64.deb
 a00f262eb07bfa6583adba6e6fe4b3f9a085fb670e6d961a07f16bfff98cad21 103814 libcupsmime1-dev_1.6.2-9_amd64.deb
 e285a89c86df45e84d21252d932fdbb9d63f76f5811cf8ef938577ddffc2140b 159472 libcupsppdc1-dev_1.6.2-9_amd64.deb
 9a3893438d707618d4467ca32fad04315c222752223027ba15704438b038c417 30402 cups-bsd_1.6.2-9_amd64.deb
 dd5ddab9a3ff230026ed9d87a94565e8d2e3082949770d24b1275840788864a3 287826 cups-common_1.6.2-9_all.deb
 2e346be3741d5b366ff76d79cf2458be0d20b29a86311896cc3170dfe8adadf2 747500 cups-server-common_1.6.2-9_all.deb
 7c13707cb5c0a748c797a8ca459bff6e7a04c1b400195f31233b2c638368fe9f 120040 cups-ppdc_1.6.2-9_amd64.deb
 737cea8b09eb5bc3de7549c2be27b07af8ae1776cfc522927bff88fc97175cba 2065538 cups-dbg_1.6.2-9_amd64.deb
Files: 
 306c13e514baff93e07790340d5b9c04 3221 net optional cups_1.6.2-9.dsc
 b00b9eb08b94da26f3d3fd4ac0c5e3d8 429377 net optional cups_1.6.2-9.debian.tar.gz
 b9c76b5663c7370806eb78b8e2a0ae6f 281608 libs optional libcups2_1.6.2-9_amd64.deb
 9f675b50a116727041ed24043310454a 106382 libs optional libcupsimage2_1.6.2-9_amd64.deb
 234f7aac3c39dc455989fbc5fae70525 119978 libs optional libcupscgi1_1.6.2-9_amd64.deb
 fb4e739263b0a25b19be40416a4ad7e2 103128 libs optional libcupsmime1_1.6.2-9_amd64.deb
 80f4e1475925d44359b7203afb939624 142434 libs optional libcupsppdc1_1.6.2-9_amd64.deb
 d88c9e41609ca1bbc8e19c1d1fd9c52b 355948 net optional cups_1.6.2-9_amd64.deb
 1aa9c9c1a8e61374ac71483c16f6177b 402152 net optional cups-daemon_1.6.2-9_amd64.deb
 660fa726bea19c79ed0aecd42cef8227 201080 net optional cups-client_1.6.2-9_amd64.deb
 9e73d38dba6cef41080214465e33618f 351188 libdevel optional libcups2-dev_1.6.2-9_amd64.deb
 e24ff2e4d166a37e9c86089013f48457 21938 libdevel optional libcupsimage2-dev_1.6.2-9_amd64.deb
 1e2fd694652aea65ee81184868d2106c 125546 libdevel optional libcupscgi1-dev_1.6.2-9_amd64.deb
 96de378dce23743ae6627718837b2766 103814 libdevel optional libcupsmime1-dev_1.6.2-9_amd64.deb
 0f5cbcaf6d9aa83d9b9b29289be90f99 159472 libdevel optional libcupsppdc1-dev_1.6.2-9_amd64.deb
 c53c744edd323029a100c2b8957bd07b 30402 net extra cups-bsd_1.6.2-9_amd64.deb
 300d6ecf25ca92e73b98c2efd00f17af 287826 net optional cups-common_1.6.2-9_all.deb
 60c5dd0fa299270c60aa41828288c7c2 747500 net optional cups-server-common_1.6.2-9_all.deb
 c6812ee5c13420301f29c8356c73ad8f 120040 utils optional cups-ppdc_1.6.2-9_amd64.deb
 d36df440b8fbd9a353358dfb6573afbe 2065538 debug extra cups-dbg_1.6.2-9_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQGcBAEBCAAGBQJRvcSjAAoJEIvPpx7KFjRVHyIL/RQhOre+ECWs4gBt3xO9uQMu
ROie7x2pYg4jD4dTS6tTNGZL1Sn6Hr29WyY0U2bfh8u/W+Dz5mgOXnf/EoPuXSsb
ONj84Ajsk6JSVN9i++CCBgy1tZQvwOjARj3tr1wfCE7jovxlaxGo1yRLp0+Eg0z7
H/SUuuhCC3pp0gjtXpcCIjp6t2SurArDQCNeiZdLkWQ+5UKdzJeSsBrruo0dUKaj
AOuf/i0YdA0Q+X5MZI3I0koyKUp/zJI3Hgg3D+/WrtcpLAOjStkmXDbQyj+4YkD7
ZI9J8h/jeHdesWP5V4K92WJPYGJM1e02ti9ylMXf29XpnCjahAvmuXsZgNeroO4F
XYtO7iZEa2JOsl2eIAMpiCRrfGg0M9BkzzB8uAwXcO0FjlwyI77wJLH15wkaawIy
rhv9uFhIAU715sLIkY6nSO2pQX+Kc9c1vNavc5FZJpMd0Nt1Tiy6of7bm3PXsu84
XERLUgwqbwGW+MAZUDagFeMob6MYvmXvwOumxLs+vQ==
=MQ3R
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Thu, 20 Jun 2013 14:57:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Lefevre <vincent@vinc17.net>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Thu, 20 Jun 2013 14:57:04 GMT) Full text and rfc822 format available.

Message #54 received at 704238@bugs.debian.org (full text, mbox):

From: Vincent Lefevre <vincent@vinc17.net>
To: Michael Sweet <msweet@apple.com>
Cc: Didier 'OdyX' Raboud <odyx@debian.org>, "Daniel Richard G." <skunk@iskunk.org>, 704238@bugs.debian.org, 711192@bugs.debian.org
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Thu, 20 Jun 2013 16:55:51 +0200
On 2013-06-20 10:41:56 -0400, Michael Sweet wrote:
> On 2013-06-06, at 2:59 AM, Didier 'OdyX' Raboud <odyx@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 decision…
> 
> It isn't impossible, but it can be unreliable and is problematic for
> existing users of the cupsSendRequest/cupsGetResponse APIs - they
> have to handle the downgrading themselves.
> 
> 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 specify a way to ask the server
what version is running?

However would it be possible to output a real error message?
The errors I get

ypig:~> lpq -P lipucb-mono-1
lpq: Unknown destination "lipucb-mono-1".

ypig:~> lpstat -a
lpstat: Bad Request

are quite uninformative, in particular the first one.

There's a difference between having an unknown printer name
(say, like in "lpq -P does-not-exist") and having something
wrong in the communication with the server.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Thu, 20 Jun 2013 15:06:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Lefevre <vincent@vinc17.net>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Thu, 20 Jun 2013 15:06:08 GMT) Full text and rfc822 format available.

Message #59 received at 704238@bugs.debian.org (full text, mbox):

From: Vincent Lefevre <vincent@vinc17.net>
To: Michael Sweet <msweet@apple.com>
Cc: Didier 'OdyX' Raboud <odyx@debian.org>, "Daniel Richard G." <skunk@iskunk.org>, 704238@bugs.debian.org, 711192@bugs.debian.org
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Thu, 20 Jun 2013 17:05:02 +0200
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 the user needs to guess what to put there
(and update it if the version of the server changes).

Having some "cupsversion" utility to output the version would be
useful for configuration and to be able to diagnose problems more
easily.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Thu, 20 Jun 2013 15:42:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Sweet <msweet@apple.com>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Thu, 20 Jun 2013 15:42:04 GMT) Full text and rfc822 format available.

Message #64 received at 704238@bugs.debian.org (full text, mbox):

From: Michael Sweet <msweet@apple.com>
To: Vincent Lefevre <vincent@vinc17.net>
Cc: Didier 'OdyX' Raboud <odyx@debian.org>, "Daniel Richard G." <skunk@iskunk.org>, 704238@bugs.debian.org, 711192@bugs.debian.org
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Thu, 20 Jun 2013 11:39:01 -0400
Vincent,

On 2013-06-20, at 10:55 AM, Vincent Lefevre <vincent@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 protocol doesn't specify a way to ask the server
> what version is running?

You can, however you need to first send a request the server will accept.  That means you can either:

a) probe by sending requests (try 2.0, then 1.1, then 1.0)
b) send a Get-Printer-Attributes request with an older version (1.0 or 1.1) and look at the ipp-versions-supported values that are returned.

Option a) is what we tried at the beginning, but has problems when you use any of the "streaming" APIs (cupsSendRequest, cupsGetResponse, cupsStartDocument/cupsWriteRequestData/cupsFinishDocument) because the caller has to have the retry logic in it.

Option b) may fail if a printer/server stops supporting IPP/1.x and involves an extra request/connection when we first start talking to the server. This can cause slowdowns or hangs.

> However would it be possible to output a real error message?
> The errors I get
> 
> ypig:~> lpq -P lipucb-mono-1
> lpq: Unknown destination "lipucb-mono-1".
> 
> ypig:~> lpstat -a
> lpstat: Bad Request
> 
> are quite uninformative, in particular the first one.
> 
> There's a difference between having an unknown printer name
> (say, like in "lpq -P does-not-exist") and having something
> wrong in the communication with the server.

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 caused by a grab bag of issues, we can't just map it to "version not supported".

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Thu, 20 Jun 2013 15:45:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Sweet <msweet@apple.com>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Thu, 20 Jun 2013 15:45:09 GMT) Full text and rfc822 format available.

Message #69 received at 704238@bugs.debian.org (full text, mbox):

From: Michael Sweet <msweet@apple.com>
To: Didier 'OdyX' Raboud <odyx@debian.org>
Cc: "Daniel Richard G." <skunk@iskunk.org>, 704238@bugs.debian.org, 711192@bugs.debian.org, Vincent Lefevre <vincent@vinc17.net>
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Thu, 20 Jun 2013 10:41:56 -0400
Didier,

On 2013-06-06, at 2:59 AM, Didier 'OdyX' Raboud <odyx@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 decision…

It isn't impossible, but it can be unreliable and is problematic for existing users of the cupsSendRequest/cupsGetResponse APIs - they have to handle the downgrading themselves.

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.

Filed as the following bug in Apple's bug tracker:

    <rdar://problem/14216262> cups.org: Missing documentation for ServerName foo/version=1.1 in client.conf

(looking forward to getting the cups.org bug tracker back up...)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Thu, 20 Jun 2013 15:48:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Sweet <msweet@apple.com>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Thu, 20 Jun 2013 15:48:04 GMT) Full text and rfc822 format available.

Message #74 received at 704238@bugs.debian.org (full text, mbox):

From: Michael Sweet <msweet@apple.com>
To: Vincent Lefevre <vincent@vinc17.net>
Cc: Didier 'OdyX' Raboud <odyx@debian.org>, "Daniel Richard G." <skunk@iskunk.org>, 704238@bugs.debian.org, 711192@bugs.debian.org
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Thu, 20 Jun 2013 10:46:00 -0400
Vincent,

On 2013-06-06, at 7:15 AM, Vincent Lefevre <vincent@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 a version is not supported, but that requires clients to re-submit using the supported version.  Relatively easy for us to do for the cupsDo*Request APIs, but cupsSendRequest/GetResponse depend on the application to duplicate the logic.  There are just too many places to change (even in the CUPS sources) and then we'll still end up getting someone that reports it doesn't work because RandomApplication didn't update their code as well.

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.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair




Set Bug forwarded-to-address to 'rdar://problem/14216262'. Request was from "Didier 'OdyX' Raboud" <odyx@debian.org> to control@bugs.debian.org. (Thu, 20 Jun 2013 15:48:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Thu, 20 Jun 2013 15:54:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Sweet <msweet@apple.com>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Thu, 20 Jun 2013 15:54:04 GMT) Full text and rfc822 format available.

Message #81 received at 704238@bugs.debian.org (full text, mbox):

From: Michael Sweet <msweet@apple.com>
To: Vincent Lefevre <vincent@vinc17.net>
Cc: Didier 'OdyX' Raboud <odyx@debian.org>, "Daniel Richard G." <skunk@iskunk.org>, 704238@bugs.debian.org, 711192@bugs.debian.org
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Thu, 20 Jun 2013 11:50:59 -0400
Vincent,

On 2013-06-20, at 11:05 AM, Vincent Lefevre <vincent@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 user/administrator specify any version
>> limitations there.
> 
> The initial problem is that the user needs to guess what to put there
> (and update it if the version of the server changes).

For the former, if it doesn't work use /version=1.1.

As for updating it, you don't need to if all you ever use are PPD-based printers, which is quite likely if you are just using ServerName to point to a single server.

> Having some "cupsversion" utility to output the version would be
> useful for configuration and to be able to diagnose problems more
> easily.


but is of limited usefulness given that the supported IPP versions have changed exactly 3 times over the life of CUPS since 1998 (1.0 for CUPS 1.0.x, 1.x for CUPS 1.1.0 through 1.3.12, 1.x and 2.x for CUPS 1.4.0 and later) and CUPS 1.4.0 was released 4 years ago next month.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Fri, 21 Jun 2013 03:39:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Daniel Richard G." <skunk@iSKUNK.ORG>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Fri, 21 Jun 2013 03:39:05 GMT) Full text and rfc822 format available.

Message #86 received at 704238@bugs.debian.org (full text, mbox):

From: "Daniel Richard G." <skunk@iSKUNK.ORG>
To: Michael Sweet <msweet@apple.com>, Vincent Lefevre <vincent@vinc17.net>
Cc: "Didier 'OdyX' Raboud" <odyx@debian.org>, 704238@bugs.debian.org, 711192@bugs.debian.org
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Thu, 20 Jun 2013 23:38:03 -0400
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 caused by a grab bag of issues, we
> can't just map it to "version not supported".

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.

When I first saw the errors Vincent quoted above, I had no idea what to
do. Printing worked on older Ubuntu system images, but not on a new one,
and there were a hundred-and-one things that had changed between
releases that could have been at fault. Ultimately, the only way I could
determine what was going on was to sit down with Wireshark, try to
print, and inspect the network chatter of the failed request. Only then
was I able to find the relevant bug reports.

It is not reasonable for a user to have to sniff CUPS network traffic in
order to diagnose an IPP version incompatibility.

I think that lpq and lpstat (any others?), being the most obvious tools
for verifying basic connectivity with the CUPS server, need to go the
extra mile to detect this kind of situation so that the user can be
alerted to it. Maybe if the tool gets a "Bad Request" error, it can do a
version probe... whatever makes the most sense. I'm not going to argue
for automatic protocol downgrading when that's already been considered,
but I will argue that returning a nonspecific "Bad Request" error (or
spurious "Unknown destination" error) for this particular failure mode
places an unacceptable burden on users wondering why their latest and
greatest Linux system is unable to print at all.

(I would agree that a "cupsversion" utility isn't such a hot idea,
albeit because the user would have to be aware of the IPP version being
an issue in order to know to use such a utility in the first place.)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Fri, 21 Jun 2013 13:33:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Sweet <msweet@apple.com>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Fri, 21 Jun 2013 13:33:04 GMT) Full text and rfc822 format available.

Message #91 received at 704238@bugs.debian.org (full text, mbox):

From: Michael Sweet <msweet@apple.com>
To: "Daniel Richard G." <skunk@iskunk.org>
Cc: Vincent Lefevre <vincent@vinc17.net>, Didier 'OdyX' Raboud <odyx@debian.org>, 704238@bugs.debian.org, 711192@bugs.debian.org
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Fri, 21 Jun 2013 09:29:36 -0400
Daniel,

On 2013-06-20, at 11:38 PM, Daniel Richard G. <skunk@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.

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-existent since we had to drop support for it entirely there (not all applications ask for networking access, and without network access you can't talk to a remote cupsd...)

> ...
> I think that lpq and lpstat (any others?), being the most obvious tools
> for verifying basic connectivity with the CUPS server, need to go the
> extra mile to detect this kind of situation so that the user can be
> alerted to it. Maybe if the tool gets a "Bad Request" error, it can do a
> version probe... whatever makes the most sense. I'm not going to argue
> for automatic protocol downgrading when that's already been considered,
> but I will argue that returning a nonspecific "Bad Request" error (or
> spurious "Unknown destination" error) for this particular failure mode
> places an unacceptable burden on users wondering why their latest and
> greatest Linux system is unable to print at all.
> 
> (I would agree that a "cupsversion" utility isn't such a hot idea,
> albeit because the user would have to be aware of the IPP version being
> an issue in order to know to use such a utility in the first place.)


Would simply adding some additional text to the client.conf man page be just as helpful, e.g.:

       ServerName hostname-or-ip-address[:port]/version=1.1
            Specifies the address and optionally the port to use when connect-
            ing to a server running CUPS 1.3.12 or earlier. Note: Not support-
            ed on OS X 10.7 or later.

       ServerName hostname-or-ip-address[:port]

       ServerName /domain/socket
            Specifies the address and optionally the port to use when connect-
            ing to a server running CUPS 1.4 or later. Note: Not supported on
            OS X 10.7 or later.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Fri, 21 Jun 2013 18:21:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Daniel Richard G." <skunk@iSKUNK.ORG>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Fri, 21 Jun 2013 18:21:09 GMT) Full text and rfc822 format available.

Message #96 received at 704238@bugs.debian.org (full text, mbox):

From: "Daniel Richard G." <skunk@iSKUNK.ORG>
To: Michael Sweet <msweet@apple.com>
Cc: Vincent Lefevre <vincent@vinc17.net>, "Didier 'OdyX' Raboud" <odyx@debian.org>, 704238@bugs.debian.org, 711192@bugs.debian.org
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Fri, 21 Jun 2013 14:20:22 -0400
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-existent since we had to drop support
> for it entirely there (not all applications ask for networking access,
> and without network access you can't talk to a remote cupsd...)

client.conf is applicable to large-site/institutional/enterprise
deployments of CUPS. How important is this use case to you?

Beyond that, it almost sounds likes CUPS as a whole is scaling down into
a local-only print infrastructure, that networked printing support is no
longer a goal. Is that really where things are going?

> Would simply adding some additional text to the client.conf man page
> be just as helpful, e.g.:
> 
>        ServerName hostname-or-ip-address[:port]/version=1.1
>             Specifies the address and optionally the port to use when
>             connecting to a server running CUPS 1.3.12 or earlier.
>             Note: Not supported on OS X 10.7 or later.
> 
>        ServerName hostname-or-ip-address[:port]
> 
>        ServerName /domain/socket
>             Specifies the address and optionally the port to use when
>             connecting to a server running CUPS 1.4 or later. Note:
>             Not supported on OS X 10.7 or later.

Documenting these directives is helpful, but how are users going to
recognize that an IPP version incompatibility is the problem in the
first place? How would they know that they should care what version of
CUPS is running on the server, when it's working perfectly well with
older clients? Right now, all they get is a generic and/or spurious
error message that isn't even good for a Web search.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Fri, 21 Jun 2013 19:48:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Sweet <msweet@apple.com>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Fri, 21 Jun 2013 19:48:04 GMT) Full text and rfc822 format available.

Message #101 received at 704238@bugs.debian.org (full text, mbox):

From: Michael Sweet <msweet@apple.com>
To: "Daniel Richard G." <skunk@iSKUNK.ORG>
Cc: Vincent Lefevre <vincent@vinc17.net>, Didier 'OdyX' Raboud <odyx@debian.org>, 704238@bugs.debian.org, 711192@bugs.debian.org
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Fri, 21 Jun 2013 15:44:07 -0400
Daniel,

On 2013-06-21, at 2:20 PM, "Daniel Richard G." <skunk@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 non-existent (less than 1% of users, based on bug
>> reports) and since 10.8 *is* non-existent since we had to drop support
>> for it entirely there (not all applications ask for networking access,
>> and without network access you can't talk to a remote cupsd...)
> 
> client.conf is applicable to large-site/institutional/enterprise
> deployments of CUPS. How important is this use case to you?

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 do not run all of the clients through a single print server because of performance issues, and use local PPDs to avoid hitting the print server every time someone opens the print dialog...

> Beyond that, it almost sounds likes CUPS as a whole is scaling down into
> a local-only print infrastructure, that networked printing support is no
> longer a goal. Is that really where things are going?

Not at all.

cupsd itself hasn't changed all that much.  We dropped support for CUPS browsing (serious performance and scaling problems for large networks, and a huge power drain in mobile devices) and our ad-hoc SLP/LDAP schema (serious deployment issues) in CUPS 1.6 in order to re-wire things to better support large and mobile networking.

At the client level, we changed the focus from a static list of printers provided by a single server to a dynamic list of printers provided by multiple servers - definitely large network stuff.  Right now the dynamic lookup happens only with DNS-SD, but future versions of CUPS will also look things up via SLP and LDAP using the standard schema (again, large network stuff).

Other future work: check out the IPP Shared Infrastructure Extensions on pwg.org; this will likely be supported by cupsd and solves many of the network/security barrier issues common in large networks.

So no, we aren't focused on local-only print - that's all we had previously.  We are now tackling large network/Internet printing and network mobility, something CUPS has traditionally been very bad at (thus hacks like client.conf and CUPS browsing).

>> Would simply adding some additional text to the client.conf man page
>> be just as helpful, e.g.:
>> 
>>       ServerName hostname-or-ip-address[:port]/version=1.1
>>            Specifies the address and optionally the port to use when
>>            connecting to a server running CUPS 1.3.12 or earlier.
>>            Note: Not supported on OS X 10.7 or later.
>> 
>>       ServerName hostname-or-ip-address[:port]
>> 
>>       ServerName /domain/socket
>>            Specifies the address and optionally the port to use when
>>            connecting to a server running CUPS 1.4 or later. Note:
>>            Not supported on OS X 10.7 or later.
> 
> Documenting these directives is helpful, but how are users going to
> recognize that an IPP version incompatibility is the problem in the
> first place?

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?

> How would they know that they should care what version of
> CUPS is running on the server, when it's working perfectly well with
> older clients?

Presumably the users will know what the admins are telling them, and the admins will read the documentation?

> Right now, all they get is a generic and/or spurious
> error message that isn't even good for a Web search.

We tried doing auto-version-detection and that didn't work.

Getting a Bad Request in lpstat/lpq and retrying with a 1.1 request to display an error telling the user to fix their configuration (!?!?) isn't particularly useful IMHO, and is more likely going to have users asking why the f**k we don't just do a 1.1 request in the first place.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Sat, 22 Jun 2013 02:33:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Vincent Lefevre <vincent@vinc17.net>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Sat, 22 Jun 2013 02:33:04 GMT) Full text and rfc822 format available.

Message #106 received at 704238@bugs.debian.org (full text, mbox):

From: Vincent Lefevre <vincent@vinc17.net>
To: Michael Sweet <msweet@apple.com>
Cc: "Daniel Richard G." <skunk@iSKUNK.ORG>, Didier 'OdyX' Raboud <odyx@debian.org>, 704238@bugs.debian.org, 711192@bugs.debian.org
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Sat, 22 Jun 2013 04:31:03 +0200
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
sometimes the print names, that's all.

> Getting a Bad Request in lpstat/lpq and retrying with a 1.1 request
> to display an error telling the user to fix their configuration
> (!?!?) isn't particularly useful IMHO, and is more likely going to
> have users asking why the f**k we don't just do a 1.1 request in the
> first place.

Getting a "Bad Request" is much better than an "unknown destination".
But still, the user may wonder what's going on. Perhaps point to
documentation telling what to do in case of such an error.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Sat, 22 Jun 2013 04:54:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Daniel Richard G." <skunk@iSKUNK.ORG>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Sat, 22 Jun 2013 04:54:04 GMT) Full text and rfc822 format available.

Message #111 received at 704238@bugs.debian.org (full text, mbox):

From: "Daniel Richard G." <skunk@iSKUNK.ORG>
To: Michael Sweet <msweet@apple.com>
Cc: Vincent Lefevre <vincent@vinc17.net>, "Didier 'OdyX' Raboud" <odyx@debian.org>, 704238@bugs.debian.org, 711192@bugs.debian.org
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Sat, 22 Jun 2013 00:51:54 -0400
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 do not run all of the clients through
> a single print server because of performance issues, and use local
> PPDs to avoid hitting the print server every time someone opens the
> print dialog...

My site is admittedly not that large; we haven't had any trouble
pushing everything through a single print server, running on a machine
alongside other services. Yet we've seen benefits in standardizing on a
client-only setup, as administration becomes easier when you don't have
to deal with cupsd and all its moving parts on every desktop. This is
why I filed

    https://bugs.launchpad.net/bugs/302272

(Same reasoning as why it's better to have one central SMTP smarthost
and dumb forwarders on each desktop, rather than a number of independent
mail queues that could each fail in multiple ways.)

> > Beyond that, it almost sounds likes CUPS as a whole is scaling down
> > into a local-only print infrastructure, that networked printing
> > support is no longer a goal. Is that really where things are going?
>
> Not at all.
>
> cupsd itself hasn't changed all that much.  We dropped support for
> CUPS browsing (serious performance and scaling problems for large
> networks, and a huge power drain in mobile devices) and our ad-hoc
> SLP/LDAP schema (serious deployment issues) in CUPS 1.6 in order to
> re-wire things to better support large and mobile networking.
>
> At the client level, we changed the focus from a static list of
> printers provided by a single server to a dynamic list of printers
> provided by multiple servers - definitely large network stuff.  Right
> now the dynamic lookup happens only with DNS-SD, but future versions
> of CUPS will also look things up via SLP and LDAP using the standard
> schema (again, large network stuff).
>
> Other future work: check out the IPP Shared Infrastructure Extensions
> on pwg.org; this will likely be supported by cupsd and solves many of
> the network/security barrier issues common in large networks.
>
> So no, we aren't focused on local-only print - that's all we had
> previously.  We are now tackling large network/Internet printing and
> network mobility, something CUPS has traditionally been very bad at
> (thus hacks like client.conf and CUPS browsing).

This is all good to hear---I was a bit worried that LPRng or the like
was going to be the way forward for networked printing on Linux :]

I'm certainly open to alternatives to client.conf; all I really want is
the option of a client-server setup with a client that's no more
complicated than a dumb SMTP forwarder.

> > Documenting these directives is helpful, but how are users going to
> > recognize that an IPP version incompatibility is the problem in the
> > first place?
>
> 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?

Admins are users, too. Some are all-knowing, some barely have the time
or wherewithal to deal with the afterthought that is the print server---
especially if it's been working fine for years and still works fine when
they try to print from their desktop.

> > How would they know that they should care what version of CUPS is
> > running on the server, when it's working perfectly well with older
> > clients?
>
> Presumably the users will know what the admins are telling them, and
> the admins will read the documentation?

My office runs CUPS 1.3.8 on the server. Even if my admin had the time
to read through the 1.3.8 docs, I don't think he would have found
anything helpful in there.

> > Right now, all they get is a generic and/or spurious error message
> > that isn't even good for a Web search.
>
> We tried doing auto-version-detection and that didn't work.

That's unfortunate; it would have been the best solution.

> Getting a Bad Request in lpstat/lpq and retrying with a 1.1 request to
> display an error telling the user to fix their configuration (!?!?)
> isn't particularly useful IMHO, and is more likely going to have users
> asking why the f**k we don't just do a 1.1 request in the first place.

I had to use a *protocol analyzer* to diagnose that problem. I didn't
know that the default IPP version had changed in 1.6, let alone that
that had anything to do with the "Bad Request" error. You may not think
the extra lpstat/lpq logic would be useful, but then, you live and
breath CUPS and already know what's going on. I do not, and from my
perspective, the extra logic and specific error message would have been
useful enough to save me hours of time investigating the problem, and
get printing working on the Ubuntu test system many weeks sooner than it
ultimately did.

As for users asking why not a 1.1 request, the error message can include
a URL to a document explaining this whole mess. You've already had to
explain a few times here why the obvious solution of auto-downgrading
the protocol doesn't work---you may as well answer that whole family of
annoying questions once and for all.



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Mon, 24 Jun 2013 04:21:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Daniel Richard G." <skunk@iSKUNK.ORG>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Mon, 24 Jun 2013 04:21:09 GMT) Full text and rfc822 format available.

Message #116 received at 704238@bugs.debian.org (full text, mbox):

From: "Daniel Richard G." <skunk@iSKUNK.ORG>
To: Vincent Lefevre <vincent@vinc17.net>, Michael Sweet <msweet@apple.com>
Cc: "Didier 'OdyX' Raboud" <odyx@debian.org>, 704238@bugs.debian.org, 711192@bugs.debian.org
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Mon, 24 Jun 2013 00:17:53 -0400
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 to tell
users about it.

> Getting a "Bad Request" is much better than an "unknown destination".
> But still, the user may wonder what's going on. Perhaps point to
> documentation telling what to do in case of such an error.

"Bad Request" is a catch-all error, however, and those tend not to lead
to documentation that most users will find easy to follow (cf. SIGSEGV).



Information forwarded to debian-bugs-dist@lists.debian.org, Debian Printing Team <debian-printing@lists.debian.org>:
Bug#704238; Package cups-client. (Tue, 25 Jun 2013 05:18:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guido Günther <agx@sigxcpu.org>:
Extra info received and forwarded to list. Copy sent to Debian Printing Team <debian-printing@lists.debian.org>. (Tue, 25 Jun 2013 05:18:04 GMT) Full text and rfc822 format available.

Message #121 received at 704238@bugs.debian.org (full text, mbox):

From: Guido Günther <agx@sigxcpu.org>
To: 704238@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Bug#704238: Need to document the CUPS client's new server-version option
Date: Mon, 24 Jun 2013 19:18:26 +0200
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 documentation for
> > ServerName foo/version=1.1 in client.conf
> 
> Then tagging the bug as such.

I'm reopening this bugs since the NEWS file is not shipped in the
cups-client package:

$ dpkg -s cups-client | grep Version:
Version: 1.6.2-9
$ dpkg -L cups-client  | grep NEWS
<nothing

This is presumably cause by the fact that /u/s/d/cups-client is a 
symlink to /u/s/d/cups-client.

This also doesn't help much when browsing remote priners that aren't in
client.conf but I needed to find more time to debug this further.
Cheers,
 -- Guico



Bug reopened Request was from Guido Günther <agx@sigxcpu.org> to control@bugs.debian.org. (Tue, 25 Jun 2013 05:18:11 GMT) Full text and rfc822 format available.

No longer marked as fixed in versions cups/1.6.2-9. Request was from Guido Günther <agx@sigxcpu.org> to control@bugs.debian.org. (Tue, 25 Jun 2013 05:18:13 GMT) Full text and rfc822 format available.

Reply sent to Didier Raboud <odyx@debian.org>:
You have taken responsibility. (Wed, 26 Jun 2013 12:51:09 GMT) Full text and rfc822 format available.

Notification sent to "Daniel Richard G." <skunk@iSKUNK.ORG>:
Bug acknowledged by developer. (Wed, 26 Jun 2013 12:51:09 GMT) Full text and rfc822 format available.

Message #130 received at 704238-close@bugs.debian.org (full text, mbox):

From: Didier Raboud <odyx@debian.org>
To: 704238-close@bugs.debian.org
Subject: Bug#704238: fixed in cups 1.6.2-10
Date: Wed, 26 Jun 2013 12:48:33 +0000
Source: cups
Source-Version: 1.6.2-10

We believe that the bug you reported is fixed in the latest version of
cups, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 704238@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Didier Raboud <odyx@debian.org> (supplier of updated cups package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Wed, 26 Jun 2013 13:51:10 +0200
Source: cups
Binary: libcups2 libcupsimage2 libcupscgi1 libcupsmime1 libcupsppdc1 cups cups-daemon cups-client libcups2-dev libcupsimage2-dev libcupscgi1-dev libcupsmime1-dev libcupsppdc1-dev cups-bsd cups-common cups-server-common cups-ppdc cups-dbg
Architecture: source amd64 all
Version: 1.6.2-10
Distribution: unstable
Urgency: low
Maintainer: Debian Printing Team <debian-printing@lists.debian.org>
Changed-By: Didier Raboud <odyx@debian.org>
Description: 
 cups       - Common UNIX Printing System(tm) - server
 cups-bsd   - Common UNIX Printing System(tm) - BSD commands
 cups-client - Common UNIX Printing System(tm) - client programs (SysV)
 cups-common - Common UNIX Printing System(tm) - common files
 cups-daemon - Common UNIX Printing System(tm) - daemon
 cups-dbg   - Common UNIX Printing System(tm) - debugging symbols
 cups-ppdc  - Common UNIX Printing System(tm) - PPD manipulation utilities
 cups-server-common - Common UNIX Printing System(tm) - server common files
 libcups2   - Common UNIX Printing System(tm) - Core library
 libcups2-dev - Common UNIX Printing System(tm) - Development files CUPS library
 libcupscgi1 - Common UNIX Printing System(tm) - CGI library
 libcupscgi1-dev - Common UNIX Printing System(tm) - Development files for CGI libra
 libcupsimage2 - Common UNIX Printing System(tm) - Raster image library
 libcupsimage2-dev - Common UNIX Printing System(tm) - Development files CUPS image li
 libcupsmime1 - Common UNIX Printing System(tm) - MIME library
 libcupsmime1-dev - Common UNIX Printing System(tm) - Development files MIME library
 libcupsppdc1 - Common UNIX Printing System(tm) - PPD manipulation library
 libcupsppdc1-dev - Common UNIX Printing System(tm) - Development files PPD library
Closes: 645436 704238 711848
Changes: 
 cups (1.6.2-10) unstable; urgency=low
 .
   [ Didier Raboud ]
   * Mark the cups-client NEWS as released and make sure it can be
     installed by dropping the /usr/share/doc/cups-client symlink.
     Thanks to Evgeni Golov (Closes: #704238)
   * Backport upstream patch to remove unreal printers from the potential
     printers' list to avoid jobs to go to unexpected printers
     (Closes: #711848)
   * Backport upstream patch to enhance the HTTP_ERROR handling
     (Closes: #645436)
   * Bump Standards-Version to 3.9.4 without changes needed
   * Source package cleanup:
     - Drop outdated and not-applied cups-avahi.patch
     - Drop unused bzr-builddep configuration files
     - Add gitignore file to ignore .pc/ directory
 .
   [ Helge Kreutzmann ]
   * Update German manpages translation.
Checksums-Sha1: 
 b6dad067b30577a6ecf37d657f3870afd1996b0d 3225 cups_1.6.2-10.dsc
 7328fe8b14e426e130e5b1698bd775ad9d468646 410832 cups_1.6.2-10.debian.tar.gz
 414988297e941d6b849f17b3e1459a8fe1b23f35 279818 libcups2_1.6.2-10_amd64.deb
 9df899c8800f5473de7323d7de0c6f1d410123ac 106510 libcupsimage2_1.6.2-10_amd64.deb
 8ea39fa9f4d4c616af1140a2d4035e121ffabca6 119798 libcupscgi1_1.6.2-10_amd64.deb
 57309ba3ed282f10ca4a8ad1fd7af87bf61d2a17 103188 libcupsmime1_1.6.2-10_amd64.deb
 050c2ae65937fe1d56104a42871b463dfe0e9923 141946 libcupsppdc1_1.6.2-10_amd64.deb
 9695db3870849f7cae1e32c44c3df827f7cc4fa8 350884 cups_1.6.2-10_amd64.deb
 59e90e1811871cdf69b4a38afd47c76e8f9377f1 400050 cups-daemon_1.6.2-10_amd64.deb
 b256b1906731e374df269496997cf6b51b00d508 289518 cups-client_1.6.2-10_amd64.deb
 468026397ce7ad7d53aa2154bb63e630edae09e0 351340 libcups2-dev_1.6.2-10_amd64.deb
 61834ba560756c6990e6adee73e6569219cf16d6 21934 libcupsimage2-dev_1.6.2-10_amd64.deb
 fa1e602ead1dc458b781f2554c0317fe9bae12cf 125804 libcupscgi1-dev_1.6.2-10_amd64.deb
 6aff2448b88ab5325b577332db71e90c655c96db 104076 libcupsmime1-dev_1.6.2-10_amd64.deb
 c072fbe053306ec64c14f46c0ad6861def9e0f9a 159720 libcupsppdc1-dev_1.6.2-10_amd64.deb
 7cb0ace7cb9cd9ab2a1647f46d028635b28f3407 29984 cups-bsd_1.6.2-10_amd64.deb
 551b4cc58ffe3d40c79d10da0b5aa38ef4e08604 288072 cups-common_1.6.2-10_all.deb
 3764025fe140bac74611de56a515462d5a26b51c 747714 cups-server-common_1.6.2-10_all.deb
 1e5edcb74530ded53983716c6eff81d33f299498 119742 cups-ppdc_1.6.2-10_amd64.deb
 344d7ca84df9e0d5927207a11970114f59ba7f26 2062874 cups-dbg_1.6.2-10_amd64.deb
Checksums-Sha256: 
 e326a9113a34ba4a7c7a682b9e57e77c591ac23233e8a6a88e0b58d1cd1546fe 3225 cups_1.6.2-10.dsc
 fbd09cbce12c59f125c6775d039f28eb111a2ef2ffa564473f4b1e31d8014bab 410832 cups_1.6.2-10.debian.tar.gz
 ded97f652e18b4de3fd91ff2f00fcfddf93793e035492b2c06d4bdd079d524e5 279818 libcups2_1.6.2-10_amd64.deb
 597686cf0d66d03f64c34ac1d8a6566674fc0f0bdaccacacb965fcba40f178e6 106510 libcupsimage2_1.6.2-10_amd64.deb
 44444c06a8a94effc7dd014c691fcdf8102f62674dac9855f0bfbc1e268f5d75 119798 libcupscgi1_1.6.2-10_amd64.deb
 0e35d602b34640db6fc441d4ef6a55927c22f6719f4090dc202f2f7217f74637 103188 libcupsmime1_1.6.2-10_amd64.deb
 6b897701dcfbb8cc433acda52c342e374052ef927fa5e9d6da95a3ceb1573778 141946 libcupsppdc1_1.6.2-10_amd64.deb
 4a5114eb3ecb32055e860f31edb5837b4f845459d21ac00cb8a5dc5f247c2317 350884 cups_1.6.2-10_amd64.deb
 8f653df18806369404f1fff3cbbfa767dd19c7357db51c2a3bc39050a85e281a 400050 cups-daemon_1.6.2-10_amd64.deb
 c5372fdf1b00f0f33b05a82c3d10b1bd378a20539eca34a8aaa5ea47e5a557ff 289518 cups-client_1.6.2-10_amd64.deb
 a71768b542a99de7bed25a506f7537e29913efc5769cfcdfc2e28fbcff0767a9 351340 libcups2-dev_1.6.2-10_amd64.deb
 19d3eef564c52a330d1deea98e66278a51a482467ac67bf171f07ed677f095b2 21934 libcupsimage2-dev_1.6.2-10_amd64.deb
 3b80569f050b48f20eb81d1586fc20dd1a5bdaa35ff2a013124590772049173a 125804 libcupscgi1-dev_1.6.2-10_amd64.deb
 61ff50d690c07585d02a29c2e9744d2225c4a1a5ecfbe8f90475dd36b2bcc673 104076 libcupsmime1-dev_1.6.2-10_amd64.deb
 92cb0c4ba5670b81b0630128528fb6beeb87342d7c778363643bd545861082a6 159720 libcupsppdc1-dev_1.6.2-10_amd64.deb
 3a8a0dd2369d39b584a160e6c7142035e284abf798371c50f0ee249bbdd3b355 29984 cups-bsd_1.6.2-10_amd64.deb
 426ea3937a3c08cc292620754021d3cef1dc641263fe8fa40a2dd740b8a8732f 288072 cups-common_1.6.2-10_all.deb
 e2aa30a708dd96c72cfb2a175c103a86ba983be0044d6d3e5445fd357be01f64 747714 cups-server-common_1.6.2-10_all.deb
 d1e311093c3f8ec0b1ea8f7552d13ec1f34607d0db945d945930adf04ae2ba2e 119742 cups-ppdc_1.6.2-10_amd64.deb
 3ddaf57e42551f6c6889bd9c794d1f8d080cf932e30ec5cbe50fe4754886cc65 2062874 cups-dbg_1.6.2-10_amd64.deb
Files: 
 c60e7fb48d9602d41479d00a747024f6 3225 net optional cups_1.6.2-10.dsc
 29ac857dd65b1db25b8498bd17c4815a 410832 net optional cups_1.6.2-10.debian.tar.gz
 05f045836db9bf4d26b94176443a5716 279818 libs optional libcups2_1.6.2-10_amd64.deb
 dbdc2a2f18b347a69c2f7651ec61f78c 106510 libs optional libcupsimage2_1.6.2-10_amd64.deb
 b441807a6a898bde756291fb392183de 119798 libs optional libcupscgi1_1.6.2-10_amd64.deb
 981e5f9543693ed8fcbc2e4b2b108c9c 103188 libs optional libcupsmime1_1.6.2-10_amd64.deb
 72dea6fe93c14a79b2ecab50b777450b 141946 libs optional libcupsppdc1_1.6.2-10_amd64.deb
 60f7bb6e6f603ada58db932474abbef8 350884 net optional cups_1.6.2-10_amd64.deb
 9ff10dfc9df8e1f344c346268e60c0d8 400050 net optional cups-daemon_1.6.2-10_amd64.deb
 a3a6394fe6450a82f9e066cd8f27d1c8 289518 net optional cups-client_1.6.2-10_amd64.deb
 fb26e9395c4d83c07278fd14ba7d0d9c 351340 libdevel optional libcups2-dev_1.6.2-10_amd64.deb
 b212844bed6aa48291cffa7a2a4881f3 21934 libdevel optional libcupsimage2-dev_1.6.2-10_amd64.deb
 102199dea1478f7317795c8c93387da8 125804 libdevel optional libcupscgi1-dev_1.6.2-10_amd64.deb
 3741cb4ddbeea4e857cc553317012d4a 104076 libdevel optional libcupsmime1-dev_1.6.2-10_amd64.deb
 51b3c096be613177dd984f58cbb805aa 159720 libdevel optional libcupsppdc1-dev_1.6.2-10_amd64.deb
 66321917709de349ae6893df98073e8c 29984 net extra cups-bsd_1.6.2-10_amd64.deb
 b9722a47797b77711ecc9bb5fdfcffd3 288072 net optional cups-common_1.6.2-10_all.deb
 74fc86e47d96aebf0e9458187d571c0d 747714 net optional cups-server-common_1.6.2-10_all.deb
 1f1b1526965862845e93e38b1062689e 119742 utils optional cups-ppdc_1.6.2-10_amd64.deb
 3eaf9a83a97ff431967da5da54bfcef6 2062874 debug extra cups-dbg_1.6.2-10_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQGcBAEBCAAGBQJRyt7PAAoJEIvPpx7KFjRVIpAL+gK9D/BIe05yhK1LzHloWLRy
orqrSwsGzy5MaGZuVJhvdWW9xJ1pcuB/u1Suw9TovOBeAswiODe+j1lvz/FH528Z
he4FHLit4tTvS9Kz8tk5yTe2mfUHWdWhoVn2rrudXdie7i01MLNWLeTQWsnpWIv9
lloUmErABTAp6Hxfp9UHDVIWAIY3IiG+6qBmZrTeMsc87hA4+qiTO2r35UlovQo3
tI3BaFeMw0PXdTyS37XvBJEVVJiLnEZgk0MD0xPMfTz8/aRk38iRogVZCPAMWUA9
okQzhQp/JpDv1VO0bFL4T11/EZ1db4D3bwsuysNXLupMypxsMLFXFnNh2QQAJV81
+GC1kPyY3974YfuodaXTHX1LgWPRVWrPc2pKRzS1cq7mRgu8bVN04WJCLQMqC08v
JI5ka77STJHJWI37ihtMxaH2cBuQphA9F77KF3f+73+G5kSarAC/YlZQjiHXhgBv
3cRT6z0WEtYAkuqyeeJRh2g0Vpq35MxyzW20IkmK6A==
=dTTc
-----END PGP SIGNATURE-----




Reply sent to Didier Raboud <odyx@debian.org>:
You have taken responsibility. (Wed, 26 Jun 2013 12:51:10 GMT) Full text and rfc822 format available.

Notification sent to Vincent Lefevre <vincent@vinc17.net>:
Bug acknowledged by developer. (Wed, 26 Jun 2013 12:51:10 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 06 Aug 2013 07:31:06 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 17 04:51:31 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.