From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) Gecko/20070718 Fedora/18.104.22.168-1.fc7 Firefox/22.214.171.124
Description of problem:
After starting system-config-printer, I choose "New Printer" button.
Brings up a dialog where I can set a printer name, etc. I click "Forward"
It hangs with a wait cursor.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. See above
It hangs interminably (at least an hour). Ctrl-c does not work in the terminal from which the system-config-printer was executed. ctrl-z, kill %1 however does work.
Gone to the next dialog?
This program is completely opaque. Perhaps the most opaque of any of the system-config utilities.
Created attachment 160663 [details]
a trace file of the above hang
WORKAROUND --- bug source identified
Ok. I figured out what was causing the problem by setting LogLevel to debug in
/etc/cups/cupsd.conf. It turns out that the web pages (http://localhost:631/)
were looking in /usr/lib64/cups however there was no /usr/lib64/cups.
ln -s fixed that problem.
At first glance, this seems to still be a problem in fc8...
The cupsd.conf we ship says to look in /usr/lib/cups, so the problem lies with
whatever tool edited it (and note, system-config-printer does not edit
Please attach /etc/cups/cupsd.conf.
Created attachment 161023 [details]
requested cups config file
I went back through my history file for the printer configuration and this is
what I see:
97 cd /etc/init.d/
98 service cups restart
106 kill %2
Maybe the cupsdconf (part of kde) did the damage? I tried repeating with
cupsdconf but it doesn't seem to make the cupsd.conf look like the one I have.
Yes, that's definitely it. What does 'rpm -qf cupsdconf' say?
$ rpm -q -f /usr/bin/cupsdconf
Looks like we may want to consider omitting this from kdelibs.
Before omitting it from kdelibs, it needs to be digested. The configuration of
system-config-printer is extremely opaque to a new cups user. Especially when
trying to interact in a windows domain. That is why I tried cupsdconf, because
I was looking for a tool to give a useful selection on trying to point cups to a
windows print server...never did find anything useful... ended up just going to
directly to :9100 on each of the printers and bypassing our print server.
Also, are all the cups cgi scripts not 64 bit? Is cupsdconf right in expecting
to find them in lib64?
Joel: I am aware that work is needed in system-config-printer for Windows shared
printers. Other bugs are open for this.
cupsdconf is incorrect in expecting the CUPS ServerBin path to be
/usr/lib64/cups. Although the binaries are indeed 64-bit, they are executables
not shared libraries, and are only in /usr/lib instead of /usr/libexec for
compatibility with upstream and other 3rd parties.
The issue here is that cupsdconf must not write incorrect cupsd.conf files.
Right (what Tim said. :) ). We can always certainly try patching kdelibs to do
the right thing here, (patches always welcome).
otoh, it simply makes little sense to me to include > 1 tool for the same job,
especially when one (cupsdconf) is known to by buggy. *shrug*.
Concur. Note that cupsdconf didn't help me either...it hadn't clicked that it
was not part of cups until after I ran it and said "wow...the cups folks used
kde?"...I had gotten cups to work on redhat 9 and I loved it...unfortunately I
had forgotten that the real interface is the web interface on 631.
Maybe system-config-printer can point that way? Anywho, it seems that if we
just wack cupsdconf it would give more fuel to the fedora hates kde meme.
Joel: does the CUPS web interface show you available printers that
system-config-printer does not? (I hope not: it uses the same API as the CUPS
Ok..that was strange. (comment #13 reposting). The CUPS web interface does not
show printers that system-config-printer does not.
*** This bug has been marked as a duplicate of 230979 ***