Talk:HPLIP

From Gentoo Wiki
Jump to:navigation Jump to:search
Note
This is a Talk page - please see the documentation about using talk pages. Add newer comments below older ones, sign comments using four tildes (~~~~), and indent successive comments with colons (:). Add new sections at the bottom of the page, under a heading (== ==). Please remember to mark sections as "open for discussion" using {{talk|open}}, so they will show up in the list of open discussions.

SANE_BACKENDS USE flag

On Paludis I can just set

SANE_BACKENDS: -*

in order for none of the normal backends to be built. Is there no such syntax under Portage? --Hypnos (talk) 04:46, 15 December 2015 (UTC)

I stopped using the HP (HPLIP) scanner and bought a Canon 9000F MK2 scanner with Linux native scanning, and never looked back! Granted, I still use the HP MFD for printing and copying. --Roger (talk) 18:38, 15 December 2015 (UTC)
File: /etc/make.conf or /etc/portage/make.conf
#SANE_BACKENDS="-hp"
SANE_BACKENDS="pixma"

Incompatibility with the LaserJet 1320 (and possibly others)

I just put Gentoo back on one of my boxes today after spending a while with Kubuntu, and ran into major difficulty getting my LaserJet 1320 working with it again. hp-setup's test page comes through, but nothing else works after that...keep running into printer communication errors (code 5012, IIRC). There's lots of discussion in the Gentoo forums and elsewhere, but no fixes. I tried downloading a PPD from HP's website, but they don't seem to have a clue what those are anymore.

I eventually stumbled across a clue that suggested using Foomatic to generate a PPD, and then configure CUPS with that. Kernel USB printing support needs to be enabled, but once you have that in place, printing once again works great. Slightly more complete documentation is on my blog:

https://alfter.us/wp/2015/03/23/gentoo-linux-hplip-and-the-hp-laserjet-1320-dont-mix/

--Salfter (talk) 03:56, 24 March 2015 (UTC)

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?

user $sudo gpasswd -a $USER lpadmin

or for noobs that think they're super elite

root #gpasswd -a yourusertoadminlphere lpadmin

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

I think it has always been simply assumed qt4 (or gtk) use flags have always been required for GUI interfaces. However, most of us command line junkies know this and instinctively avoid enabling the QT/GTK USE flags when needed. So I don't know if this QT/GTK USE flag is a problem -- I could be wrong though? (For example, us command line junkies will commonly use app-portage/euses tools; "# euses qt4" responds with "net-print/hplip:qt4 - Enable graphical interface using Qt 4") If I'm not mistaken; I think HP's perspective of support for HPLIP, HP support prefers or requires users to require building HPLIP with the QT4 (or QT/GTK) GUI for end user support to be even considered. (Mine and likely other minimalists' perception is, HPLIP GUI tools shouldn't be required for merrily operating a printer under Linux.) Since I've migrated to a box with a i7-3770K CPU @ 3.50GHz x4 with x4 Threads, 32GB RAM, NVIDIA GTX 670; I don't have much problem anymore restricting all of my builds from using QT4, albeit I never use the QT front-ends! On my older Intel Pentium 3, the older boxes still run slow when using most Python or when building something using QT. Probably similar results with any mobile or minimal platforms. --Roger (talk) 23:08, 21 May 2014 (UTC)
Nowadays, I only print one or two documents every two months or so. I also now remember when the printer is off and CUPS sends a job and fails, CUPS will automatically suspend the printer for that specific printer requiring the user to resume printing for that specific printer before being able to print again. (ie. CUPS Front End: Maintenance > Resume) --Roger (talk) 23:08, 21 May 2014 (UTC)
As far as Sane scanner plug-in, I've had no problems for awhile here. But then again, I haven't manually upgraded the plug-in for awhile. Once the binary library becomes incompatible with the newer HPLIP versions, breakage can easily occur at any time! So I (or we) have to continually be weary of this occurring at anytime and need to be on our toes. :-/ --Roger (talk) 23:08, 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?)
-- {{RootCmd| hp-upgrade -i 192.168.1.27}}

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!)

Note
/usr/lib64/sane/libsane-hpaio.so* is not part of the binary plugin, it comes with the hplip ebuild installed by portage. You can easily find this out with:
user $equery b /usr/lib64/sane/libsane-hpaio.so*
Everything which is installed by the binary plugin resides under /usr/share/hplip/data/firmware/ /usr/share/hplip/data/plugins/ and /usr/share/hplip/prnt/plugins/. This is mentioned in the binary plugin section.
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!)

Note
What is wrong with recreating the printer and fax queues after an update and why should this defeat the purpose of upgrades. The upgrade installs a new version of hplip. Now there may be incompatibilities with existing ppd files installed at configuration time. So the best solution is to delete the queues and recreate them again. I have not much experience with the binary plugin, however every time there is a new version of hplip there is also a new version of the binary plugin and it has to be upgraded as well. How this happens is up to the user. After installing the hplip and the plugin the cups deamon should be restarted. Some problems may occur as new versions of hplip try to be smart and create the printer queues automatic as well as installing the plugin. Currently I try to figure out how to remove all this automagic stuff like auto-upgrading of the hplip software and the plugin as well as auto-configuring of queues.
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.

Note
The hplip ebuild does not care about the binary plugin. The binary plugin is currently not supported by Gentoo as there is no dedicated maintainer to take care of it. This again is all mentioned in the binary plugin section.
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.

FYI: I've finally purchased a Canon Canoscan 9000F MK2 dedicated flat bed scanner, aside from using my HP M1522NF multifunction device. The Canon flat bed has a completed open source Sane driver, with almost functional open sourced infrared fixing via "antidust.c". Although my HP 1522NF scanner using the binary HPLIP driver's hp-plugin utility for manually upgrading the binary scanner driver appears to be working lately without also completely uninstalling the printer quenes, the scanner binary driver update still has to be performed manually after each HPLIP package update, else the HP M1522NF scanner becomes inoperable due to scanner driver and hplip package version conflicts. I eventually foresee once I encounter further problems with the HPLIP HP 1522NF scanner driver, I'll likely revert to just uninstalling the HPLIP package and defaulting to just using the open sourced printer drivers. (Bought a Canoscan 9000F a couple of years ago for the parents too, and they're very pleased. --Roger (talk) 20:56, 11 June 2015 (UTC))

Disabling Infinality?

++ {{Note| Sometimes using Infinality can create some unknow issues, if nothing works try 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)