Bug#940019: cups: No more options for remote shared printers
reopen 940019
thanks
On Fri 13 Sep 2019 at 22:28:04 +0200, Vincent Danjean wrote:
> Le 13/09/2019 à 12:58, Brian Potkin a écrit :
[...]
> > "permanent" indicates local queues. There are two URIs. The second is
> > one managed by cups-browsed; the first is something set up by you. I
> > doubt this arrangemment will work reliably.
>
> No. Unless I'm mistaken, the "permanent" queue is setup by cups-browsed.
Indeed it is, and it is a local queue. However, I think I have not
interpreted the output correctly, so withdraw my remark about doubting
reliability.
> From its own doc :
> # With OnlyUnsupportedByCUPS set to "No", cups-browsed creates queues
> # for all printers which it supports [...] As queues
> # created by cups-browsed are permanent CUPS queues [...]
> # [...] This setting is the default.
>
> And indeed, I do not change this settings.
> So, the "permanent" queue comes from cups-browsed.
Agreed. 'lpstat -p <queue>' shows this with "cups-browsed=true".
> I also checked it by :
> 1) stopping cups and cups-browsed
> 2) checking that no reference to a "brother" printer exists in
> all files under /etc/cups (I removed /etc/cups/printers.O for example)
> 3) removing all files under /var/cache/cups/
> 4) restarting cups
> => the brother printer was not listed by "lpstat -l -e"
Would give the output of 'lpoptions -p <queue> -l' (please see below)
and attach the CUPS generated PPD in /etc/cups/ppd. You have a minute to
do this before the PPD disappears.
> 5) restarting cups-browsed
> => the brother printer appears as before with "lpstat -l -e", ie:
> brother permanent ipp://localhost/printers/brother implicitclass://brother/
>
> >> Brother_DCP_9020CDW_kooot_2 network none ipps://Brother%20DCP-9020CDW%20%40%20kooot-2._ipps._tcp.local/cups
> >
> > This appears to be a print queue or printer on the network.
>
> This one is directly discovered by cups itself (appears at step 4 above)
>
> > From the information provided, and what you have said, it appears you
> > are processing a print job twice; this is not a setup supported by
> > Debian. I have triaged enough reports involving this situation to know
> > that it generally leads to grief for both parties. I am closing the
> > report on that basis.
>
> I perhaps did it. But it is not the case anymore as the PPD file
> on the laptop is now (wrongly) generated by driverless. And I doubt
> it was the case before, because even if I remember I gave the PPD
> at install time, I never install the binary drivers/filters
> as it is done on the server.
The reason I gave for closing the report was not valid, so it has been
reopened. However, I have been remiss in not drawing your attention to
your use of the lpoptions command, which I noticed at the very beginning
but stupidly let go past.
The option order is significant. 'lpoptions -p <queue> -l' is what
should be used for printer specific options and their current settings.
What do you get with 'lpoptions -p brother -l'? Would you also post the
PPD in /etc/cups/ppd that cups-browsed generates.
> The result is that the printing system is unusabled for now.
> Both at home and at work, I cannot manage important options.
I believe we can restore the home system to your control.
Cheers,
Brian.
Reply to: