Bug 1187232

Do I understand it correctly that the HP Color LaserJet 2600n
had worked with Leap 15.2 on aarch64?

As far as I see we have HPLIP 3.19.12 in Leap 15.2 and
HPLIP 3.20.11 in Leap 15.3 so this issue looks like
a regression in HPLIP from 3.19.12 to 3.20.11.

Christopher Chavez,
is it possible to downgrade to HPLIP 3.19.12 from Leap 15.2
and does that make it work again?

According to
https://developers.hp.com/hp-linux-imaging-and-printing/supported_devices/index
and
https://developers.hp.com/hp-linux-imaging-and-printing/binary_plugin.html
for the "HP Color LaserJet 2600n Printer"
a so called "Plugin" is "Required" for "Printing support"
which is proprietary software that must be downloaded from HP, cf.
https://en.opensuse.org/SDB:Printer_buying_guide#HP_printers

In general my personal recommendation is to not buy printers
that do not support a standard printer language, cf.
https://en.opensuse.org/SDB:Printer_buying_guide

There is basically nothing what I could do here
because I neither have ARM based hardware
nor a matching HP printer to reproduce or test anything
(I have only a PostScript printer).

From what I see in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972339
and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974828
it seems there is no simple and straightforward patch
that one could blindly apply without a real test
to get this issue fixed.

Christopher Chavez
if you like and if you think you are able do it
you may try to fix the issue on your own by using
the openSUSE Build Service where you could build
a HPLIP package with a patch so you could do a real test
whether or not your patched HPLIP package fixes the issue, cf.
https://en.opensuse.org/openSUSE:How_to_contribute_to_the_Printing_project


In general regarding HPLIP:

HPLIP is developed by HP.

We (i.e. openSUSE) distribute HP's HPLIP software "as is"
but we do not develop it, cf.
https://en.opensuse.org/SDB:How_to_set-up_a_HP_printer

Issues with HPLIP are usually upstream issues
that should be reported directly to HP via
https://developers.hp.com/hp-linux-imaging-and-printing/support

Accordingly issues with HPLIP are usually closed as "upstream",
cf. "Background Information" in
https://en.opensuse.org/SDB:How_to_Report_a_Printing_Issue

It is known that HPLIP upstream issues may sometimes
take a rather long time until they get fixed by HP.

I cannot reproduce on my openSUSE Leap 15.2 x86_64 system
what is described as "a simple way to reproduce" in
https://bugs.launchpad.net/hplip/+bug/1901209

I had hplip-3.19.12 installed and did
(long lines may show wrapped here):
-------------------------------------------------------------
# rpm -qa | grep ^hplip

hplip-sane-3.19.12-lp152.2.3.1.x86_64
hplip-3.19.12-lp152.2.3.1.x86_64
hplip-hpijs-3.19.12-lp152.2.3.1.x86_64

# mkdir /tmp/bug1187232

# cd /tmp/bug1187232

# cp /usr/share/cups/model/manufacturer-PPDs/hplip/hp-officejet_pro_1150c.ppd.gz .

# gunzip hp-officejet_pro_1150c.ppd.gz

# cp /usr/share/ghostscript/9.54.0/examples/text_graphic_image.pdf .

# export PPD=/tmp/bug1187232/hp-officejet_pro_1150c.ppd

# /usr/lib/cups/filter/pdftopdf 1 user title 1 options \
 <text_graphic_image.pdf >pdftopdf_stdout.pdf

DEBUG: pdftopdf: No FINAL_CONTENT_TYPE environment variable, could not determine whether to log pages or not, so turned off page logging.
DEBUG: pdftopdf: Last filter determined by the PPD: None; FINAL_CONTENT_TYPE: (null) => pdftopdf will not log pages in page_log.
DEBUG: PDF interactive form and annotation flattening done via QPDF

# /usr/lib/cups/filter/gstoraster 1 user title 1 options \
 <pdftopdf_stdout.pdf >gstoraster_stdout.CUPS_raster

