libImageProcessor binary blob

Bug #1785230 reported by Hans-Peter Jansen on 2018-08-03
This bug affects 4 people
Affects Status Importance Assigned to Milestone
hplip (Debian)

Bug Description

In an attempt to package the current hplip version for openSUSE, a couple of issue arose around libImageProcessor:
 * since libImageProcessor-{x86_64,x86_32}.so doesn't conform to shared libs naming policy, rpm fails to handle this dependency correctly
 * $DESTDIR isn't respected

As far as I understand the build, is a new blob, do you plan to release it to open source?

For reference:

srinivas (srinivas5) wrote :


Yes currently is not open source. Hope you are not seeing any functionality issue when you print.
You need to install with the command "rpm -ivh xxx.rpm --nodeps" to not see any dependency issues.

Srinivas Teja.

Changed in hplip:
status: New → In Progress

Hi Srinivas!

I also tried to package this version on Gentoo Linux. There seem to be more issues.

 * QA Notice: The following files contain writable and executable sections
 * Files with such sections will not work properly (or at all!) on some
 * architectures/operating systems. A bug should be filed at
 * to make sure the issue is fixed.
 * For more information, see:
 * Please include the following list of files in your report:
 * Note: Bugs should be filed for the respective maintainers
 * of the package in question and not hardened@g.o.
 * --- --- RWX usr/lib64/

 * QA Notice: The following shared libraries lack a SONAME
 * /usr/lib64/

Already mentioned by Hans-Peter

 * QA Notice: The following shared libraries lack NEEDED entries
 * /usr/lib64/

 * QA Notice: Pre-stripped files found:
 * /usr/lib64/

Additionally $DESTDIR is not honored, but Hans-Peter already mentioned this. I will try to add a patch to fix this issue.
This seems also be the case for the linking of the scan stuff the install-data-hook section of However this does not affect Gentoo as the directories $(libdir)/x86_64-linux-gnu/sane and $(libdir)/i386-linux-gnu do not exist thus these links are not created.

Any chance that this issues get fixed?

You also mentioned that libImageProcessor is currently not open source. This indicates that it might get open source at some point. Is there any ETA when this will happen?


Attempt to honor $DESTDIR when creating the symbolic link for libImageProcessor-{x86_64,x86_32}.so.

Hans-Peter Jansen (frispete) wrote :

> Yes currently is not open source. Hope you are not seeing any functionality issue when you print.

Sorry, but I reverted to hplip-3.18.6 and submitted that.

If you plan to keep the state of this blob disclosed, please correct the wording from

    Note: HPLIP is free, open source software distributed under the MIT, BSD, and GPL licenses.

This is no longer true, and forces us to nail the version to 3.18.6 for the time being.

> You need to install with the command "rpm -ivh xxx.rpm --nodeps" to not see any dependency issues.

Since we're using zyp as a rpm frontend, providing --nodeps isn't an option. Sure, I can do this manually, but this definitely is a no go distribution-wise.

Srinivas, please don't get me wrong, this isn't meant to offend you. You surely have your reasons for this move, but it changes the rules and forces most distributions to handle this package in a non free way for legal reasons. Since "non-free" complicates the package management significantly, every responsible packager have to weight this cost against keeping the last free version 3.18.6.

Didier Raboud (odyx) wrote :

We have the same issue in Debian, which forces us to use an hplip amputed away from libImageProcessor. It's a serious move away from OpenSource, and specifically hinders our ability to ship hplip outside of only i386 and amd64 architectures. See Up until 3.18.6, hplip was installable in non-x86_* architectures such as arm, mips or s390.

Please seriously reconsider this, or split hplip in two, with a working fully-opensource hplip and an "hplip-nonfree" to enable features that HP doesn't want to opensource (and/or which are limited to specific architectures).

Martin Wilck (mwilck) wrote :

For now, the best workaround for distros appears to be reverting the libImageProcessor related changes to HPCupsFilter::processRasterData(), as Debian seems to have done already. It's likely "just" an optimization that enhances the rendering of rastered pages. (Some public information about the purpose of imageProcessorProcessLine() would be desirable).

@Srinivas, there's a mechanism already in place to download the binary plugins for various printer models. Can you consider a similar mechanism for libImageProcessor? Thus, rather then shipping it with hplip and linking with it hard, you could offer to download it with the plugin helper in hp-setup. The CUPS filter code would then try to and dlopen() it, and just skip calling the related functions if the library isn't found, falling back to in 3.18.6 behavior.

In any case, it would be highly desirable to have libImageProcessor available not only for x86 and x86_64, but (at least) also for arm32 and arm64 (for which you provide the plugins).

llalonde (luc-lalonde) wrote :

I would also like to add my 2 cents...

Please open libImageProcessor or take it out of HPLIP and package as a separate binary package.

I am also running a ARM64 Cups server at home... So please also provide binary for this platform if you cannot distribute the source.

Thank You!

Joe Van Dyk (joevandyk) wrote :

I'm running into this problem as well, I cannot use the latest HP printer on a ARM device.

Peter Ceiley (pceiley) wrote :

It would be great to see this removed from the tarball as this is still a blocker for upgrading in some distributions.

Francois Ochsenbein (f0x1) wrote :

Also running into the same problem, I cannot use the latest (>3.18.12) HPLIP on an ARM device (Raspberry)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers