foomatic-rip fails

Can you do

cupsctl LogLevel=debug
cancel -a
cupsenable HL-5140

and then send a print job?

After that wait for the processing to stop (either the job disappears or gets into "Stopped" state) and then attach your /var/log/cups/error_log to this bug report.

I performed the above steps and then issued a 'lp strengths.pdf'. The error_log is attached.

foomatic-rip segfaults. Seems to be an upstream bug of foomatic-rip.

Lars, can you investigate this?

Note that here PostScript is fed into foomatic-rip (due to an old PPD file)

Mitchell Surface, can you do the following:

Start system-config-printer, right-click the icon for your Brother HL-5140 and choose "Copy" to make a copy of your print queue, Enter a new name, like "HL-5140-debug". Then right-click the "HL-5140" again and choose "Properties". You should be in the "Settings" section of the properties dialog. There click the "Change" button in the "Make and Model" line. After loading the driver list system-config-printer lets you choose manufacturer, model, and driver. Go with the default settings by simply clicking "Forward" several times and "Apply" in the end. This should update your PPD. Try to print. I ts should work now.

Now you have two print queues. Your old one should be in a working state now for daily printing. The new one is a copy of the state of your old queue as it did not work. Use it for the further steps needed to fix this bug.

Thank you Till Kamppeter, I can print using the modified queue.

Mitchell Surface, can you attach the PPD file of your old queue (/etc/cups/ppd/HL-5140-debug.ppd) and also the input PDF file (strengths.pdf)?

I ran into a similar poblem with my HL-5040 printer when I did an update on 1-24-2009 , the same process fixed it. diff of the ppd attached

This means that an updated PPD generated by Foomatic 4.0 fixes the problem.

David Lang, did you activate the -proposed repository? What is the output of

foomatic-rip --version

The newest foomatic-rip (4.0 final) has also a bug fix concerning a segmentation fault. So it is possible that the segmentation fault observed by the original poster can have disappeared.

So please test either with Jaunty or after following the instructions to update from -proposed in bug 299918, using the old PPD file (Mitchell, test with the "HL-5140-debug" queue). Do

cupsctl LogLevel=debug
cancel -a

Then print a job and wait until it comes out or turns to "stopped" state. If the result is not satisfying, do

sudo cp /var/log/cups/error_log ~
sudo chmod 777 ~/error_log

and attach the error_log file from your home directory to this bug report. Do not compress the file.

Your problem is perhaps the same as described in bug 321164. Can you please install the update proposed there (available for both Intrepid and Jaunty) and tell whether it helps. Thanks.

Please test foomatic-filters_4.0.0-0ubuntu7 in Jaunty, it fixes another cause of a segfault.

I have this foomatic rip error now with a clean install of jaunty and a hp 930c.

I too have this problem "foomatic-rip failed" on an HP 1020 Laserjet
System is fully up to date.

attached error log when trying to print as root

There is a line

D [26/Apr/2009:12:22:19 +1000] [Job 60] GPL Ghostscript 8.64: Can't start ijs server "hpijs"

in your error_log. Can you run

hpijs -h

and

ls -l /usr/bin/hpijs

and post the output here?

Can you also post the output of

dpkg -l | grep hpijs

mike@jaunty32-1:~$ hpijs -h

Hewlett-Packard Co. Inkjet Server 3.9.2
Copyright (c) 2001-2004, Hewlett-Packard Co.

mike@jaunty32-1:~$ ls -l /usr/bin/hpijs
-rwxr-xr-x 1 root root 524496 2009-04-14 19:38 /usr/bin/hpijs

mike@jaunty32-1:~$ dpkg -l | grep hpijs
ii foomatic-db-hpijs 20090218-0ubuntu3 OpenPrinting printer support - database for
ii hpijs 3.9.2-3ubuntu4 HP Linux Printing and Imaging - gs IJS drive

mike@jaunty32-1:~$

Can you run

hp-plugin -i

and follow the instructions to download HP's plugin? Does the printer work after installing the plugin?

After hp-plugin -i it now prints. Amazing! Why does HPLIP not install this? I tried everything with it.

Thanks Till 'till next time (sorry about that)
Mike

Mike Durham, the plugin contains proprietary files which cannot be shipped as part of the Ubuntu Linux distribution. For your printer it contains the firmware file for the printer which needs to be uploaded into it each time the printer is turned on.