DEBUG: OUTFORMAT="<none>", so output format will be CUPS/PWG Raster
DEBUG: Color Manager: Calibration Mode/Off
DEBUG: Color Manager: Invalid printer name.
DEBUG: Color Manager: Invalid input - Unable to find profile.
DEBUG: Color Manager: ICC Profile: None
DEBUG: Ghostscript using Any-Part-of-Pixel method to fill paths.
DEBUG: Ghostscript command line: gs -dQUIET -dSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups -sMediaType=Plain -sOutputType=0 -r300x300 -dMediaPosition=7 -dDEVICEWIDTHPOINTS=612 -dDEVICEHEIGHTPOINTS=792 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=1 -dcupsInteger0=2 -scupsString0=PlainNormalColor -scupsPageSizeName=Letter -I/usr/share/cups/fonts -c '<</.HWMargins[18.000000 36.000000 18.000000 9.000000] /Margins[0 0]>>setpagedevice' -f -_
DEBUG: envp[0]="LS_COLORS=no=00:fi=00:di=01;34:ln=00;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=41;33;01:ex=00;32:*.cmd=00;32:*.exe=01;32:*.com=01;32:*.bat=01;32:*.btm=01;32:*.dll=01;32:*.tar=00;31:*.tbz=00;31:*.tgz=00;31:*.rpm=00;31:*.deb=00;31:*.arj=00;31:*.taz=00;31:*.lzh=00;31:*.lzma=00;31:*.zip=00;31:*.zoo=00;31:*.z=00;31:*.Z=00;31:*.gz=00;31:*.bz2=00;31:*.tb2=00;31:*.tz2=00;31:*.tbz2=00;31:*.xz=00;31:*.avi=01;35:*.bmp=01;35:*.dl=01;35:*.fli=01;35:*.gif=01;35:*.gl=01;35:*.jpg=01;35:*.jpeg=01;35:*.mkv=01;35:*.mng=01;35:*.mov=01;35:*.mp4=01;35:*.mpg=01;35:*.pcx=01;35:*.pbm=01;35:*.pgm=01;35:*.png=01;35:*.ppm=01;35:*.svg=01;35:*.tga=01;35:*.tif=01;35:*.webm=01;35:*.webp=01;35:*.wmv=01;35:*.xbm=01;35:*.xcf=01;35:*.xpm=01;35:*.aiff=00;32:*.ape=00;32:*.au=00;32:*.flac=00;32:*.m4a=00;32:*.mid=00;32:*.mp3=00;32:*.mpc=00;32:*.ogg=00;32:*.voc=00;32:*.wav=00;32:*.wma=00;32:*.wv=00;32:"
DEBUG: envp[1]="HOSTTYPE=x86_64"
DEBUG: envp[2]="XAUTHLOCALHOSTNAME=linux-h9wr"
DEBUG: envp[3]="XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB"
DEBUG: envp[4]="LANG=POSIX"
DEBUG: envp[5]="WINDOWMANAGER=/usr/bin/gnome"
DEBUG: envp[6]="LESS=-M -i"
DEBUG: envp[7]="DISPLAY=:0"
DEBUG: envp[8]="JAVA_ROOT=/usr/lib64/jvm/jre-11-openjdk"
DEBUG: envp[9]="HOSTNAME=linux-h9wr"
DEBUG: envp[10]="OLDPWD=/root"
DEBUG: envp[11]="CONFIG_SITE=/usr/share/site/x86_64-unknown-linux-gnu"
DEBUG: envp[12]="CSHEDIT=emacs"
DEBUG: envp[13]="GPG_TTY=/dev/pts/2"
DEBUG: envp[14]="AUDIODRIVER=pulseaudio"
DEBUG: envp[15]="LESS_ADVANCED_PREPROCESSOR=no"
DEBUG: envp[16]="COLORTERM=1"
DEBUG: envp[17]="JAVA_HOME=/usr/lib64/jvm/jre-11-openjdk"
DEBUG: envp[18]="ALSA_CONFIG_PATH=/etc/alsa-pulse.conf"
DEBUG: envp[19]="MACHTYPE=x86_64-suse-linux"
DEBUG: envp[20]="QEMU_AUDIO_DRV=pa"
DEBUG: envp[21]="MINICOM=-c on"
DEBUG: envp[22]="QT_SYSTEM_DIR=/usr/share/desktop-data"
DEBUG: envp[23]="OSTYPE=linux"
DEBUG: envp[24]="USER=root"
DEBUG: envp[25]="PAGER=less"
DEBUG: envp[26]="MORE=-sl"
DEBUG: envp[27]="PWD=/tmp/bug1187232"
DEBUG: envp[28]="HOME=/root"
DEBUG: envp[29]="LC_CTYPE=en_US.UTF-8"
DEBUG: envp[30]="HOST=linux-h9wr"
DEBUG: envp[31]="XNLSPATH=/usr/share/X11/nls"
DEBUG: envp[32]="XDG_DATA_DIRS=/root/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share"
DEBUG: envp[33]="PROFILEREAD=true"
DEBUG: envp[34]="FROM_HEADER="
DEBUG: envp[35]="MAIL=/var/spool/mail/root"
DEBUG: envp[36]="PPD=/tmp/bug1187232/hp-officejet_pro_1150c.ppd"
DEBUG: envp[37]="LESSKEY=/etc/lesskey.bin"
DEBUG: envp[38]="TERM=xterm"
DEBUG: envp[39]="SHELL=/bin/bash"
DEBUG: envp[40]="LS_OPTIONS=-A -N --color=tty -T 0"
DEBUG: envp[41]="XCURSOR_THEME=DMZ"
DEBUG: envp[42]="PYTHONSTARTUP=/etc/pythonstart"
DEBUG: envp[43]="SHLVL=1"
DEBUG: envp[44]="MANPATH=/usr/share/man:/usr/local/man"
DEBUG: envp[45]="LOGNAME=root"
DEBUG: envp[46]="XAUTHORITY=/root/.xauthW4NA1N"
DEBUG: envp[47]="JRE_HOME=/usr/lib64/jvm/java-11-openjdk-11"
DEBUG: envp[48]="XDG_CONFIG_DIRS=/etc/xdg"
DEBUG: envp[49]="PATH=/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin"
DEBUG: envp[50]="JAVA_BINDIR=/usr/lib64/jvm/jre-11-openjdk/bin"
DEBUG: envp[51]="SDL_AUDIODRIVER=pulse"
DEBUG: envp[52]="G_BROKEN_FILENAMES=1"
DEBUG: envp[53]="HISTSIZE=10000"
DEBUG: envp[54]="HISTFILESIZE=100000"
DEBUG: envp[55]="CPU=x86_64"
DEBUG: envp[56]="CVS_RSH=ssh"
DEBUG: envp[57]="_=/usr/lib/cups/filter/gstoraster"
INFO: Start rendering...
INFO: Processing page 1...
INFO: Processing page 2...
INFO: Rendering completed

