Version: desconocido (using KDE 3.5.3, Debian Package 4:3.5.3-1 (testing/unstable)) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.15 I'm very tired because a bug in Kdeprint in Kubuntu Breezy and Dapper: I know many computers with Kubuntu with a common printer installed which many times is "disabled" in the start of the system. Just it. The printer works well the 50% of times, but the other 50% it appears as "disabled" and the user must go to kdeprint and "Activate" (or "Enable") the printer manually. There is no reason for this bug, but it just occurs and is annoying for common users. I've only seen it in Kubuntu Breezy and Dapper. In all the cases with USB HP printers. It could be a problem of Kubuntu inself, of course, but because I'm not sure of that I report it here too.
KDEPrint does not decide to enable/disable printers alone. It requires an action from the user. If a printer is appears disabled, it means that the CUPS spooler has decided to disable it. Try to start your system, then without trying to print with KDE, go to http://localhost:631 and check the printer state. If it's disabled, KDEprint cannot do anything about it.
Yes, I know that it's not normal that Kdeprint decides to enable/disable a printer alone. But it's a bug that I've only seen in Kubuntu. Anyway I have realized that it occurs too in Debian (people told me), so it must be a Cups issue. Thanks.
I really meant "KDEPrint does not disable a printer alone". If the printer is disabled, this is because CUPS told KDEPrint about it, but KDEPrint is not responsible for the disabled state.
Sorry, ibc, this is a "standard" behavior of CUPS. If a CUPS backend can't contact the printer any more for some reason (switched off, changed usb:/ device address, whatever...) it disables the queue. There is a workaround for this available at Linuxprinting.org. It is called the "backend error handler", or beh. beh is a wrapper around any other available backend. It can be used to run these backends, and CUPS will "see" only beh and beh's return values. In turn, beh can be set to lie to CUPS about the real backend's return values and always say "Yes, I am still here", so CUPS will never disable the related printer. (You can also configure it to try printing for instance 25 times with a delay of 1 minute in between each attempt before CUPS is allowed to disable the queue.) beh is a Perl script, and you should read its initial comment section. Get it here: http://www.linuxprinting.org/download/printing/beh As Michael explained, it is not KDEPrint's fault that the backend/printer is disabled. It is rather a feature that KDEPrint informs the user about that state, and lets him re-enable the queue. :-) Setting this bug report to INVALID now....
Closing old Resolved status bug.