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.
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
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
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.)
this is part of the filesystem rpm. It is ALWAYS there. Having rpms add bits
they need that are part of this base leads to madness.