Bug 18208 - print queues did not upgrade
Summary: print queues did not upgrade
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: LPRng   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Crutcher Dunnavant
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-10-03 12:30 UTC by rich gregory
Modified: 2007-04-18 16:28 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-10-04 21:33:41 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description rich gregory 2000-10-03 12:30:21 UTC
The local LPT1 print queue that was set up in RH 6.2 did not work when I 
upgraded to RH 7.0 using the disk1-2 ISO files (burned to cdroms) on your 
web site.

A simple delete queue / add queue operation fixed the problem.

Comment 1 Michael Fulbright 2000-10-03 18:51:34 UTC
This is most likely a problem with the LPRNG package.

Comment 2 Crutcher Dunnavant 2000-10-04 18:42:59 UTC
This is most likely a problem with rhs-printfilters, but please answer the
following:

Those print queues, were they set up with a version of rhs-printfilters older
than the one that was on your system at install time? If they were, then this is
documented in the release notes,
anyway, I'd like to know.

Comment 3 Crutcher Dunnavant 2000-10-04 21:33:38 UTC
Posted from email: Rich Gregory <rtg2t@cms.mail.virginia.edu> wrote:

The key word is upgrade.  This machine has been running redhat for a long
time.  The last full install was 5.x.  I can look if it is really
important.  It is at home....
  
rich


Comment 4 Crutcher Dunnavant 2000-10-04 21:38:33 UTC
Okay, this is a KNOW issue. It can't be fixed. In the past, printtool copied the
master print filter into a spool directory when it set up a spool. This was
wrong, as when the actions of the filtration system changed, they still used the
old filter residing in the spool directory. Now, printtool leaves a symlink to
that filter, and that might become even more transparent in the future. So on
upgrade, rhs-printfilters tries to decide if this state exists on the machine,
and fix it.

It cannot be very smart about this, so it errs on the side of caution, and ONLY
performs its fix if the filter in the spool directory EXACTLY matches the filter
in therhs-printfilters package on the machine at time of upgrade.

This is all descirbed in the release notes.


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