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 follows: 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 00:42:12.259 Status: IF filter 'mf_wrapper' filter exit status 'UNKNOWN STATUS '128'' at 00:42:12.259 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 00:42:12.260 Status: subserver pid 4235 exit status 'UNKNOWN STATUS '128'' at 00:42:12.261 Status: job 'cfA668rivendell.ncssm.net' error 'aborting operations' at 00:42:12.270 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: /etc/printcap /var/spool/lpd/SPOOLNAME/mf.cfg and the output of: bzcat /etc/alchemist/namespace/printconf/local.adl
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 works fine. 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 machineA.
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 through. And if I get bugs on that behaviour (and I will, and they will be hard to classify), I'll mark 'em WONTFIX. humbug.