Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: I'm using the most recient FC3 release (2.6.10-1.741_FC3), and noticed that the "Printer Configuration" applet would not display. Starting it by hand revealed the problem in two of the python scripts used. In both queueTree.py and cups_import.py, the assumption is made that there is an active spooler, so the call to os.popoen ('LANG=C /usr/sbin/alternatives --display-print') returns a valid file pointer. I "fixed" the problem by modifying the code to initalize "which" to "" so the functions would have something to return when no printer list was returned and the "for" loop was executed 0 times. I was then able to (re)configure my printer. (Um, I have no idea why the spooler disappeared.) Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Attempt to open the "Printer Configuration" applet when no printer is properly configured 2. 3. Actual Results: Applet was not displayed (actually, blinked up and dissapeared.) Expected Results: Applet should have been displayed Additional info: See discription for fix
Well, it's not the case that "no printer is properly configured" is the trigger for this -- it's that cups is not installed properly. The *real* problem is that your spooler disappeared. :-) Any idea why that happened?
No really. I'd been trying both Gnome annd KDE as desktops, and (I believe) KDE messes with the printer set-up. Since the "problem" I have upgraded CUPS at least once, and have had no further problem. But I don't know why the problem happened in the first place. (Printing had been working fine for several weeks [i.e., ever since I'd installed Fedora], and then just "stopped." That's why I was trying to bring up the printer configuration application to try to fix the problem. In fact, after I patched and ran the Python code, the problem was fixed.) In other words, I needed to run the code to configure things properly, but the code couldn't be run because thing weren't properly configured. This is refered to as "Catch 22." In any case, I would contend that "good programing practices" mandates that no assumption that a function call will not return a error code (when the function specified that it might do so) should be made. By checking that the list of spoolers was not empty, you would be able to pop a warning that CUPS was not properly configured rather than just failing to execute. And then the configuration could be fixed, as it was when I got the code to run.
The cups_import which_spooler() function is no longer used, so this particular issue should no longer be a problem.
*** Bug 155171 has been marked as a duplicate of this bug. ***