/usr/lib/cups/filter/hpcups 1 user title 1 options \
 <gstoraster_stdout.CUPS_raster \
 >hpcups_stdout.hplip-3.19.12.pcl

PAGE: 1 1

# ls -l pdftopdf_stdout.pdf gstoraster_stdout.CUPS_raster \
 hpcups_stdout.hplip-3.19.12.pcl

... 22408200 Jun 14 14:24 gstoraster_stdout.CUPS_raster
...  1377317 Jun 14 14:25 hpcups_stdout.hplip-3.19.12.pcl
...   133504 Jun 14 14:22 pdftopdf_stdout.pdf

# file pdftopdf_stdout.pdf gstoraster_stdout.CUPS_raster \
 hpcups_stdout.hplip-3.19.12.pcl

pdftopdf_stdout.pdf:             PDF document, version 1.7
gstoraster_stdout.CUPS_raster:   Cups Raster version 3, Little Endian, 300x300 dpi, 2400x3112 pixels 8 bits/color 24 bits/pixel ColorOrder=Chunky ColorSpace=RGB
hpcups_stdout.hplip-3.19.12.pcl: HP PCL printer data
-------------------------------------------------------------

I upgraded to HPLIP 3.20.11 from the OBS Printing project
-------------------------------------------------------------
# osc getbinaries Printing hplip openSUSE_Leap_15.2 x86_64

# rpm -Uhv hplip-3.20.11-lp152.232.1.x86_64.rpm \
 hplip-hpijs-3.20.11-lp152.232.1.x86_64.rpm \
 hplip-sane-3.20.11-lp152.232.1.x86_64.rpm

warning: hplip-3.20.11-lp152.232.1.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 98c4529d: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...
   1:hplip-hpijs-3.20.11-lp152.232.1  ################################# [ 17%]
   2:hplip-sane-3.20.11-lp152.232.1   ################################# [ 33%]
   3:hplip-3.20.11-lp152.232.1        ################################# [ 50%]
Cleaning up / removing...
   4:hplip-3.19.12-lp152.2.3.1        ################################# [ 67%]
   5:hplip-sane-3.19.12-lp152.2.3.1   ################################# [ 83%]
   6:hplip-hpijs-3.19.12-lp152.2.3.1  ################################# [100%]

# rpm -qa | grep ^hplip
hplip-sane-3.20.11-lp152.232.1.x86_64
hplip-3.20.11-lp152.232.1.x86_64
hplip-hpijs-3.20.11-lp152.232.1.x86_64
-------------------------------------------------------------

Then I did re-run the hpcups filter
-------------------------------------------------------------
# /usr/lib/cups/filter/hpcups 1 user title 1 options \
 <gstoraster_stdout.CUPS_raster \
 >hpcups_stdout.hplip-3.20.11.pcl

PAGE: 1 1

# ls -l hpcups_stdout.*

... 1377317 Jun 14 14:25 hpcups_stdout.hplip-3.19.12.pcl
... 1377317 Jun 14 14:29 hpcups_stdout.hplip-3.20.11.pcl

# diff -s hpcups_stdout.hplip-3.19.12.pcl \
 hpcups_stdout.hplip-3.20.11.pcl

Files hpcups_stdout.hplip-3.19.12.pcl and hpcups_stdout.hplip-3.20.11.pcl are identical
-------------------------------------------------------------

So on my openSUSE Leap 15.2 x86_64 system the hpcups filter
of HPLIP 3.19.12 and HPLIP 3.20.11 produced identical output.

This matches that the souces of the hpcups filter
did almost not change from HPLIP 3.19.12 to HPLIP 3.20.11
-------------------------------------------------------------
# diff -r -U0 hplip-3.19.12/prnt/hpcups/ \
 hplip-3.20.11/prnt/hpcups/

