Red Hat Bugzilla – Bug 26921
printing to remote printer doesn't work
Last modified: 2007-04-18 12:31:23 EDT
Setting up a remote lpd queue via printconf does not result in a working
printer config (tested with an hp lj6 and filters configured on both ends).
Printing via 'lpr -Plp@host foo' works fine. Output from lpq -L is as
Status: subserver pid 4235 starting at 00:42:12.211
Status: accounting at start at 00:42:12.211
Status: opening device '/dev/lp0' at 00:42:12.211
Status: printing job 'root@rivendell+668' at 00:42:12.212
Status: processing 'dfA668rivendell.ncssm.net', size 594564, format 'f',
IF filter 'mf_wrapper' at 00:42:12.212
Status: IF filter 'mf_wrapper' filter msg - 'can't print HP PCL printer
data - US letter page size files' at 00:42:12.255
Status: IF filter 'mf_wrapper' filter msg -
'/usr/share/printconf/mf_wrapper: exit: bad non-numeric arg `RETVAL'' at
Status: IF filter 'mf_wrapper' filter exit status 'UNKNOWN STATUS '128''
Status: printing finished at 00:42:12.260
Status: accounting at end at 00:42:12.260
Status: finished 'root@rivendell+668', status 'UNKNOWN STATUS '128'' at
Status: subserver pid 4235 exit status 'UNKNOWN STATUS '128'' at 00:42:12.261
Status: job 'cfA668rivendell.ncssm.net' error 'aborting operations' at
Status: removing job 'cfA668rivendell.ncssm.net' - ABORT at 00:42:12.278
This defect is considered MUST-FIX for Florence Release-Candidate #1
Please attach a copy of:
and the output of:
also, where you sending non-standard data? (Like, say, PCL?)
Attachments coming right up, but to be a bit more verbose about the setup. Note
that this setup worked properly with 7.0, so it's entirely possible someone
could end up with such a configuration
MachineA has printer plugged into parallel port, printer is configured as 'lp'
with filter configuration set up for the HP LaserJet 6L. Printing from MachineA
MachineB has remote lpd spool set up in printconf. Remote spool is lp@MachineA
with filter config for the HP LaserJet 6L.
Created attachment 9860 [details]
/etc/printcap off of machine B
Created attachment 9861 [details]
mf.cfg from machineB
Created attachment 9862 [details]
zcat'd local.adl from machineB
Right, there was an error in mf_wrapper, but that isn't what's killing you.
What are you printing? Is it raw PCL, because:
Status: IF filter 'mf_wrapper' filter msg - 'can't print HP PCL printer data -
US letter page size files' at 00:42:12.255
Implies that it is, in fact, raw PCL, that you are sending. Now, this printer
supports raw PCL, but the database scan can't see that, because it's not listed
as doing so. If you wish to force it to send raw PCL (or whatever) without
filtration (and all it's magic), set up a Raw print queue on machine B, and it
won't reject the job. I will try to get better prediction of capabilities.
But is it PCL that you are printing? What are you printing with? (is it gimp?)
It's raw pcl as it's already been processed by the print filters on machine B.
The abort occurs in the filters on machine A (which isn't clear from the lpq
log, bleah, sorry about that). The print job in question is nothing more than
the postscript test page being printed from within printconf-gui, but the same
occurs whenever your print a postscript file off of machineB as the local
filters on machine B process it to PCL and then shove it across the network to
You'll have to make a raw printer queue. lp -oraw seems to be completely broken
right now. :-(
Which will foul up a lot of people's existing configurations when they upgrade :(
I dont want to just let PCL through, I have no reason to assume that a given
printer supports it, except for a few clues in the pnp information.
This is a bad magic versus dangerous control character problem, and either way I
handle it, it's gonna piss off somebody. Okay, fine. I'll let PCL, PJL, et all
And if I get bugs on that behaviour (and I will, and they will be hard to
classify), I'll mark 'em WONTFIX.