libImageProcessor binary blob

Hi,

Yes currently libImageProcessor.so 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.

Regards,
Srinivas Teja.

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
 * https://bugs.gentoo.org/ to make sure the issue is fixed.
 * For more information, see:
 *
 * https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart
 *
 * 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/libImageProcessor-x86_64.so

 * QA Notice: The following shared libraries lack a SONAME
 * /usr/lib64/libImageProcessor-x86_64.so

Already mentioned by Hans-Peter

 * QA Notice: The following shared libraries lack NEEDED entries
 * /usr/lib64/libImageProcessor-x86_64.so

 * QA Notice: Pre-stripped files found:
 * /usr/lib64/libImageProcessor-x86_64.so

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 Makefile.am. 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?

Regards,
Daniel

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

> Yes currently libImageProcessor.so 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 https://launchpad.net/hplip:

    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.

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 https://buildd.debian.org/status/package.php?p=hplip&suite=experimental 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).

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

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!

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

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

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

The same problem exists on RHEL7 which is preventing us from easily automating the installation and updates with the preferred package manager: 'yum'. Using the 'rpm' command with the --force --nodeps option works, but since it's outside of the yum package management system, we lose all of the benefits of yum's history and dependency tracking. I support any of the recommended approaches above to make the rpm usable with yum.