From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031027 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): redhat-config-printer-gui-0.6.79-1 How reproducible: Always Steps to Reproduce: 1. Boot 2. Run gnome-print-manager 3. See there is wrongly no printer reported, run the printer setup app it suggests 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 to gnome-print-manager Actual Results: As described, printer was not visible to user until 'edited' Expected Results: Printer should have been visible to user from boot, like it is on all other machines here Additional info: 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 noticed this: [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?
Yes, maybe.