Bug 429275

Summary: Text files aren't printed
Product: [Fedora] Fedora Reporter: Horst H. von Brand <vonbrand>
Component: papsAssignee: Akira TAGOH <tagoh>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: rawhideCC: eng-i18n-bugs, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-02-01 09:20:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Requested "lpstat -s" output
none
The requested output
none
Requested error_log
none
Output of "lpstat -t" none

Description Horst H. von Brand 2008-01-18 13:37:36 UTC 
Description of problem:
When printing a plain text file:

  lpr TEXT

it shows up as a job for lpq(1), and then dissapears without being printed out.

Version-Release number of selected component (if applicable):
cups-1.3.5-1.fc9

How reproducible:
Always


Steps to Reproduce:
1. lpr random-text-file
2.
3.
  
Actual results:
Nothing printed

Expected results:
Printout

Additional info:
Comment 1 Tim Waugh 2008-01-18 14:29:13 UTC 
What does 'lpstat -s' say?
Comment 2 Horst H. von Brand 2008-01-18 18:40:06 UTC 
Created attachment 292184 [details]
Requested "lpstat -s" output

In any case, other types of stuff (did PS, PDF recently) prints OK.
I fixed the permissions problem on the USB device by hand (see BZ 429000).
Comment 3 Tim Waugh 2008-01-19 18:43:06 UTC 
1. Enable debugging output:
cupsctl --debug-logging
2. Stop cups:
/sbin/service cups stop
3. Clear out the error_log file:
>/var/log/cups/error_log
4. Start cups:
/sbin/service cups start

Now submit your print job as before and wait for 1 minute.  Then please attach
the /var/log/cups/error_log file to this bug report.
Comment 4 Horst H. von Brand 2008-01-21 12:33:50 UTC 
Created attachment 292358 [details]
The requested output
Comment 5 Horst H. von Brand 2008-01-21 12:39:23 UTC 
Created attachment 292359 [details]
Requested error_log

There was more output after the first I sent in.
Comment 6 Tim Waugh 2008-01-21 12:49:21 UTC 
What does 'lpstat -t' say?
Comment 7 Horst H. von Brand 2008-01-21 14:35:33 UTC 
Created attachment 292374 [details]
Output of "lpstat -t"
Comment 8 Horst H. von Brand 2008-01-21 14:36:46 UTC 
BTW, I just printed out a couple of webpages (through the net, even). No hitch.
It only hates textfiles.
Comment 9 Tim Waugh 2008-01-21 14:57:59 UTC 
Try this:

lp -o document-format=application/x-shell README

What happens?
Comment 10 Horst H. von Brand 2008-01-21 15:30:25 UTC 
Prints just fine.
Comment 11 Tim Waugh 2008-01-21 15:40:28 UTC 
What does 'rpm -q paps' say?
Comment 12 Horst H. von Brand 2008-01-21 17:12:37 UTC 
paps-0.6.8-3.fc9.x86_64 (rpm(1) configured to show the arch too)
Comment 13 Tim Waugh 2008-01-21 17:37:11 UTC 
Reassigning as it seems to be a paps problem.  I'll try to take a closer look at
this later in the week.
Comment 14 Horst H. von Brand 2008-01-21 20:42:07 UTC 
Looks that way, paps generates a .ps that crashes ghostscript, presumably the
interpreter in the printer goes south too.
Comment 15 Akira TAGOH 2008-01-23 02:02:00 UTC 
ok, confirmed a problem. trying to get a fix.
Comment 16 Akira TAGOH 2008-01-23 02:28:34 UTC 
should be fixed in paps-0.6.8-4.fc9.
Comment 17 Tim Waugh 2008-01-23 16:51:37 UTC 
Doesn't work for me.  I get this stack trace when trying 'lp /etc/fstab':

D [23/Jan/2008:16:49:22 +0000] [Job 2] Error: /rangecheck in --cvs--
D [23/Jan/2008:16:49:22 +0000] [Job 2] Operand stack:
D [23/Jan/2008:16:49:22 +0000] [Job 2] last_x   7416   (0)
D [23/Jan/2008:16:49:22 +0000] [Job 2] Execution stack:
D [23/Jan/2008:16:49:22 +0000] [Job 2] %interp_exit   .runexec2   --nostringval-
-   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--   --
nostringval--   --nostringval--   false   1   %stopped_push   1905   1   3   %op
array_pop   1904   1   3   %oparray_pop   1888   1   3   %oparray_pop   1771   1
   3   %oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringv
al--   --nostringval--   --nostringval--   2   %stopped_push   --nostringval--  
 --nostringval--   --nostringval--   %loop_continue   --nostringval--   --nostri
ngval--   --nostringval--   --nostringval--
D [23/Jan/2008:16:49:22 +0000] [Job 2] Dictionary stack:
D [23/Jan/2008:16:49:22 +0000] [Job 2] --dict:1166/1684(ro)(G)--   --dict:1/20(G
)--   --dict:77/200(L)--   --dict:31/42(L)--   --dict:7/11(L)--   --dict:13/21(L
)--   --dict:39/42(L)--   --dict:39/42(L)--
D [23/Jan/2008:16:49:22 +0000] [Job 2] Current allocation mode is local
D [23/Jan/2008:16:49:22 +0000] [Job 2] GPL Ghostscript 8.61: Unrecoverable error
, exit code 1
Comment 18 Horst H. von Brand 2008-01-23 21:39:03 UTC 
Running paps-0.6.8-4.fc9 here (i686) now gives a .ps that doesn't crash gs
(ghostscript-8.61-6.fc9), both with my original file and my /etc/fstab here. I
am away from the machine that couldn't print, so I can't check if the original
problem is gone.
Comment 19 Akira TAGOH 2008-01-23 23:48:16 UTC 
(In reply to comment #17)
> Doesn't work for me.  I get this stack trace when trying 'lp /etc/fstab':

That works for me. please make sure if you are using the above version of paps.
from the operand stack, that looks like the older version of paps.
Comment 20 Tim Waugh 2008-01-24 10:40:42 UTC 
Yes, I must have been looking at the wrong machine or something.  Works for me,
thanks.
Comment 21 A S Alam 2008-02-01 09:20:03 UTC 
it is working fine with following vesion:
paps-0.6.8-4.fc9.i386