Bug 496521

New discovery:

It is the frankenstein monster causing the problem :-). When I explicitly
pick the Brother HL-2060 Foomatic/hpijs driver which is the one fedora
10 picked automatically, then the printer seems to work fine.

Gutenprint's foomatic drivers are not something new in Fedora 11.

Please run the printing troubleshooter and attach the troubleshoot.txt file you get. (System->Administration->Printing, then Help->Troubleshoot)

Created attachment 340435 [details]
troubleshoot.txt from help wizard

I see system-config-printer is yet another app that doesn't work if I'm
running it as root. It does an exit(1) when I try the troubleshoot
and reach the "enable debug" page, but running it as ordinary user
did produce the attached file.

By the way: Is debugging now enabled all the time in cups after running
the wizard, or does it turn it off after I get the file saved?

The main problem here seems to be that the wrong driver is getting selected.  The other two problems you've mentioned (the time taken to search drivers and the troubleshooter not running as root) are not something I was aware of and will need separate bug reports.

The HL-2040 driver issue has previously been fixed (bug #292012) but seems to have broken again.

Please try the 'hl1250' driver.

(Oh, and debug logging is supposed to be turned off when you exit the troubleshooter.  You can check with 'cupsctl'.)

Created attachment 340851 [details]
troubleshoot.txt with new driver

OK, I explicitly selected the driver:

Brother HL-1250 Foomatic/gutenprint-ijs-simplified.5.2

and I get the same behavior - it acts like it prints, but nothing comes
out.

The driver system-config-printer on fedora 10 suggested was (I think I
mentioned above) Brother HL-2060 Foomatic/hpijs (not a gutenprint
driver). It works fine if I explicitly select it, so there is something
wrong with system-config-printer's suggestions or all the gutenprint
drivers simply don't work or something.

By the way, the really slow printer selection didn't happen the 2nd time
I tried it, so it either unpacks some database the first time, or some
cron job was bogging down the system in the background the first time
I did it (updatedb or makewhatis or prelink all tend to run in a relatively
newly installed system :-).

Out of curiosity, I tried Brother HL-1250 Foomatic/hpijs (the guten
free version), and it also works fine. I get a perfectly printed test
page.

Sorry, I wasn't clear enough, please try this driver:

Brother HL-2060 Foomatic/hl1250

Created attachment 341004 [details]
here's the failure with foomatic/hl1250

This driver give a foomatic-rip failed message in the status. Here's the
latest debug output.

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Please edit /etc/foomatic/filter.conf and add this line to the end:

debug: 1

Then try printing a test page again, as before.  This time you should end up with /tmp/foomatic-rip.ps and /tmp/foomatic-rip.log.  Please attach those files.  Afterwards you can remove the 'debug: 1' line from /etc/foomatic/filter.conf again.

Created attachment 348361 [details]
foomatic-rip.log

I deleted and re-installed the printer just to make sure I was starting
from the same broken state. It did indeed pick the
Brother HL-2060 Foomatic/gutenprint-ijs-simplified.5.2 driver, and it still
doesn't print anything just as initially reported.

Here's the foomatic-rip.log file, with the postscript coming up next.

Created attachment 348362 [details]
foomatic-rip.ps

This the the postscript from the same test page attempt.

(In reply to comment #11)
> I deleted and re-installed the printer just to make sure I was starting
> from the same broken state. It did indeed pick the
> Brother HL-2060 Foomatic/gutenprint-ijs-simplified.5.2 driver, and it still
> doesn't print anything just as initially reported.

Oh, why did you do this?  Unfortunately you've now given me debugging information that's no good. :-(  What we are trying to do here is get the correct driver (hl1250) working.  Once that is fixed, the fact that the incorrect driver (gutenprint) gets auto-selected can be fixed.

Please change the driver back, as in comment #7, and then follow the steps in comment #10 again.  Thanks.

Created attachment 348406 [details]
foomatic-rip.log

OK, here are the files again with the hl1250 driver. Still gets the
foomatic rip failure with that driver.

Created attachment 348407 [details]
foomatic-rip.ps

Created attachment 349208 [details]
raw-job

Please download this file and name it 'raw-job', then try to print it while the troubleshooter is asking you to print a test job:

lp -dHL-2040 -oraw raw-job

OK, this is increasingly frustrating - I can't get the troubleshooter past
the enable debug button. I ran it as normal user because I had problems
previously running it as root, but I just get a busy cursor after it asks
for root credentials for as long as I care to wait :-).

I gave up on troubleshooter and enabled the "Save debugging information
for troubleshooting" option, which seemed to work, then I did the lp
command above, and I got a printer test page on the printer, so some
part of this worked OK, but now I have absolutely no idea where
the save debug info checkbox saves the info :-).

One other piece of possibly relevant info: I just noticed in my logs from
previous attempts to use the hl1250 driver that there are messages
about the executable foomatic-rip getting a segfault, so apparently
the foomatic-rip error is because the rip program itself blows up.

I went back to system-config-printer and ran as root to see if that
would work, and I got this when I hit the enable debug button:

 Multiple segmentation faults occurred; can't display error dialog

Anyway, it looks like at least some debug info from the raw print
is in the cups error log, so I'll attach that :-).

Created attachment 349322 [details]
cups error_log from lp -oraw print

The end of this log should be the info gathered while I had debug
turned on during the raw print job.

That raw-job file was the result of me running that job (comment #15) to completion with the hl1250 driver, so that driver clearly works.

Which versions of cups and system-config-printer do you have currently?

rpm -q cups system-config-printer

zooty> rpm -q cups system-config-printer
cups-1.4-0.b2.18.fc11.x86_64
system-config-printer-1.1.7-4.fc11.x86_64

As I type this a slew of updates are still downloading on my
"fetch-updates" cron job, so if there is newer ones, I'll have
them soon.

OK, you'll need the test updates for cups and system-config-printer:

yum --enablerepo=updates-testing update 'system-config-printer*' 'cups*'

That should fix troubleshoot reporting, and it may even fix the printing problem.  Let me know how you get on with those.

OK, I got the updates-testing version installed, and I figured I'd begin back
at the beginning and try it all again. I deleted the printed, then ran
s-c-p as normal user to install it from scratch, and I see this output
in the terminal where I ran it:

 Using foomatic:Brother-HL-2060-gutenprint-ijs-simplified.5.2.ppd (status: 0)
Caught non-fatal exception.  Traceback:
File "/usr/share/system-config-printer/system-config-printer.py", line 6658, in on_btnNPApply_clicked
    option = self.mainapp.server_side_options['media']
AttributeError: GUI instance has no attribute 'server_side_options'
Continuing anyway..
Traceback (most recent call last):
  File "/usr/share/system-config-printer/system-config-printer.py", line 6672, in on_btnNPApply_clicked
    self.mainapp.ppd != False:
AttributeError: GUI instance has no attribute 'ppd'

I don't know what the errors mean, but I notice it is still picking
the gutenprint driver by default, and it still acts the same - the printer
whirs a bit, but nothing actually comes out.

Step 2 was manually switching to the Brother HL-2060 Foomatic/hl1250 [en]
printer in the list. That still gives a foomatic-rip error and if I look
in /var/log/messages at the end, I find:

Jun 25 18:16:52 zooty kernel: foomatic-rip[4936]: segfault at 71 ip 00007f4b73afb214 sp 00007fffffb8cce0 error 4 in libc-2.10.1.so[7f4b73a7b000+164000]

So it looks like poor old foomatic-rip is still segfaulting when
trying to generate a test page.

I figured it was time to try troubleshoot, and this time it actually
managed to enable debug logging, no more busy cursor forever, so one
thing is fixed, anyway.

So now's my chance to print the raw job again while sitting at the
Test Page screen in troubleshoot. That allowed me to generate a troubleshoot.txt
file which I'll attach.

Maybe I should try this on my 32 but fedora 11 partition. It might be
interesting to see if the 32 bit foomatic-rip also segfaults.

Created attachment 349481 [details]
latest troubleshoot.txt from printing raw job

The raw job output did indeed print a correct test page by the way.

Nope, I get foomatic-rip failed on 32 bit as well with this in
/var/log/messages:

Jun 25 18:46:57 zooty kernel: foomatic-rip[2933]: segfault at 11 ip 0018a162 sp bf84483c error 4 in libc-2.10.1.so[110000+16b000]

For grins I installed the debuginfo I'd need to debug foomatic-rip
and tried to attach to cupds and debug all the kids till I got to
foomatic-rip, but when running under debugger, it doesn't segfault the
same way.

Then I tried to make it generate a core file by sticking this
stuff in the /etc/init.d/cups script:

	DAEMON_COREFILE_LIMIT="unlimited"
	export DAEMON_COREFILE_LIMIT
	ulimit -c unlimited

but none of that seemed to generate a core file anywhere that
I could find.

Anyone know how to induce a service to coredump? Is there some
global /proc file I have to echo "I tell you 3 times" to or something?

It's easier to run the filter outside CUPS, but first let's see what triggers it and what doesn't.  It *hadn't* been segfaulting previously, so I wonder:

(In reply to comment #10)
> Afterwards you can remove the 'debug: 1' line from
> /etc/foomatic/filter.conf again.  

Did you do this step?  Might be worth trying that first to see if it's still segfaulting when *not* in debug mode.

>It's easier to run the filter outside CUPS

Only if you know how :-).

I think maybe it has been segfaulting all along, and I just didn't
notice the /var/log/messages entries at first, at least it has always been
reporting a foomatic-rip failure the same way when using the hl1250 driver.

I just checked, and I apparently removed the debug line a while back, it
has not been there during these latest attempts.

(In reply to comment #28)
> >It's easier to run the filter outside CUPS
> 
> Only if you know how :-).

I was more hoping that I'd be able to do it myself (and I have now).  I wasn't expecting you to.

OK, I see the same thing, and it also explains the hl1250 driver failure because it is failing with EPIPE/SIGPIPE as well but has no reason to.

Created attachment 349532 [details]
Test case

Here is a test case.

foomatic-4.0.2-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/foomatic-4.0.2-1.fc11

I get: "The path /updates/foomatic-4.0.2-1.fc11 cannot be found"

I wonder if this is related to the problem I'm having with foomatic-rip segfaults when I print remotely...

Jul  7 10:05:31 anvil kernel: foomatic-rip[16247]: segfault at 0 ip 00374ac8 sp bfbbd98c error 4 in libc-2.10.1.so[2fc000+16b000]

This happens either printing directly to CUPS or via SAMBA.

The current URL for the update is this:

https://admin.fedoraproject.org/updates/foomatic-4.0.2-3.fc11

I'm hoping it will appear in updates-testing soon.

Confirming my segfault as reported in Comment #33 is fixed by the foomatic-4.0.2-3 update.

foomatic-4.0.2-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

foomatic-4.0.2-4.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/foomatic-4.0.2-4.fc11

Just a note to say I have just trodden this path with an HL-2030 (blank pages, or printer comes out of standby but prints nothing + foomatic segfaulting) and finally got things working with foomatic-4.0.2-3 and the Footmatic/HL-1250 driver.

In my case, I was printing round the network to a Netgear PSUS4 USB print server (LPR)/4-port switch and discovered that some of my faulty test prints were actually hanging the Netgear box, so if anyone else is following this, remember to reset/power cycle your print server if nothing's turning up.

Thanks to all who did the legwork on this.

foomatic-4.0.2-4.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.