Bug 8288 - Printer accounting broken in lpr-0.48
Summary: Printer accounting broken in lpr-0.48
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: lpr
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-01-08 05:58 UTC by mwilson
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-02-03 18:08:02 UTC

Attachments (Terms of Use)

Description mwilson 2000-01-08 05:58:03 UTC
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

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:


The printer is a LaserWriter IIg on ethernet... there is no Mac involved.

Comment 1 jdalbec 2000-01-12 05:02:59 UTC
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 06:52:59 UTC
Ok, what's the -j option supposed to do?  Tell the filter where to get input

Comment 3 jdalbec 2000-01-12 22:33:59 UTC
I assume -j is the jobname as seen in lpq.  The filter always reads the
standard input.

Comment 4 Bernhard Rosenkraenzer 2000-02-03 18:08:59 UTC
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.