From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:
If /var/spool/lpd is missing, printconf-backend will scream and die when
you ask it to rebuild the /etc/printcap files.  The symptom could be fixed
by making printconf-backend smarter, but /var/spool/lpd needs to exist,
always, when the local system uses LPRng.  Therefore, I think it's LPRng's
responsibility to make sure that directory exists.

How reproducible:
Always

Steps to Reproduce:
# rm -rf /var/spool/lpd

Then run printconf-gui from a terminal window and hit the Apply button. 
You'll see a Python backtrace in the terminal.  This leads you to the code
where it's trying to walk the tree underneath /var/spool/lpd looking for
"volatile" directories.

Additional info:

I came across this problem while trying to fix a printing problem.  The
machine had been upgraded from RH6.2 to 7.1 -- printing worked before the
upgrade, and didn't afterward.  I decided to remove everything I could find
related to printing: /var/spool/lpd/*, /etc/printcap*, the LPRng and
printconf RPMs, etc.  I then reinstalled the RPMs, assuming they'd bring
the print sybsystem back to a working state, so I could re-create my
printer.

Strictly speaking, I caused this problem, but a core directory like
/var/spool/lpd should have an RPM package that owns it and is responsible
for re-creating it when someone blows it away.

(For what it's worth, the _real_ problem turned out to be a conflict with
the old LPT1 port, 0x3BC -- I think the vesafb feature interferes with it. 
I changed the port in the BIOS to 0x378 and it began working.)