diff -r -U0 hplip-3.19.12/prnt/hpcups/CommonDefinitions.h hplip-3.20.11/prnt/hpcups/CommonDefinitions.h
--- hplip-3.19.12/prnt/hpcups/CommonDefinitions.h       2019-12-10 06:00:33.000000000 +0100
+++ hplip-3.20.11/prnt/hpcups/CommonDefinitions.h       2020-11-30 01:03:52.000000000 +0100
@@ -468,0 +469 @@
+    int               args_duplex_mode;
diff -r -U0 hplip-3.19.12/prnt/hpcups/Hbpl1_Wrapper.cpp hplip-3.20.11/prnt/hpcups/Hbpl1_Wrapper.cpp
--- hplip-3.19.12/prnt/hpcups/Hbpl1_Wrapper.cpp 2019-12-10 06:00:33.000000000 +0100
+++ hplip-3.20.11/prnt/hpcups/Hbpl1_Wrapper.cpp 2020-11-30 01:03:52.000000000 +0100
@@ -174 +174 @@
-       PCLmPageContent.duplexDisposition = simplex;
+       PCLmPageContent.duplexDisposition = (duplexDispositionEnum)o_Hbpl1->m_JA.args_duplex_mode;
diff -r -U0 hplip-3.19.12/prnt/hpcups/HPCupsFilter.cpp hplip-3.20.11/prnt/hpcups/HPCupsFilter.cpp
--- hplip-3.19.12/prnt/hpcups/HPCupsFilter.cpp  2019-12-10 06:00:33.000000000 +0100
+++ hplip-3.20.11/prnt/hpcups/HPCupsFilter.cpp  2020-11-30 01:03:52.000000000 +0100
@@ -524,0 +525,13 @@
+   
+    if((strstr(argv[5],"Duplex=DuplexTumble")) || (strstr(argv[5],"Duplex=DuplexNoTumble")))
+
+    {
+        m_JA.args_duplex_mode = 2;
+    
+    }
+
+    else
+   {
+        m_JA.args_duplex_mode = 0;
+     
+   }
-------------------------------------------------------------

Same here, I can't reproduce the issue either (at least not with the procedure from comment 2).

(In reply to Martin Wilck from comment #3)
> Same here, I can't reproduce the issue either (at least not with the
> procedure from comment 2).

(tested on openSUSE Leap 15.3 aarch64).

