User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; nn-NO; rv:1.9.1b4) Gecko/20090427 Fedora/3.5-0.20.beta4.fc11 Firefox/3.5b4
I have tried to print a receipe but I can't get it to work. In the past everything have worked fine (ie. 6 months ago) but today it isn't. I have tried to install the cups from updates-testing to see if that had any fixes but no.
In the printer applet it says "Status: Stopped" after a little while of "Pending".
I have tried printing from OO.o, Firefox and Okular.
Steps to Reproduce:
1. Plug in my HP PSC 1410 and turn it on. Let it get some time to get detected etc.
2. Print a page
Nothing. The printer doesnt show any error blinks or anything
A page with my receipe on
Created attachment 350149 [details]
cups error messages
You need to install the hpijs package.
The system-config-printer-applet is meant to spot this situation and prompt you to install the package, but that doesn't seem to be working.
Ok. I will not install hpijs manually (I wrote the recipe down by hand), that way I can retest it when an update has hit updates-testing :)
Thank you. Of course it can always be tested by disconnecting the printer, removing the hpijs package, and deleting the queue, then reconnecting the printer.
That way you can still print in the interim before I get this problem fixed.
I saw on Fedora Community that there is a version of system-config-printer in testing which has a fix for this bug. I ran:
[root@Huginn ~]# yum --enablerepo=updates-testing update system-config-printer
Loaded plugins: presto, refresh-packagekit
Setting up Update Process
Package(s) system-config-printer available, but not installed.
I also see that I haven't mentioned that I am running KDE, so I am beginning to suspect that this bug is reported to the wrong package as I, when searching for this package, that there is a system-config-printer-kde package.
Yes, an update intended to address this bug is in the pipeline:
but the package has not yet reached the updates-testing repository.
However as you have noted, you don't have the system-config-printer package installed. Looks like system-config-printer-kde (from the kdeadmin package) needs to be fixed as well.
I've already referenced this bug number in the system-config-printer Fedora update so it would be ideal if you could open a separate bug report against kdeadmin. Thanks!
*** Bug 509846 has been marked as a duplicate of this bug. ***
*** Bug 509847 has been marked as a duplicate of this bug. ***
system-config-printer-1.1.8-5.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
system-config-printer-1.1.8-6.fc11 has been submitted as an update for Fedora 11.
system-config-printer-1.1.8-6.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
I had an interesting experience trying to add a JetDirect-style remote printer to my F11 box today that's tangentially related to this bug.
When I run system-config-printer **from a root shell** I get this message at the very end of the add printer wizard:
> Unauthorized request (addPrinter)
> You are not authorized to carry out the requested action.
At that point /var/log/cups/error_log has:
> E [01/Sep/2009:14:49:04 -0700] Returning HTTP Forbidden for CUPS-Get-Devices (no URI) from localhost
It looks like CUPS needs the actual root password to proceed; merely running the system-config-printer client *as* root doesn't work. This security architecture could be better, but that's not what I'm here to talk about.
Next, I went into the CUPS web app at http://localhost:631 and went through the web-based wizard. After being prompted for root credentials I was successful in adding the printer, only to be thwarted at print time by the lack of hpijs, which I only discovered by reading logs. So if adding printers via the CUPS web application is a supported use case, this fix really should be applied "closer to the metal" than system-config-printer.
Running system-config-printer as my own user account, everything works fine after being prompted for my root password.
And, perhaps somewhat ironically, when hpijs is *not* installed, the list of available drivers offered by the wizard for my printer model includes "HP OfficeJet Pro L7700 Foomatic/hpijs [en]" **but NOT** "HP Officejet Pro l7700, hpcups 3.9.8 [en]". :)
(In reply to comment #12)
> It looks like CUPS needs the actual root password to proceed; merely running
> the system-config-printer client *as* root doesn't work. This security
> architecture could be better, but that's not what I'm here to talk about.
cupsd requires HTTP-style authentication when it cannot verify the client user. For local connections over a UNIX domain socket (the default when running on the local machine) it can verify the client user so does not require further authentication; failing that, if the client has access to a root-readable certificate file, they can provide the content of that file as proof of credentials. These methods are how e.g. 'lpadmin' can run as root without requiring a password.
If that isn't working for you it sounds like some sort of configuration or runtime issue on your machine.
But: don't run system-config-printer as root. GTK+ is not designed to be run that way and it may cause security problems.
> Next, I went into the CUPS web app at http://localhost:631 and went through the
> web-based wizard. After being prompted for root credentials I was successful
> in adding the printer, only to be thwarted at print time by the lack of hpijs,
> which I only discovered by reading logs. So if adding printers via the CUPS
> web application is a supported use case, this fix really should be applied
> "closer to the metal" than system-config-printer.
If http://localhost:631/ was how end users were expected to administer print queues, why would I have bothered writing system-config-printer?
> And, perhaps somewhat ironically, when hpijs is *not* installed, the list of
> available drivers offered by the wizard for my printer model includes "HP
> OfficeJet Pro L7700 Foomatic/hpijs [en]" **but NOT** "HP Officejet Pro l7700,
> hpcups 3.9.8 [en]". :)
This is a result of how foomatic is architected. The hpijs information in foomatic has been removed in newer versions.