Bug 1129228 - hplip: transition from hpijs to hpcups
hplip: transition from hpijs to hpcups
Status: RESOLVED WONTFIX
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Printing
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Johannes Meixner
Johannes Meixner
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-03-14 11:48 UTC by Martin Wilck
Modified: 2020-05-15 15:31 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Wilck 2019-03-14 11:48:44 UTC
Forked from bug 1128467

bug 1128467, comment 11 (Johannes Meixner):

FYI regarding HP printers and HPLIP in general:

HPLIP provides two printer drivers:

The old HPIJS that is declared deprecated/unmaintained/unsupported
by HPLIP upstream since a long time (since several years)
but as long as it works I keep in in our hplip RPMs.

The current HPCUPS that should be normally used.
HPCUPS is a "nowadays normal" printer driver where
in particular no IJS program spawned by Ghostscript.

As far as I see for each HPLIP <model>-hpijs.ppd.gz PPD file
there is a matching <model>.ppd.gz PPD file
(the PPD files without 'hpijs' use HPCUPS):
---------------------------------------------------------------------------
# for hpijs_ppd in $( \
 find /usr/share/cups/model/manufacturer-PPDs/ -name '*-hpijs.ppd.gz' ) ; \
 do hpcups_ppd=$( echo $hpijs_ppd | sed -e 's/-hpijs//' ) ; \
 test -s $hpcups_ppd || echo No $hpcups_ppd ; done

No /usr/share/cups/model/manufacturer-PPDs/hplip/HP-Fax3.ppd.gz
No /usr/share/cups/model/manufacturer-PPDs/hplip/HP-Fax4.ppd.gz
No /usr/share/cups/model/manufacturer-PPDs/hplip/HP-Fax2.ppd.gz
No /usr/share/cups/model/manufacturer-PPDs/hplip/HP-Fax.ppd.gz
---------------------------------------------------------------------------
Off the top of my head I don't know what the
/usr/share/cups/model/manufacturer-PPDs/hplip/HP-Fax*-hpijs.ppd.gz
are needed for - of course something related to 'faxing' but I assume
when HPIJS is deprecated/unmaintained/unsupported by HPLIP upstream
then HPLIP implements nowadays maintained faxing support differently
e.g. where no PPD file is needed at all for faxing?

I keep the old IJS stuff in Ghostscript basically only
for the outdated/deprecated/unmaintained/unsupported HPIJS.

I think the current security issues are a good reason
to get rid of that old/overcomplicated/insecure stuff
and drop first HPIJS and then IJS in Ghostscript
for openSUSE_Factory -> openSUSE_Tumbleweed.

----

Unfortunately, the transition between the drivers isn't necessarily smooth for users who currently use hpijs configurations. See bug 1128467, comment 14

bug 1128467, comment 17:

In general when a printer driver is dropped
existing print queues that use that driver will no longer work,
usually with a not really informative "Filter failed" message:
---------------------------------------------------------------------------
# lpadmin -p hpijstest -v file:///dev/null \
 -P /usr/share/cups/model/manufacturer-PPDs/hplip/hp-910-hpijs.ppd.gz\
 -E

# echo hello1 | lp -d hpijstest -t test1

# mv /usr/bin/hpijs /usr/bin/hpijs.away

# echo hello2 | lp -d hpijstest -t test2

# lpstat -p hpijstest
printer hpijstest is idle.  enabled since Mon 11 Mar 2019 09:06:11 CET
        Filter failed

# grep PID /var/log/cups/error_log
...
D [11/Mar/2019:09:06:11 +0100] [Job 18] PID 8550 \
 (/usr/lib/cups/filter/foomatic-rip) stopped with status 9.

# less /var/log/cups/error_log
...
D [11/Mar/2019:09:06:11 +0100] [Job 18]
 Starting renderer with command: gs -dShowAcroForm  -q -dBATCH
 -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=ijs -sIjsServer=hpijs
 -dDEVICEWIDTHPOINTS=612 -dDEVICEHEIGHTPOINTS=792
 -sDeviceManufacturer=\"HEWLETT-PACKARD\"
 -sDeviceModel=\"deskjet 3600\" -r300
 -sIjsParams=Quality:Quality=0,Quality:ColorMode=2,
             Quality:MediaType=0,Quality:PenSet=1
 -dIjsUseOutputFD -sOutputFile=-   /var/spool/cups/tmp/foomatic-h902Zw 
...
D [11/Mar/2019:09:06:11 +0100] [Job 18]
 sh: hpijs: command not found
D [11/Mar/2019:09:06:11 +0100] [Job 18]
 GPL Ghostscript 9.26: Can\'t start ijs server \"hpijs\"
D [11/Mar/2019:09:06:11 +0100] [Job 18]
 **** Unable to open the initial device, quitting.
D [11/Mar/2019:09:06:11 +0100] [Job 18]
 renderer exited with status 1
D [11/Mar/2019:09:06:11 +0100] [Job 18]
 Possible error on renderer command line or PostScript error.
 Check options.Kid3 exit status: 3
D [11/Mar/2019:09:06:11 +0100] [Job 18] PID 8550
 (/usr/lib/cups/filter/foomatic-rip) stopped with status 9.
---------------------------------------------------------------------------
Only with "LogLevel debug" one may notice in /var/log/cups/error_log
the "sh: hpijs: command not found" which points to the root cause.

Currently I have no good idea for a smooth transition from HPIJS to HPCUPS.
In particular I have no idea how to tell the user the root cause why his
existing HPIJS queue does no longer work.

We might first drop the
/usr/share/cups/model/manufacturer-PPDs/hplip/*-hpijs.ppd.gz
and
/usr/share/cups/model/manufacturer-PPDs/hplip-plugin/*-hpijs.ppd.gz
PPD files from the hplip-hpijs and hplip RPMs
but keep /usr/bin/hpijs
so that uses can no longer set up new print queues with HPIJS
but existing queues that use HPIJS will still work
(PPDs for existing queues are in /etc/cups/ppd/).

Then we could wait (how long?) and hope that very most of the
existing queues that use HPIJS somehow faded away.

Finally we could drop /usr/bin/hpijs (still existing HPIJS queues
will then no longer work as described above).
Comment 1 Martin Wilck 2019-03-14 11:50:03 UTC
Are there "preference rules" wrt what driver option is offered  to users first / most prominently? If yes, where? As noted in bug 1128467, from my experience it seems that hpcups was most prominently suggested only since 3.18.x. But that may also have been changed by some other update (e.g. cups).
Comment 2 Johannes Meixner 2020-05-15 13:37:14 UTC
I am afraid in the foreseeable future I won't find any time
to actually move this issue forward so all I can do is to
close it as "wontfix" - at least for the foreseeable future.

Perhaps this issue is actually a "feature"?
I don't know if dropping stuff that is marked by upstream
as deprecated/unmaintained/unsupported since a long time
requires a "feature" process at SUSE/openSUSE?
Comment 3 Martin Wilck 2020-05-15 15:31:57 UTC
(In reply to Johannes Meixner from comment #2)

> Perhaps this issue is actually a "feature"?
> I don't know if dropping stuff that is marked by upstream
> as deprecated/unmaintained/unsupported since a long time
> requires a "feature" process at SUSE/openSUSE?

I guess a JIRA would be needed. PM needs to agree if we remove a feature.