Red Hat Bugzilla – Bug 109491
users unable to print with configured printer until printconf-gui or tui run and printer edited after each boot
Last modified: 2007-11-30 17:10:33 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Description of problem:
On one machine here, an IBM R31 laptop 1.2GHz Celeron, both on the
original RH9 install and after an upgrade to FC1, users cannot print
after a boot until the pre-existing printer is edited and any changes
applied in printconf-gui or printconf-tui. Before this, opening
gnome-print-manager shows no printers and brings up a dialog saying
that there are no printers and asking if we would like to spawn
printconf-gui. If you use printconf-gui, make a fake edit and
'accept' the change, then subsequently the printer appears correctly
in gnome-print-manager and the user can print from OO or other
applications. But the next boot will suffer from the same problem
with no printer found.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2. Run gnome-print-manager
3. See there is wrongly no printer reported, run the printer setup app
4. Make a fake edit in the already existing printer instance shown there
5. Accept the edit
6. Exit printconf-gui and see that the existing printer is now visible
Actual Results: As described, printer was not visible to user until
Expected Results: Printer should have been visible to user from boot,
like it is on all other machines here
Its set up for an Epson E740 via cups to another machine.
This occurs just on this one machine, several machines here with
Fedora or RH9 do NOT suffer this.
Does 'printconf-backend' (as root) have the same effect as editing and
applying changes? How about 'printconf-backend --force-rebuild'?
No, running printconf-backend with or without the --force-rebuild
switch does not improve the situation.
However, I did this over ssh running the utils from the commandline, I
[root@nicecat root]# gnome-print-manager
lpstat: Unable to connect to server: Connection refused
This set me thinking, it seems that on this machine in some distant
past time of struggle I disabled cupsd. I found that running cupsd
from the commandline DOES have the same effect as the edit in printconf.
Although this is clearly 'operator error', maybe if
gnome-print-manager is prepared to spawn printconf-gui when there are
no printers, one or the other should check to see if cupsd is running
(wasn't there a change to cups in Fedora?) and prompt the
operator/idiot who disabled it with a specific warning?