Bug 59949 - printconf 0.3.61-3 will not add a new print queue
printconf 0.3.61-3 will not add a new print queue
Status: CLOSED DUPLICATE of bug 59481
Product: Red Hat Linux
Classification: Retired
Component: printconf (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2002-02-15 11:36 EST by Matt Arnold
Modified: 2007-04-18 12:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-02-25 21:27:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Local.adl file using printconf 0.3.61-3 (421 bytes, application/octet-stream)
2002-02-15 11:55 EST, Matt Arnold
no flags Details

  None (edit)
Description Matt Arnold 2002-02-15 11:36:36 EST
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:

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.
Comment 1 Tim Waugh 2002-02-15 11:38:26 EST
Please attach /etc/alchemist/namespace/printconf/local.adl.
Comment 2 Matt Arnold 2002-02-15 11:55:48 EST
Created attachment 45819 [details]
Local.adl file using printconf 0.3.61-3
Comment 3 Tim Waugh 2002-02-22 09:17:28 EST
What happens if you run 'printconf-backend --force-rebuild' as root?  Does
/etc/printcap get populated then?
Comment 4 Matt Arnold 2002-02-22 12:01:27 EST
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.
Comment 5 Russel Winder 2002-02-25 11:43:21 EST
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.
Comment 6 Peter Surda 2002-02-25 21:27:16 EST
EXACTLY same problem (/etc/printcap not generated) and EXACTLY the same cure (install mpage). I suggest to the maintainer to add mpage to RPM 
Comment 7 Tim Waugh 2002-02-26 03:43:56 EST

*** This bug has been marked as a duplicate of 59481 ***
Comment 8 kop 2002-04-29 12:01:48 EDT
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.

Comment 9 Tim Waugh 2002-04-29 12:11:46 EDT
kop@meme.com: 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. 

Note You need to log in before you can comment on or make changes to this bug.