Now the file is in place and so it gets automatically loaded into the printer whenever needed and after that the driver can communicate with the printer.

Usually, hp-plugin is started automatically when an appropriate printer (like yours) is set up. Probably you ran into bug 363522.

All problems described here are solved.

Thanks again Till, I'll remember for next time.
Cheers, Mike

I can't print PDFs with evince, only with acroread. I get the same "foomatic-rip failed" popup error message, followed by prompts to diagnose and troubleshoot. As suggested above, I tried installing hp-plugin, to no avail.

I'm on Ubuntu 9.04. I have an HP Officejet 5610 All-in-One. foomatic-filters 4.0.0-0ubuntu9 installed. CUPS 1.3.9-17ubuntu3 installed.

Troubleshooting output attached.

Same here. After updating to foomatic-filters 4.0.0-0ubuntu9, printing a PDF from okular fails, because foomatic-rip segfaults. So this bug is still there somehow. Ubuntu 9.04, HP LaserJet 1300, CUPS 1.3.9-17ubuntu3.1. hpijs: same as in comment 15. Running hp-plugin and downloading the stuff didn't help.
I recompiled foomatic-filters with debug symbols, but for some reason this crash doesn't generate a core dump, and happens too fast for me to attach gdb to the running process (even with a watchdog-kind of script). The only way would be to start foomatic-rip in gdb in the first place, but how and where is it invoked?

ricardisimo, David Faure, only the HP LaserJet 1000, 1005, 1018, 1020, P100x need firmware files, all HP inkjets and the LaserJet 1300 do not need a firmware file to work. Please create an error_log with your problem logged in debug mode as described on

https://wiki.ubuntu.com/DebuggingPrintingProblems

and attach it to this bug report.

ricardisimo, David Faure, tell also which files you printed, with which app you printed them, and with which settings. Attach also the files.

I am trying to print http://ev.kde.org/resources/FLA-generic.pdf from okular [embedded into konqueror, but that shouldn't matter], and from another computer than the one connected to the printer. Same setup worked before without problems.

You can find the cups error_log at this address:
http://www.davidfaure.fr/2009/error_log

See the line that starts with E ;)

I don't know what has changed in the past month, but I no longer have any problems printing PDFs with evince, and cannot recreate the error. It just hasn't come up again in that time, so I never really worked on it. Sorry.

David Faure, can you attach your PPD file (/etc/cups/ppd/HPLaser.ppd)?

In general, please always attach files to the bug instead of hosting them on your own server. We have enough space, and bug reports will also get understood later, also after you have taken down your file again. Thanks.

I am wondering about this:

I [17/Jun/2009:17:37:00 +0200] [Job 2068] File of type application/vnd.cups-postscript queued by "dfaure".

This means that CUPS has auto-detected the format of the job as application/vnd.cups-postscript, but (at least my) /etc/cups/mime.types has no auto-detection rule for application/vnd.cups-postscript. So how could CUPS auto-detect this type.

I anddition, I was assuming that all KDE apps emit PDF when they print.

The line application/vnd.cups-postscript is empty in /etc/cups/mime.types indeed.
I wonder, too, where this mimetype comes from... HPLaser.ppd mentions it, at least.
As to why cups is getting PS and not PDF: seems to be okular's doing. It says:

okular(32683)/okular (app) Okular::FilePrinter::doPrintFiles: Executing "lpr" with arguments ("-P", "HPLaserCleo", "-#1", "-J", "FLA-generic.pdf", "-o", "media=A4", "-o", "portrait", "-o", "sides=one-sided", "-o", "outputorder=normal", "-o", "Collate=False", "-r", "/tmp/dfaure-kde4/kde-dfaure/okularr32683.ps")

So apparently it's generating a temporary PS file and then calling lpr with that.

I'm attaching HPLaser.ppd from the cups server machine (not the client machine running okular, right?).

Okular seems not to use standard KDE (Qt) methods for printing. It looks very much like the method of KDE 3.x for me.

Concerning the foomatic-rip crash, I have uploaded a new foomatic-filters package to Karmic. Please try it, as it fixes also a segfault in foomatic-rip.

Also please make sure to have the newest printing stuff. Do a full update in case of Karmic and activate jaunty-proposed and do a full update in case of Jaunty.

Works in Karmic indeed. Thanks!