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): How reproducible: Always 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. Additional info: 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 dependencies).
*** 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.
kop: 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. Thanks.