Red Hat Bugzilla – Bug 59949
printconf 0.3.61-3 will not add a new print queue
Last modified: 2007-04-18 12:40:26 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
Description of problem:
I am running a fully patched version of Red Hat 7.2. After updating to printconf
0.3.61-3, lpd started reporting "no printers defined" on boot-up. If I would run
printconf or printconf-gui the printer would show up there, but attempting to
print test pages would fail. After further investigation, I found that it was
not writing anything to /etc/printcap. After reverting to printconf 0.3.52-1,
everything works fine again. This is with a Hewlett-Packard DeskJet 810C
attached to /dev/lp0.
As a minor point, printconf (0.3.52-1 and 0.3.61-3) identifies my printer as a
DeskJet 812C, even though the kernel properly identifies it as an 810C. That's
probably unrelated and does not affect printing at all.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Upgrade printconf and printconf-gui to 0.3.61-3
2. Attempt to add a new print queue
3. Try to print a test page
Actual Results: Nothing is written to /etc/printcap, lpd appears to start fine
(although it actually doesn't), an error message pops up saying that there was
an error trying to print the test page.
Expected Results: /etc/printcap should be written with the proper information,
lpd should start fine, and the test page should print.
This bug showed up on both a Celeron 400a-based system and an Athlon XP 1800+
system, both using a DeskJet 810C. It is a very annoying bug. If I can't print,
my computer is little more than a paperweight for getting real work done.
Please attach /etc/alchemist/namespace/printconf/local.adl.
Created attachment 45819 [details]
Local.adl file using printconf 0.3.61-3
What happens if you run 'printconf-backend --force-rebuild' as root? Does
/etc/printcap get populated then?
Yep, /etc/printcap gets populated and the printer works. In so doing, I think I
have discovered the problem. printconf-rebuild complained that it couldn't file
/usr/bin/mpage. After I installed the mpage RPM, the rebuild worked and
/etc/printcap was populated.
Just for testing purposes, I deleted the print queue I had just set up. I
checked to make sure that /etc/printcap was empty again (except for the various
comments). Then I started printconf-gui again and tried to add the print queue
again. This time everything worked fine. It would appear that the printconf RPM
needs another dependency check to make sure that mpage is installed. If mpage
isn't installed, printconf will not write anything to /etc/printcap and it will
not give an error message.
Just to reinforce the issue. I upgraded printconf and printconf-gui from
whatever it was in the standard RedHat 7.2 distribution to 0.3.61 using
red-carpet. Printing ceased to work. This is because the old /etc/printcap
file was emptied. Using printconf-gui to try and "re-install" the printers
failsleading to No Printers.
Installing mpage package (which was not previously installed) appears to cure
the problem. I have no idea why but it seems to work.
EXACTLY same problem (/etc/printcap not generated) and EXACTLY the same cure (install mpage). I suggest to the maintainer to add mpage to RPM
*** This bug has been marked as a duplicate of 59481 ***
Simply having mpage installed does _not_ fix this problem.I have the latest
updates to 7.2 and mpage installed and still have almost the same problem.
If you create a single print queue, stop and start printconf-gui, and try to
create another print queue, the second print queue does not make it into
/etc/printconf or /var/spool/lpd. It does show up in the gui through.
Running 'printconf-backend --force-rebuild' as root updates printcap and make
the queue directory.
firstname.lastname@example.org: it's working for me, so I'll need more information. What do you
mean by 'stop and start printconf-gui'?
To save the reporter of this bug getting mail they don't want, could you
please open a new bug report? This has already been marked as a duplicate of
a bug with a known cause, which is different to the one you are describing.