Bug 132115

/etc/printcap has not been authoritative for some time.

Need to see 'printconf-tui --Xexport' output to have an idea of the
configuration state.

Created attachment 103642 [details]
results of 'printconf-tui --Xexport'

In the meantime the machine in question was shut down and after it was
brought up again printing on both queues works again.

Yesterday, after changes via 'printconf', the second queue had a big red
cross over it in GUI while jobs sent to the first one were simply vanishing
without any trace and not showing up on a printer - which is even worse.
No amount of mucking around in 'printconf-gui' with "Edit" and "Apply" had
an apparent effect on the situation although I have to admit that I did
not try simple 'service cups restart' (which I would likely do right away
on a non-test installation).

As for /etc/printcap - I realize perfectly well that it is not authoritative
but it could be at least not misleading.  What about a comment:

# this file is full of a random junk

for its entire content?  If that is not enough for some applications then
just a list of colon terminated printer queue names should be sufficient
and better than some crap-shot in fake properties.

BTW - what ate printer aliases?  Do I have to have multiple queues in lieu
of that?  __Big__ PITA in maitenance.

These are experiences after a series of a today updates on x86_64
machine.  After a fresh login 'gnome-printinfo', brought up via
"Print Manager" icon, tells me that I have no printers available
and offers to run a printer configuration tool.  I agree and I am
getting a 'printconfig' window, after a very looong read, with
my only on this box printer queue configured and all data correct.
Without any changes I click, for a good measure, on "Apply" and
that is enough for 'gnome-printinfo' to wake up and recognize
that I have a printer configured after all.  It is even possible
to print on it - which is a nice bonus.

It is possible that glibc updates may have something to do with
the above but one would expect a printer daemon still function.

What does this say?:

/sbin/chkconfig --list cups

/sbin/chkconfig --list cups
cups     	0:off	1:off	2:on	3:on	4:on	5:on	6:off

And here is more fun courtesy of the whole printing setup.
I noticed that a small new icon showed up on my toolbar.  After
squinting on it for a while it looked like a printer.  Clicking
on it opened a window with a "Document print status" title.
It has one line in it which says:

Unknown  lp   ?   1 hour and 5 minutes ago   Unknown

This apparently refers to my test print job which I did after
I managed to get my printer back in action and which finished
in about that time.  "Edit" on that line offers options like
"Cancel Documents", "Pause Documents", "Resume Documents".
Regardless of what I am choosing and what I do in the followup
that does not seem to have any effect whatsoever.  'lpq' says:

lp is ready
no entries

and 'lpc' agrees with it.  Now what?

Please stop adding more bugs into the same report.

Let's stick to the bug you first reported: queues stopped working. 
File the others into separate reports, since they are for separate
components.

I am not really sure what the issues really are but if you prefer
I will re-file some comments as separate reports.

Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Closing per lack of response to previous request for information.
Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.