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.