(In reply to Johannes Meixner from comment #1)

> According to
> https://developers.hp.com/hp-linux-imaging-and-printing/supported_devices/
> index
> and
> https://developers.hp.com/hp-linux-imaging-and-printing/binary_plugin.html
> for the "HP Color LaserJet 2600n Printer"
> a so called "Plugin" is "Required" for "Printing support"
> which is proprietary software that must be downloaded from HP, cf.
> https://en.opensuse.org/SDB:Printer_buying_guide#HP_printers

Apparently there's an issue with the plugin for hplip 3.20.11. I get a wrong checksum error if I try to download it. Seems to be a known problem (https://forums.linuxmint.com/viewtopic.php?f=49&t=343350)

Christopher, it would help if you could show us a simple reproducer like in comment 1 that shows your problem, possibly with a sample PDF.
Or you could try to run hpcups under valgrind to provide outputs like the Debian bug reporters did. That would at least enable us to judge with some confidence whether it's the same issue.

(In reply to Johannes Meixner from comment #1)

> From what I see in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972339
> and
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974828
> it seems there is no simple and straightforward patch
> that one could blindly apply without a real test
> to get this issue fixed.

FTR: https://sources.debian.org/patches/hplip/3.21.2+dfsg1-2/?page=2,
Patch 79ff. 

Indeed, these patches are really just workarounds. The patch author blindly allocated additional bytes in certain places. It's illuminating to see the Debian maintainer express his frustration about hplip "upstream". I thought Debian had a better relationship to upstream than us, but it doesn't seem to be much better actually.

OTOH, these patches can't do harm, afaics. So if Debian considers them fit for inclusion, perhaps we could, too. We are in the unfortunate situation that upstream just doesn't fix bugs.

(In reply to Johannes Meixner from comment #2)
 
> This matches that the souces of the hpcups filter
> did almost not change from HPLIP 3.19.12 to HPLIP 3.20.11

True. The rpm optflags used are the same between 15.2 and 15.3, too, and the compiler is gcc-7.5.0 for both environments. So if one crashes and the other doesn't, I conjecture that it must be a library issue.

One thing that did change (and affects the command line used for compiling) was the addition of avahi support to hplip. I very much doubt that this matters here though.

I got this printer as a hand-me-down, but thank you for pointing to the suggested alternatives.

I noticed this comment https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972339#50 about similar possible allocation workarounds present in the upstream source.

Downgrading to hplip 3.19.12-lp152.1.1 worked, though that turned out to be because I neglected to properly clean and update the proprietary plugin. (Normally the plugin installer refuses to install for a mismatched HPLIP version, however hpcups will not alert at runtime that the plugin is outdated rather than potentially crash.)

I now have hplip 3.20.11-2.1 and the correct plugin version installed and working. I never encountered the hplip-3.20.11-plugin.run checksum error, though I had done some steps manually: verified it against hplip-3.20.11-plugin.run.asc, extracted it, and then ran its Python installer script directly:

gpg --keyserver keyserver.ubuntu.com --recv-keys gpg --keyserver keyserver.ubuntu.com --recv-keys 73D770CDA59047B9
gpg --verify hplip-3.20.11-plugin.run.asc hplip-3.20.11-plugin.run
sh hplip-3.20.11-plugin.run --noexec --target hpplugindir-3.20.11
cd hpplugindir-3.20.11
python3 plugin_install.py -i

I notice there is an OBS community build of HPLIP 3.21.4 for x86_64, so maybe I will consider deriving an aarch64 build and trying it.

Thank you to everyone who investigated, and sorry for the noise.

Martin Wilck,

thank you for trying to reproduce it on Leap 15.3.
Yesterday late afternoon I was about to install
a Leap 15.3 virtual machine to check it there
but my kids rightfully got precedence :-)

FYI regarding comment #6
"frustration about hplip upstream":

When HPLIP was initially developed I and other Linux distribution
people had a perfect relationship to HPLIP developers in the US.
We even met at the Printing Summit in Montreal, cf.
https://wiki.linuxfoundation.org/openprinting/summitmontreal
Later HP decided to take HPLIP away from the US developers
and move it to new developers (I guess to save costs)
but that destroyed all the over years established valuable
cooperation which never came back - not even a little bit.
I think in the end HP gets what they pay for.


Christopher Chavez,

thank you for your clear descriptive feedback what the
root cause was in your particular case:

The installed HPLIP plugin did not match the installed HPLIP.

Interesting to see that there are no appropriate checks
in HPLIP programs that plugin version and program version match
so it seems HPLIP programs blindly use plugin code and then
fail in arbitrary ways if the plugin code does not fit :-(

(In reply to Christopher Chavez from comment #8)

> Downgrading to hplip 3.19.12-lp152.1.1 worked, though that turned out to be
> because I neglected to properly clean and update the proprietary plugin.

I don't understand. Are you saying that the crashes you reported were caused by using the 3.19.12 plugin with the 3.20.11 SUSE package?

> I now have hplip 3.20.11-2.1 and the correct plugin version installed and
> working. I never encountered the hplip-3.20.11-plugin.run checksum error,

How / from where did you download? The issue occurs if you run the "hp-plugin" tool. It fetches a list of plugin URLs and checksums from the hplip web site, and the 3.20.11 checksum in that file doesn't match.

> I notice there is an OBS community build of HPLIP 3.21.4 for x86_64, so
> maybe I will consider deriving an aarch64 build and trying it.

We recently got an update request for 3.21.4, but I had to reject it because of a build error for i586.

If I understand it correctly it seems the actual problem is
that one can do a HPLIP version upgrade via RPM packages
without doing a HPLIP plugin upgrade (if a plugin is used).

I am thinking about how to solve that.

On the one hand a HPLIP version upgrade via RPM packages
must be possible while an old HPLIP plugin is installed
because the new HPLIP version needs to be there
to be able to download and install the new plugin.

On the other hand new HPLIP should not be "just usable"
without first downloading and and installing new plugin
when a plugin is used.

On the third hand ("tertium datur" in practice always ;-)
when there are two printers one that needs a plugin
and another one that does not need a plugin,
things should still "just work" on the latter one
after HPLIP version upgrade via RPM packages.
Only for the printer that actually needs a a plugin
things should not work until the new plugin is there.

So I am thinking about some kind of RPM post install script
that could somehow disable an old plugin so that the user would
get some kind of "missing plugin" messages from HPLIP programs
when he tries to use a printer that actually needs a plugin
after HPLIP version upgrade via RPM packages.

Simply put:
After HPLIP version upgrade via RPM packages
the user should experience the same behaviour
as after an initial HPLIP installation via RPM packages
when he tries to use a printer that actually needs a plugin.

(In reply to Johannes Meixner from comment #11)
> If I understand it correctly it seems the actual problem is
> that one can do a HPLIP version upgrade via RPM packages
> without doing a HPLIP plugin upgrade (if a plugin is used).

Is it possible to update the original HPLIP package without updating the plugin?
Does the installation script automatically update it?

> On the one hand a HPLIP version upgrade via RPM packages
> must be possible while an old HPLIP plugin is installed
> because the new HPLIP version needs to be there
> to be able to download and install the new plugin.
> 
> On the other hand new HPLIP should not be "just usable"
> without first downloading and and installing new plugin
> when a plugin is used.

In terms of rpm dependencies, you would create a "requires:" 
dependency of the hp-plugin package to hplip-hpijs.

Could we simply repackage hp-plugin in rpm format, and publish it e.g. 
via packman? I wouldn't be any worse than it is now, and we could use
rpm dependencies. We'd have additional work though.

Oops - accidentally I reopened it - I want to keep it closed.

There is no hp-plugin RPM package so there cannot be
RPM dependencies for it and we (i.e. openSUSE or SUSE)
cannot package HPLIP plugins because it is proprietary stuff.

I would never even package anything where the legal state
for me, for openSUSE and SUSE, and for our users and customers
is not 100% clear.

In the old times where cooperation betweenn HP US developers
and Linux distributions had happened when the HPLIP plugin stuff
was developed it was made clear that HP and only HP deals with
their proprietary stuff - in particular to avoid possible legal
issues.

I played around with HP's HPLIP plugin stuff
on a Leap 15.3 x86_64 virtual machine without a printer
so here some first intermediate info for the log:

Running 'hp-plugin -i' as root failed for me with
"hplip-3.20.11-plugin.run file does not match its checksum"
as described in comment #5
https://forums.linuxmint.com/viewtopic.php?f=49&t=343350
but "fortunately" the downloaded hplip-3.20.11-plugin.run
gets then removed by hp-plugin's overenthusiastic cleanup :-(

So I did a manual download and installation via
------------------------------------------------------------
# wget http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/hplip-3.20.11-plugin.run
------------------------------------------------------------
By the way:
https://developers.hp.com/hp-linux-imaging-and-printing/plugins
lists other URLs where one can download things
if download from www.openprinting.org doesn't work.

Then I did a manual installation via
------------------------------------------------------------
# chmod u+x hplip-3.20.11-plugin.run

# ./hplip-3.20.11-plugin.run
------------------------------------------------------------
which seems to have succeeded (no errors shown).
But it did not show any info what it installed where.
Never tell the user to avoid confusion - yeah! :-(

So I did a manual search what new files I got via
------------------------------------------------------------
# for f in $( find /usr | grep hplip | grep plugin ) ; \
 do rpm -qf $f ; done \
 | grep 'not owned by any package' \
 | cut -d ' ' -f2

/usr/share/hplip/fax/plugins
/usr/share/hplip/fax/plugins/fax_marvell-x86_64.so
/usr/share/hplip/fax/plugins/fax_marvell.so
/usr/share/hplip/plugin.spec
/usr/share/hplip/prnt/plugins
/usr/share/hplip/prnt/plugins/lj-x86_64.so
/usr/share/hplip/prnt/plugins/hbpl1-x86_64.so
/usr/share/hplip/prnt/plugins/lj.so
/usr/share/hplip/prnt/plugins/hbpl1.so
/usr/share/hplip/data/plugins
/usr/share/hplip/data/plugins/license.txt
/usr/share/hplip/scan/plugins
/usr/share/hplip/scan/plugins/bb_marvell.so
/usr/share/hplip/scan/plugins/bb_orblite.so
/usr/share/hplip/scan/plugins/bb_soapht-x86_64.so
/usr/share/hplip/scan/plugins/bb_marvell-x86_64.so
/usr/share/hplip/scan/plugins/bb_orblite-x86_64.so
/usr/share/hplip/scan/plugins/bb_soap.so
/usr/share/hplip/scan/plugins/bb_escl.so
/usr/share/hplip/scan/plugins/bb_soapht.so
/usr/share/hplip/scan/plugins/bb_escl-x86_64.so
/usr/share/hplip/scan/plugins/bb_soap-x86_64.so
------------------------------------------------------------

Unfortunately it seems there is no 'hp-...' tool that
shows what HPLIP plugin version is currently installed
in particular hp-plugin doesn't provide that info :-(

Also /usr/share/hplip/plugin.spec does not tell
the HPLIP version where the plugin files match.

Even using 'readelf -a' on the plugin *.so files
did not help me to see the matching HPLIP version
but I am not at all an expert in shared object details
so I may have overlooked something here.

So I am now stuck because currently I cannot determine
what HPLIP version matches the installed plugin files.

But this is a precondition to decide if installed plugin
files are old/outdated for an installed HPLIP version
which is a precondition to disable old/outdated plugins.

(In reply to Johannes Meixner from comment #14)
> Then I did a manual installation via
> ------------------------------------------------------------
> # chmod u+x hplip-3.20.11-plugin.run
> 
> # ./hplip-3.20.11-plugin.run
> ------------------------------------------------------------
> which seems to have succeeded (no errors shown).
> But it did not show any info what it installed where.

It takes arguments. You can run "./hplip-3.20.11-plugin.run --list"

Obviously, running such a script as root after receiving a message that the checksum failed should be discouraged for end users. 
OK on a test VM, but not otherwise.

What `./hplip-3.20.11-plugin.run --list` shows
is what is in the archive but that is different
compared to what is installed.
Not all what is in the archive is also installed.
In particular 'version.txt' in the archive seems
to be not installed - at least I cannot find it.

When I have the hplip-3.20.11-plugin.run file
I can get the matching HPLIP version
e.g. with
-------------------------------------------------------------
# ./hplip-3.20.11-plugin.run --noexec --keep --target /tmp/hp-plugin
...

# cat /tmp/hp-plugin/version.txt 
3.20.11
-------------------------------------------------------------
and also with
-------------------------------------------------------------
# ./hplip-3.20.11-plugin.run --info
Identification: HPLIP 3.20.11 Plugin Self Extracting Archive
Target directory: plugin_tmp
Uncompressed size: 31968 KB
Compression: gzip
Date of packaging: Mon Nov 30 05:38:21 IST 2020
Built with Makeself version 2.1.5 on
Build command was: /usr/bin/makeself \
    "plugin_tmp" \
    "hplip-3.20.11-plugin.run" \
    "HPLIP 3.20.11 Plugin Self Extracting Archive" \
    "./hplip-plugin-install" \
    "-v" \
    "3.20.11" \
    "-c" \
    "64"
Script run after extraction:
     ./hplip-plugin-install -v 3.20.11 -c 64
plugin_tmp will be removed after extraction
-------------------------------------------------------------

But I fail to get the matching HPLIP version
from the installed plugin files.

For the fun of it:
The modern way to install things is 'sudo curl ... | sh' ;-)

(In reply to Johannes Meixner from comment #17)
> The modern way to install things is 'sudo curl ... | sh' ;-)

That's too secure. sh isn't even run as root :D 
I suggest:

curl --insecure $URL | sudo sh

Yes of course!
I had only 'curl | sh' and added the 'sudo' at the wrong place.
See https://gist.github.com/btm/6700524
"Why curl | sudo bash is good"
I even somewhat agree.
The crucial part is that one trusts the download site.
When I trust openprinting.org it does not matter much
if what I get matches a checksum from the same site.

I did encounter various issues (which I’ve neglected to report myself) during previous attempts to use the hp-plugin utility on aarch64, and resorted to obtaining the plugin directly and doing various steps manually.

I thought I saw a comment somewhere pointing out that the plugin tends to change very little. Comparing the contents of plugin versions 3.19.12 and 3.20.11, the only functional differences were for a couple non-aarch64 shared objects and the version number. Having the correct version in /var/lib/hp/hplip.state somehow is enough to avoid the crash.

For someone else who ran into the problem of updating HPLIP without updating the plugin, hpcups did report the version mismatch: http://thomas.quinot.org/labnotes/blog/2018/07/31/hplip-wont-print/
So maybe in my case hpcups was crashing without successfully reporting the version mismatch.

I’m aware distributions like Fedora had unresolved concerns about HPLIP plugin licensing preventing them from redistributing it, although I notice at least Arch has gone ahead with repackaging the plugin. However various distributions offer packages to wrap the Microsoft Core Fonts installer (fetchmsttfonts in openSUSE) which download proprietary resources during installation and display their EULA prompt, rather than repackage their contents. I’m not aware of any distributions doing something similar for HPLIP plugin, but would that be an applicable workaround?

In general there is no such thing as a "workaround"
in case of legal issues for Linux distributors.

Individual persons or individual legal entities may do things
different depending on their legal state and legislation.

The HPLIP plugin is proprietary stuff.
Its contents could be under various different proprietary licenses
with various different terms and conditions from various different
proprietary license holders from various different countries
under various different legislations.

E.g. think about the firmware files in the HPLIP plugin.
Firmware is usually under a proprietary license of the
actual maker of a piece of hardware and at least some
printers that need the proprietary HPLIP plugin
are not actually made by HP but by some other company,
cf. what the HP US developer David Suffield wrote in
https://bugs.launchpad.net/hplip/+bug/187049/comments/4
(excerpt): "Unfortunately these out-sourced printers ..."
So firmware files in the HPLIP plugin could be under a
proprietary license not from HP but from some other company
perhaps from some other country not under US legislation.

It is likely the same kind of legal issue for this or that
non-free printer languages that are used by at least some
printers that need the proprietary HPLIP plugin so certain
shared objects in the HPLIP plugin could be (also) under a
proprietary license not from HP but from some other company
perhaps from some other country not under US legislation.

In addition there are also possible patent issues.

When an individual person or legal entity owns a particular
printer model it usually got the legal rights to also have
the firmware of that piece of hardware and to have and use
software and patents that belong to that particular printer.

In contrast a Linux distributor usually does not have
the legal rights to distribute proprietary firmware or
proprietary software that belongs to certain hardware.

In the old times where cooperation between the HP US developers
and Linux distributors had happened when the HPLIP plugin stuff
was designed by the HP US developers together with people from
Linux distributors (in particular together with me) we perfectly
agreed that HP and only HP deals with their proprietary stuff
in particular to completely avoid any possible legal issues.

The crucial thing is that there is a strict separation
between the HPLIP free software parts that can be freely
provided by Linux distributors versus HP's proprietray parts
which cannot, must not, and should not be provided by
Linux distributors.

So the basic outcome was that HP provides a free software tool
('hp-plugin' and all what it needs to run as free software)
that deals "in the right way" with HP's proprietary stuff
so Linux distributors only have to provide that tool "as is"
(as part of the free HPLIP software) and don't need to,
and should not, and must not care about anything else.

I will never ever package anything where the legal state for me,
for openSUSE and SUSE, and for our users and customers in all those
various different countries with various different legislations
is not 100% clear and I will also never ever accept a package
where the legal state is not 100% clear, cf. the section
"General conditions for software packages in the Printing project" in
https://en.opensuse.org/openSUSE:How_to_contribute_to_the_Printing_project

For the not so fun of it what I myself witnessed:
What can happen to a Linux distributor when something happens
to get distributed where the legal state is not 100% clear,
google for
---------------------------------------------------------
SuSE Krayon
---------------------------------------------------------
It had been all about one single word - crazy world!

Christopher Chavez
thank you for pointing to /var/lib/hp/hplip.state
I did not know about it - I never cared much about
the internals of HP's proprietary HPLIP plugin stuff.

I can now reproduce the initial issue of this bug report
and your finding in your comment #20
on my Leap 15.3 x86_64 virtual machine without a printer:

With the original /var/lib/hp/hplip.state
------------------------------------------------------------
[plugin]
installed = 1
eula = 1
version = 3.20.11
------------------------------------------------------------
the following filter chain works (cf. comment #2) for me
(long lines show wrapped here):
------------------------------------------------------------
# export PPD=/usr/share/cups/model/manufacturer-PPDs/hplip-plugin/hp-laserjet_1020.ppd.gz ; \
 { cat /usr/share/ghostscript/*/examples/colorcir.ps \
 | /usr/lib/cups/filter/gstoraster 1 user title 1 options \
 | /usr/lib/cups/filter/hpcups 1 user title 1 options 1>/dev/null \
 && echo OK || echo FAILED ; } 2>&1 | tail -n10

DEBUG: envp[59]="CPU=x86_64"
DEBUG: envp[60]="SSH_SENDS_LOCALE=yes"
DEBUG: envp[61]="LESSOPEN=lessopen.sh %s"
DEBUG: envp[62]="_=/usr/lib/cups/filter/gstoraster"
INFO: Start rendering...
INFO: Processing page 1...
PAGE: 1 1
INFO: Processing page 2...
INFO: Rendering completed
OK
------------------------------------------------------------

In contrast with a modified /var/lib/hp/hplip.state
with a non-matching old plugin version
------------------------------------------------------------
[plugin]
installed = 1
eula = 1
version = 3.19.12
------------------------------------------------------------
the same filter chain fails
with "STATE: +hplip.plugin-error"
and also with "free(): invalid pointer"
(long lines show wrapped here):
------------------------------------------------------------
# export PPD=/usr/share/cups/model/manufacturer-PPDs/hplip-plugin/hp-laserjet_1020.ppd.gz ; \
 { cat /usr/share/ghostscript/*/examples/colorcir.ps \
 | /usr/lib/cups/filter/gstoraster 1 user title 1 options \
 | /usr/lib/cups/filter/hpcups 1 user title 1 options 1>/dev/null \
 && echo OK || echo FAILED ; } 2>&1 | tail -n10

DEBUG: envp[62]="_=/usr/lib/cups/filter/gstoraster"
INFO: Start rendering...
INFO: Processing page 1...
STATE: +hplip.plugin-error
prnt/hpcups/dbuscomm.cpp 86: Error: dBus connection ptr is NULL.
prnt/hpcups/HPCupsFilter.cpp 489: m_Job initialization failed with error = 48
free(): invalid pointer
INFO: Processing page 2...
INFO: Rendering completed
FAILED
------------------------------------------------------------

Unfortunately I didn't find a hp-* tools command that calls
the validate_plugin_version function in common/utils.c

As far as I see validate_plugin_version() is only
called by load_plugin_library() in common/utils.c and
load_plugin_library is only called by hpcups for printing
(and by some 'scan/sane/*.c' code for scanning).

'hp-check -r' only shows /var/lib/hp/hplip.state "as is" but it
does not report an incompatible plugin version as "INCOMPAT" :-(

One gets better stderr output when in the above filter chains
------------------------------------------------------------------
/usr/lib/cups/filter/gstoraster 1 user title 1 options 2>/dev/null
------------------------------------------------------------------
is used because the gstoraster messages are not of interest here.
Then with non-matching plugin version in /var/lib/hp/hplip.state
one gets (long lines show wrapped here):
------------------------------------------------------------------
# export PPD=/usr/share/cups/model/manufacturer-PPDs/hplip-plugin/hp-laserjet_1020.ppd.gz ; \
 { cat /usr/share/ghostscript/*/examples/colorcir.ps \
 | /usr/lib/cups/filter/gstoraster 1 user title 1 options 2>/dev/null \
 | /usr/lib/cups/filter/hpcups 1 user title 1 options 1>/dev/null \
 && echo OK || echo FAILED ; } 2>&1 | tail -n10

STATE: +hplip.plugin-error
prnt/hpcups/dbuscomm.cpp 86: Error: dBus connection ptr is NULL.
prnt/hpcups/HPCupsFilter.cpp 489: m_Job initialization failed with error = 48
free(): invalid pointer
FAILED
------------------------------------------------------------------

To at least describe things I added a new section
"Some HP devices require a proprietary HPLIP 'plugin'"
to
https://en.opensuse.org/SDB:How_to_set-up_a_HP_printer