Le 13/09/2019 à 12:58, Brian Potkin a écrit : > reassign 940019 cups-browsed > thanks > > On Thu 12 Sep 2019 at 23:25:48 +0200, Vincent Danjean wrote: > >> Le 12/09/2019 à 21:15, Brian Potkin a écrit : >>> There should not be any Brother (or Canon) files on the client. The job >>> should be processed completely on the server. This is why I wanted the >>> outputs of 'lpstat -l -e' and 'lpstat -t' (which were not sent). >> >> I'm back at home. Here are the results : >> >> $ lpstat -l -e >> brother permanent ipp://localhost/printers/brother implicitclass://brother/ > > "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. >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. 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" 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) >> I'm sure that my laptop was using the provided one (ie the one >> from Brother) because I can see it with 'git diff' (my /etc is >> handled with etckeeper). Looking at the history, it appears and >> disappears regularly (depending if my laptop is at home or not) >> until 2018-03-26 when I added these ppd files in the .gitignore... >> What I do not know is where the ppd file was coming from (each time >> the laptop was at home, the printer was rediscovered and the PPD file >> reinstalled) > > 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 result is that the printing system is unusabled for now. Both at home and at work, I cannot manage important options. For others that can read this bug report, I found a partial workaround for this situation: completely bypass the local cups/ cups-browsed servers with the bad PPD files, and directly talk to the remote cups server. This can be done by using the CUPS_SERVER envvar or the ~/.cups/client.conf file as said in documentation. $ lpoptions -l -pbrother | wc -l 2 $ CUPS_SERVER=cups.servername.domain lpoptions -l -pbrother | wc -l 18 The ~/.cups/client.conf is better for already opened programs (libreoffice, thunderbird, ...) as changing this file is taken into account immediately (no need to restart the program in a changed environment). And then, you get access to all the options available in the cups server. That said, it is just a workaround because it is not very convenient to change this file, and the settings must be removed to access local printer (such as the virtual cups-pdf printer) Regards, Vincent