Talk:HPLIP

Verbosity
can we tone down the verbosity of this page, and turn up the functionality? we should note qt4 use flag is required for the hplip GUI. lpadmin group?

or for noobs that think they're super elite

666threesixes666 (talk) 21:07, 21 May 2014 (UTC)

HPLIP Binary Upgrade
PROBLEM: The HPLIP ebuild itself does not upgrade the binary plugin(s) when the ebuild is upgraded. A symptom of this problem, you may get segfaults when starting XSane. (i.e. The HP LaserJet M1522nf requires a binary plugin for using the scanning feature.)

My Edit: -- SOLUTION: The following upgrade instructions should upgrade the Sane plugin file "/usr/lib64/sane/libsane-hpaio.so*". (hp-setup also upgrades the plugin?) --

Billie's Change: ++ SOLUTION: Following the upgrade instructions should take care of this as hp-setup tries to upgrade the plugin.

Within English Grammar, your statement lacks sense unless you are implying the upgrading of the binary (scanner/xsane) plugin is now upgraded while installing the package. (ie. Scripted now within the EBuild file?) If so, you should also say so for clarification. Albeit, I wasn't aware of this move, as I am already CC'ed on a few HPLIP bugs. Additionally, one of the reasons for specifying the "/usr/lib64/sane/libsane-hpaio.so*", is so that users know where the binary plugin file for xsane is installed for HPLIP and can manually check that their binary plugin for xsane has been updated, instead of depending explicitly upon the hplip utilities. (Funny though, I diff'ed the =net-print/hplip-3.13.9 and =net-print/hplip-3.14.1, and found those files to be different while still having the same 1.0 version, even noted within the library itself when searching using strings/hexedit!)


 * This is some good information not normally known by users of HPLIP, or those trying to troubleshoot HPLIP. I would suggest at least a brief mention as you & I have made above about the binary driver location, so when hp-set is suspected as to failing to upgrade the binary components, users can easily locate these specific binary files to ensure an upgrade took place.  In other words, when hp-setup is issued, the debug output is seemingly sparse at times.  Albeit, I don't know much about the binary scanner plugin either, and only tracked this upgrade problem down after a year or so.

I already recognize I may not even have had this bug properly corrected and documented initially, as downgrading to =net-print/hplip-3.13.9, and merrily running xsane afterwards still results in a device not found, without manually deleting and adding the fax/scanning device again. And as such, the binary plugin maynot be upgraded upon the next upgrade. If I'm not mistaken, HP developers' official stance on this (per their bug pages and support) is to manually delete all print/fax quenes and manually recreate the print/fax quenes after each upgrade or downgrade. Sort of defeats the purpose of so-called "upgrades", reverting back to MS Windows' early style of difficult package management! (Hence, the reason I stated "hp-upgrade -i 192.168.1.27" for upgrading the binary plugin... but now doesn't appear to be working... sigh!)


 * Having to recreate the printer/fax quenes requires also re-editing the PPD files to force my specific model to use "LanguageLevel 2", as it always defaults to Level 3, a known problem with my M1522nf printer to print a mess of random chars. (Not a fun issue when you need to get something out within an hour, and run a day late.  This bug, HP seems to have refused to fix, and many distros ie. Ubuntu hack the quenes to ignore the PPD specified value and use their own.  As such, users of these distros are usually completely unaware of this bug.)  Linux package upgrade process is known for it's streamlined package upgrade process, and recreating the quenes should be unnecessary.  However, you've made some good additional points and I will relax a little, as we know things aren't always perfect.  Main issue, I don't want this bug or known issue deleted, as I use this Gentoo Wiki when I have reoccurring problems with this M1522nf printer/scanner.  Others likely do so too.

I've just looked over the =net-print/hplip-3.14.1 ebuild file, and see nothing within it upgrading the binary plugin for the scanner/xsane file. And per HP developers' previous statements, the binary plugin require manual upgrading, requiring the deletion and recreation of the print/fax/scanner queues.


 * Yup. That's what I've always assumed from monitored bugs.  Good write-up here.

SOLUTION: Following the upgrade instructions should take care of this as hp-setup tries to upgrade the plugin. If there are still problems hplip comes with hp-plugin which can be used fro installing the plugin. As a last resort one can download the plugin from http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ and install it manually.

So others can have an easier time, might be just best to state for a SOLUTION, "After upgrading HPLIP to a newer version; users must run hp-setup, delete, and recreate the printer/fax quenes. Without recreating these quenes, the upgrading of the binary xsane scanner plugin maybe skipped and not upgraded." I think this is more to the point of what we've previously discussed and concluded. Think having users go to openprinting.org for a manual install of hplip might significantly discourage users, as distributions should have their packagers handle this process automatically. But for all I know, you may have heard of some users having success, with such things as a binary printer driver, as I only have the binary xsane scanner driver to worry about and I don't think I've ever attempted a manual install outside of Gentoo's EBuild. Now I do recall, using hp-setup to download the binary component, and manually executing the downloaded binary component and having it upgrade/install itself. But again, in my opinion, this manual install process usually creates unowned files within the root filesystem and not easily later uninstalled or lost.

Disabling Infinality?
++

I'm stumped. Can somebody elaborate on this? I wasn't aware there was a Infinality switch. A little research shows there is an Infinality package, and disabling it sometimes provides better results. ---Roger (talk) 01:54, 1 February 2014 (UTC)