From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221 Description of problem: Using the copy feature of xsane, I discovered that calls using <lpr -#> fail. Xsane 0.82 crashed completely when set to >1 copy. I upgraded to 0.84 -- it still returns "Fatal error..." but handles it better--no crash, just dialog box. Invoking lpr from command line returns the same message. This does not result in any nasty residual system behavior as far as I can tell (hung processes, instability, crashed lpd, etc.). Version-Release number of selected component (if applicable): LPRng-3.7.4-28 How reproducible: Always Steps to Reproduce: 1. do something that invokes <lpr -# or -K> where #/K > 1 2. 3. Actual Results: returns "Fatal error - Maximum of 1 copies allowed" Expected Results: I should have got 2 or more copies printed. Additional info:
Yep. I'd like to see if I can find what's causing this and fix it for the next release.
This is caused by LPRng's default for 'mc', which can be adjusted in /etc/lpd.conf. Put 'mc#128' in there, for example. I'll adjust this default for the next LPRng build.
Yes, thanks! I'm embarrassed that I overlooked it in man, but I was fixated on -# and -K. Maybe it should have, but checking for printcap options never occurred to me. I wonder, since changing mc# is so easy, perhaps simply changing the diemsg to point the user to lpd.conf or printcap.local would be easier than trying to pick a default that pleases everyone, and could save users from scouring man pages for the right reference? For example: "Maximum <n> copies allowed, set default in lpd.conf"
I'll mention it to the maintainer. For now I've just set the default to something sane. 3.8.5-3.
*** Bug 63124 has been marked as a duplicate of this bug. ***
*** Bug 63649 has been marked as a duplicate of this bug. ***