net-print/hplip will not print until file /usr/libexec/cups/backend/hp is chmod 700. The file is by Gentoo installed as chmod 755. I have absolutely no clue WHY OH WHY it will not work until it is chmod 700. It's not like it lacks lots of executable permission, there might be code within it which instructs it to do nothing if everyone has access. I don't know. But I do know that I pulled my hair for many hours until I discovered that the solution was available deep within the forums.gentoo.org all along. There are plenty of hplip reports at bugs.gentoo.org, none indicate this. Solution for users who find this: chmod 700 /usr/libexec/cups/backend/hp more info: http://forums.gentoo.org/viewtopic-t-701122-highlight-hplip.html Reproducible: Always Steps to Reproduce: 1. emerge hplip 2. try to print (regardless of what/where, cups test pages, from kde, gnome, etc) 3. no printing for you Actual Results: no printer activity, nothing happens Expected Results: printer activity I dare call this major bug as it breaks printing for most of those who owns printer hardware from the Hewlett-Packard Development Company.
Is the user from which you are trying to print in the lp group ? Denis.
The user trying to print was a member of the lp group. Further, the user could use the local cups service to print on non-local printers (cups network printers). This bug relates to the hplip cups backend, not user access to cups. I should add that there were jobs in the printer queue when I found the chmod 700 solution in the forum. When I did chmod 700 /usr/libexec/cups/backend/hp <enter> the printer immediately started doing it's thing and spewed out the whole print queue for the locally attached HP printer.
Thanks for your answer. I can't reproduce this here. I have always been able to print correctly with this version of hplip. I am not saying your problem does not exist though, but that it is specific to your system. Do you have an idea of when this stopped working as expected ? It's a shame I had to do a lot of cleanup in the ebuild versions due to the recent security issue. I will not use your workaround blindly in the ebuild for a number of reasons. The main one being that this is the stable version of hplip and using such an unexplained hack to fix a mysterious issue that 2 users had could be dangerous for the many others (and there are quite a few in the case of hplip). What I suggest instead is you file a bug upstream and give them all necessary details. They are much better suited than me to investigate this. There's very little we do to the code and it's all available in src_unpack in the ebuild. Also, none of this could possibly be the reason of your issue, in my opinion. Feel free to contact me or tell them to contact me in case you or they need more information, but the ebuild should be self explanatory. In the meantime you may want to try hplip-2.8.7, although I don't see anything in the changelog that would help, and you could send me the usual emerge --info for me to have a look just in case there's something suspicious. Denis.
(In reply to comment #2) > The user trying to print was a member of the lp group. > > Further, the user could use the local cups service to print on non-local > printers (cups network printers). This bug relates to the hplip cups backend, > not user access to cups. > > I should add that there were jobs in the printer queue when I found the chmod > 700 solution in the forum. When I did chmod 700 /usr/libexec/cups/backend/hp > <enter> the printer immediately started doing it's thing and spewed out the > whole print queue for the locally attached HP printer. > Thanks you very much for your workaround, same problem here and solved finally. Thanks a lot.
I can confirm that I had the same problem, I was unable to print from a user account or root and hp-toolbox would give "device communication error 5012". This workaround fixed this for me. Thanks guys.
/usr/libexec/cups/backend/hp has normal rights for me and i am able to print. Can you reproduce this by chmodding it to 755 again?
(In reply to comment #6) > /usr/libexec/cups/backend/hp has normal rights for me and i am able to print. > > Can you reproduce this by chmodding it to 755 again? > Yes, it is reproducible. If I chmod to 755 and restart cups I get the device communication error. Chmod back to 700 and restart cups and the printer works fine. I don't know if it's related, but hp-check reports that it can't find scanext. Scanner works fine, even with the device communication error though.
I can reproduce that with a HP LaserJet m1005 MFP. 700 works, 755 not.
Does this still apply to the newest version hplip-3.9.12?
(In reply to comment #9) > Does this still apply to the newest version hplip-3.9.12? Is this still a problem with recent versions of hplip. If nobody reports here I will close this bug in the next weeks. If the problem persists I will open an upstream bug about it, but before I need to know if the problem is still there.
(In reply to comment #10) > (In reply to comment #9) > > Does this still apply to the newest version hplip-3.9.12? > > Is this still a problem with recent versions of hplip. For me it is still an issue with 3.10.2-r3, but not with all printers. My father has two HP printers (MFC 1500 DeskJet something, and a LaserJet m1005), and with the former, printing did work fine while the latter needs 700 permissions.
This bug is now tracked upstream under https://bugs.launchpad.net/bugs/556838. For those who are interested in a fix please continue there and report the requested information (Printer model and output of "lsusb -v").
Great, I've added the infos.
