Bug#851705: marked as done (cups-browsed: Only one queue is allowed when CreateIPPPrinterQueues is used)
Your message dated Thu, 26 Jan 2017 12:08:11 +0000
with message-id <26012017100132.cb76cc77af57@desktop.copernicus.org.uk>
and subject line Re: Bug#851705: cups-browsed: Only one queue is allowed when CreateIPPPrinterQueues is used
has caused the Debian Bug report #851705,
regarding cups-browsed: Only one queue is allowed when CreateIPPPrinterQueues is used
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
851705: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851705
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: cups-browsed
Version: 1.13.2-1
Severity: normal
Tags: upstream
The creation of a queue with CreateIPPPrinterQueues couldn't be easier
but auto-generation of a PPD gets default default values for the printer
capabilities. I think it is legitimate (and long-established practice)
for other queues with different options for the same printer to be
capable of being set up.
This cannot be done with CreateIPPPrinterQueues so another tool (the web
interface, s-c-p or lpadmin) would have to be used. However, after
setting up another queue and restarting cups-browsed, the original
CreateIPPPrinterQueues queue disappears.
Of course this may be simply the way it is meant to work. In which case
we can close this report.
--
Brian.
--- End Message ---
--- Begin Message ---
On Tue 17 Jan 2017 at 19:25:07 +0000, Brian Potkin wrote:
> The creation of a queue with CreateIPPPrinterQueues couldn't be easier
> but auto-generation of a PPD gets default default values for the printer
> capabilities. I think it is legitimate (and long-established practice)
> for other queues with different options for the same printer to be
> capable of being set up.
>
> This cannot be done with CreateIPPPrinterQueues so another tool (the web
> interface, s-c-p or lpadmin) would have to be used. However, after
> setting up another queue and restarting cups-browsed, the original
> CreateIPPPrinterQueues queue disappears.
>
> Of course this may be simply the way it is meant to work. In which case
> we can close this report.
This is what I have from 'lpinfo -v':
network dnssd://HP%20ENVY%204500%20series%20%5BFAFAC2%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-308d99fafac2
network socket://192.168.7.235:9100
network ipp://envy4500.local:631/ipp/print
socket://... cannot be used to set up a driverless queue because the
transport protocol is not IPP. ipp://envy4500... is the URI produced
by the driverless utility and is the one I used to set up a second
queue which led to the observation above:
lpadmin -p ... -v ipp://envy4500... -E -m everywhere
My understanding of the dnssd backend is that a URI is constructed
from a Bonjour txt record and the transport protocol is IPP.
lpadmin -p ... -v dnssd://HP%20ENVY... -E -m everywhere
would appear to be equivalent to the previous command.
Using this URI it is possible to set up more queues and not have the
original CreateIPPPrinterQueues queue disappear. Printing to the
queue is successful. So, viewing the issue as a problem to be solved
rather than a bug in cups-browsed, I'll close this report.
Cheers,
Brian.
--- End Message ---
Reply to: