Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 8288 - Printer accounting broken in lpr-0.48
Printer accounting broken in lpr-0.48
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: lpr (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-01-08 00:58 EST by mwilson
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-03 13:08:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description mwilson 2000-01-08 00:58:03 EST
Ok... who thought it was a good thing to break printer accounting in the
new lpr?  0.47 in RawHide had the same weirdism, but I figured hey, that's
RawHide, and I didn't say anything.

But 0.48 has the same flaw.

With 0.46 -->

Jan  7 21:06:01 rei ifpap[21657]: starting for mwilson
Jan  7 21:06:01 rei ifpap[21657]: accounting with psa[21658]
Jan  7 21:06:01 rei ifpap[21657]: sending to pap[21659]
Jan  7 21:06:01 rei ifpap[21657]: PostScript
Jan  7 21:06:50 rei ifpap[21657]: 21659 done
Jan  7 21:06:50 rei ifpap[21657]: 21658 done
Jan  7 21:06:50 rei ifpap[21657]: done

Notice it works, and I get toner on paper...

and with 0.48 -->

Jan  7 21:23:26 rei lpd: lpd shutdown succeeded
Jan  7 21:23:26 rei lpd: lpd startup succeeded
Jan  7 21:23:38 rei ifpap[21856]: Too many arguments
Jan  7 21:23:38 rei lpd[21855]: laser: job could not be printed
(cfA546rei.moonkingdom.net)

And now it doesn't.

RH6.0 with patches and netatalk-1.4b2+asun2.1.3-6.

If accounting only works now with rh-printfilters, you could at least tell
someone.  Or maybe the calling syntax for the filter has been changed, in
which case changing the documentation might be a good idea so someone
might have a chance of altering the filter.

My /etc/printcap looks like:

lp|laser:\
        :sd=/var/spool/lpd/lp:\
        :af=/var/account/lpacct:\
        :mx#0:\
        :sh:\
        :lp=/dev/null:\
        :if=/usr/lib/atalk/filters/ifpap:

The printer is a LaserWriter IIg on ethernet... there is no Mac involved.
Comment 1 jdalbec 2000-01-12 00:02:59 EST
Apparently ifpap is not recognizing the -j option now being passed to it.
I set up a fake printer to dump the arguments to if:
-w132 -l66 -i0 -n john -h linus.localdomain -j stdin /var/tmp/acct
Comparing this with netatalk/etc/psf/psf.c reveals that -j is not recognized.
Comment 2 mwilson 2000-01-12 01:52:59 EST
Ok, what's the -j option supposed to do?  Tell the filter where to get input
from?
Comment 3 jdalbec 2000-01-12 17:33:59 EST
I assume -j is the jobname as seen in lpq.  The filter always reads the
standard input.
Comment 4 Bernhard Rosenkraenzer 2000-02-03 13:08:59 EST
Try 0.50-2 or 0.50-3

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