Red Hat Bugzilla – Bug 8288
Printer accounting broken in lpr-0.48
Last modified: 2008-05-01 11:37:53 EDT
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: starting for mwilson
Jan 7 21:06:01 rei ifpap: accounting with psa
Jan 7 21:06:01 rei ifpap: sending to pap
Jan 7 21:06:01 rei ifpap: PostScript
Jan 7 21:06:50 rei ifpap: 21659 done
Jan 7 21:06:50 rei ifpap: 21658 done
Jan 7 21:06:50 rei ifpap: 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: Too many arguments
Jan 7 21:23:38 rei lpd: 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.
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.
Ok, what's the -j option supposed to do? Tell the filter where to get input
I assume -j is the jobname as seen in lpq. The filter always reads the
Try 0.50-2 or 0.50-3