Bug 109491

Summary:	users unable to print with configured printer until printconf-gui or tui run and printer edited after each boot
Product:	[Fedora] Fedora	Reporter:	Andy Green <andy>
Component:	redhat-config-printer	Assignee:	Tim Waugh <twaugh>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-01-25 14:52:10 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andy Green 2003-11-08 14:48:18 UTC

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.

Comment 1 Tim Waugh 2003-11-08 19:52:55 UTC

Does 'printconf-backend' (as root) have the same effect as editing and
applying changes?  How about 'printconf-backend --force-rebuild'?

Comment 2 Andy Green 2003-11-09 10:27:29 UTC

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?

Comment 3 Tim Waugh 2003-11-10 09:56:35 UTC

Yes, maybe.