version 3.20.6 turns off plugin requirement for most printers

I added that affects Ubuntu as well even when they haven't got 3.20.6 in their repos yet, because it is just matter of time they will have and the issue will affect them too.

Thank you for taking the time to report this bug and help make Ubuntu better. Unfortunately, we cannot work on this bug because your description didn't include enough information. You may find it helpful to read 'How to report bugs effectively' http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem.

We have instructions on debugging some types of problems at http://wiki.ubuntu.com/DebuggingProcedures.

At a minimum, we need:
1. The specific steps or actions you took that caused you to encounter the problem.
2. The behavior you expected.
3. The behavior you actually encountered (in as much detail as possible).

Thanks!

Hi Sebastien,

as I wrote in the previous comment, I filed the issue for Ubuntu for the future, because it seems new hplip version hasn't arrived yet.

I'm able to reproduce the issue with my MFD device - HP LaserJet m1536 - with scanning. According of hpaio code, most devices are using a plugin for scanning.

The basic reproducer is (after you install hplip-3.20.6):

Prereq:
- has an OS which haven't had HP plugin installed before ('hp-plugin' wasn't run successfully)
- has a device which needs HP plugin for printing or scanning or for both
- printing and scanning needs to be done via HPLIP, not via any driverless solutions (print queue device uri needs to start with 'hp://', scanner device uri with 'hpaio://')

Steps to reproduce for printing (if the device needs HP plugin for printing):
1) install the print queue via hp-setup
2) try to print

Actual result:
Printing fails due missing plugin

Expected result:
Printing goes well

Steps to reproduce for scanning (if the device needs HP plugin for scanning):
1) find out your scanner device uri with:

$ scanimage -L

2) take hpaio:// uri from previous uri and use scanimage to scan:

$ scanimage -d <device_uri> >out.pnm

Actual results:
Scanning fails with Device I/O.

Expected results:
Scanning works.

The issue which is affecting all flavours of Ubuntu 20.04LTS and HPLIP is already known. In short the move from python 2 to python 3 in 20.04 renders HPLIP all but useless as the scanning features required by HP MFP`s require the plug-in which cannot be installed because the python 2 dependencies cannot be resolved.
I am sure the HP developers are aware of this due to past reporting, we can only await for the fix to arrive

The bug report has an upstream task, so the HPLIP developers at HP should be aware.

Seems that the main (free software) part of HPLIP which comes packaged with the Linux distributions has no problem with Python 3 but the proprietary plugin which one has to install separately for certain devices requires Python 2. Newer distro versions, especially also Ubuntu 20.04 LTS have dropped Python 2 completely in favor of Python 3, as nowadays practically all important free software projects work with Python 3.

To the HPLIP developers at HP, can you make sure that the plugin works also on systems with only Python 3 and no Python 2 installed? On Ubuntu 20.04 LTS and many other newer Linux distributions Python 2 got removed.

In many cases, especially on printers which need the plug-in only for scanning one can go a driverless way without HPLIP or anything proprietary needed.

If you run the utility

driverless

on the command line and an entry corresponding to your printer gets listed, it should work driverless. Also if system-config-printer lists your device under the discovered network printers (independent whether it is connected by USB or network, the driverless printing/scanning framework emulates a network printer if the device is connected to USB) with an entry with "driverless" under the connection types, you can do driverless printing.

SANE frontends like simple-scan should list your printer, too. Make sure to select an entry which contains "eSCL".

Hi Chris,

I beg to differ - this issue has nothing to do with python 2 -> python 3 move. Plugins are binary blobs, not python scripts and installation scripts shipped with them are python 3 compatible.

It is about HPLIP upstream changed the 'plugin' and 'plugin-reason' entries in models.dat to '0' for most devices which needed it before.

It results into problems described above in certain situations.

Hi Till,

the plugin has a script inside itself, which calls 'python' binary - we have 'python' file as a symlink to 'python3' in Fedora, but Ubuntu seems to do not have a such binary or symlink.

Seems like a bug for Ubuntu Python team, but it is still a different issue than this one is, turning off plugin requirement for most devices.

@zdohnal, not having an 'unversioned' python is a choice and what upstream is doing as well on the way to transition to python3 being the standard

@ zdohnal

Hi, all I was doing was echoing what the consensus of opinion was after upgrading to 20.04LTS, see https://ubuntu-mate.community/t/hplip-missing-files/21782 for more information.
If you think that the reasoning behind the opinion is wrong then by all means offer an alternative, as I said I was just offering an opinion.

@ Chris York,

thank you for the link! Unfortunately, the issue I report in this ticket is a different from the issue in the link.

@ seb128,

It was just my guess what can be wrong if plugin installation goes wrong after removing python2 support in Ubuntu, based on my experience with python2 removal in Fedora.

@ till-kamppeter

IMO this issue is different from what you mentioned, unless disabling the requirement is an outcome of the issue you mentioned.

Another issue caused by the change mentioned in this issue:

https://bugs.launchpad.net/hplip/+bug/1884835

Thanks @zdohnal for this bug. Thanks to your report, I have uploaded our repackaged 3.20.6+dfsg0 to debian/experimental only, so it won't be auto-sync'ed to Debian.

I really wish hplip upstream developement would happen on a public VCS, so that we could better understand the reasons behind such changes (and a place where we could discuss our 74 patches…).

> I really wish hplip upstream developement would happen on a public VCS,
> so that we could better understand the reasons behind such changes (and
> a place where we could discuss our 74 patches…).

Damn, I need to get better :) we have only 56 downstream patches :D

zdohnal: Debian's patch queue is visible here: https://sources.debian.org/src/hplip/3.20.6+dfsg0-1/debian/patches/ , or as git commits here: https://salsa.debian.org/printing-team/hplip/-/commits/debian/experimental/ As you can see, many are yours, carefully hand-picked from https://src.fedoraproject.org/rpms/hplip/tree/master. I wonder if it would make sense to start an hplip-with-patches-for-linux-distros project to base our distro packages on a common base. But it would be obviously best for everyone if these patches would be taken over by hplip upstream; just saying.

Hi Didier,

let's talk about it over email, it is kind of off-topic here.

Hi zdenek,

Could you please provide the printer model name you are using?
HPLIP does not need to install plugin in order to print. It only requires plugin in order to scan.
Previously, few entities in models.dat had remained as plugin=1 , which has been removed in 3.20.6 release.

Also plugin has nothing to do with python version. It will work on python3 as well.

Please install plugin via ,
$sh hplip-3.20.6.plugin.run

Hi Shivani,

thank you for looking into the issue!

> Could you please provide the printer model name you are using?

HP LaserJet M1536dnf MFP

> HPLIP does not need to install plugin in order to print. It only requires plugin in order to > scan.

Unfortunately, it is not true for several devices, e.g.:

hp laserjet cp 1025nw
hp laserjet professional p 1102w

Their PDL is zjstream, which is supported only by binary blob downloaded via hp-plugin.

> Previously, few entities in models.dat had remained as plugin=1 , which has been removed in
> 3.20.6 release.

Actually, 'plugin=1' doesn't mean the plugin is needed for printing, but it means whether it is needed or not. The reason why the plugin is needed is covered by 'plugin-reason' (e.g. plugin-reason=64 means the plugin is needed for scanning). So when all 'plugin=1' entries were removed, all those devices think they don't need a plugin (for printing, or scanning, or both) and fail to print/scan anything if the plugin wasn't installed previously (common use case when installing a printer on freshly installed OS).

If I look into current upstream models.dat, it seems only scanjet models are marked as they need plugin. Multi-function devices are not taken into account.

Ad previous 'plugin=0/1' settings - I'm not sure how many HP devices you have at hand for testing, but at least when I look into scan/sane/hpaio.c:

if ((ma.scantype == HPMUD_SCANTYPE_MARVELL) || (ma.scantype == HPMUD_SCANTYPE_MARVELL2))
       return marvell_open(devicename, pHandle);
if (ma.scantype == HPMUD_SCANTYPE_SOAP)
       return soap_open(devicename, pHandle);
if (ma.scantype == HPMUD_SCANTYPE_SOAPHT)
       return soapht_open(devicename, pHandle);
if (ma.scantype == HPMUD_SCANTYPE_LEDM)
       return ledm_open(devicename, pHandle);
if ((ma.scantype == HPMUD_SCANTYPE_SCL) || (ma.scantype == HPMUD_SCANTYPE_SCL_DUPLEX) ||(ma.scantype == HPMUD_SCANTYPE_PML))
       return sclpml_open(devicename, pHandle);
if (ma.scantype == HPMUD_SCANTYPE_ESCL)
       return escl_open(devicename, pHandle);
if (ma.scantype == HPMUD_SCANTYPE_ORBLITE)
       return orblite_open(devicename, pHandle);
else
       return SANE_STATUS_UNSUPPORTED;

all device types except for SCL and PML call bb_load() function, which loads symbols from binary plugins downloaded via hp-plugin.
To sum it up, I would say most devices which are able to scan and didn't have 'plugin=1' and 'plugin-reason=64' had bad entries in models.dat and supposed to require a binary plugin for scanning.

> Also plugin has nothing to do with python version. It will work on python3 as well.

I wasn't the one who thought it is a python issue.

> Please install plugin via ,
> $sh hplip-3.20.6.plugin.run

This will certainly help, but you are missing the point. Before hplip-3.20.6, hp-setup (with models.dat help) was able to install the plugin automatically, when it recognized that found device needs it. models.dat is used as a database about device features, including plugin.

After hplip-3.20.6, models.dat lost info for several models regarding plugin, making them unusable unless you manually install the plugin.

IMO making a device work, which your suggestion does, is quite di...

Hi ,

We will revert the changes for these laserjets and release it in our next release.

Thanks for drawing our attention on this. Kindly wait till next release.

@ Shivani Mandora

Kindly wait till next release.

Has a date been earmarked?

Hi Shivani,

version 3.20.9 fixed plugin plugin requirement for several models, but other models stayed with the situation from 3.20.6.

And there are several models which have 'plugin-reason=65' (meaning it needs a plugin for printing and scanning), but have 'plugin=0' (means it doesn't need a plugin). Shouldn't they have rather 'plugin=1'?

Did you test whether models which you didn't revert 3.20.6 changes for work without plugin?

Thank you in advance,

Zdenek

One concrete example: `drv:///hpcups.drv/hp-laserjet_professional_p1107.ppd`

In 3.20.5, in hpcups.drv, it had as NickName:

  "HP LaserJet Professional p1107, hpcups $Version, requires proprietary plugin"

… this was changed in 3.20.6 to:

  "HP LaserJet Professional p1107, hpcups $Version"

… and unchanged in 3.20.9.

In models.dat, for that model, 3.20.5 had

  plugin=1
  plugin-reason=1

… this was changed in 3.20.6 to

  plugin=0
  plugin-reason=1

… and unchanged in 3.20.9.

But printing to this driver/printer gives a filter error:

  STATE: +hplip.plugin-error
  prnt/hpcups/HPCupsFilter.cpp 490: m_Job initialization failed with error = 48

(see https://salsa.debian.org/printing-team/hplip/-/jobs/937420 )

So although this was fixed for several printers, it certainly wasn't for all printers.

Hi Zdohnal,

We have reverted the changes only for the printers which are part of plugin.spec file which are few old laserjets printers and which require plugins to print.

Could you provide the list of printers on which you think plugins are needed?
I will verify and revert.

We have not verified on all the devices because of the device availability because few of them are very old.

Hi Shivani,

I'm sorry I don't have such a list.

Did you have such a list when you removed the dependency on plugin for other models in 3.20.6?

I base my request (revert all plugin dependency made in 3.20.6) upon the following logic:

- when model support was added it was tested by HPLIP project owners
- when user had a plugin problem with a model (the model needed a plugin although models.dat says it doesn't), he reached HPLIP project owners with the issue and they updated models.dat

so based on the prerequisites it doesn't make sense to remove dependency on plugin for models, unless you have a list of devices which you tested and actually don't need a plugin but they are noted as they need a plugin.

Wouldn't it make sense to revert the 'plugin state' to the state before 3.20.6, depending on the presumption 'the previous state was tested' is true?

In Debian, I have been successful with the attached patch against 3.20.9. It's basically a revert to the state of these printers at the state of models.dat in the 3.20.5 version.

The attachment "0076-3.20.6-regression-In-models.dat-take-3.20.5-s-plugin.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

I basically do the same in Fedora - reverting models.dat to its state in 3.20.5, because I don't have resource to actually test.

I based my report on assumption you actually have a internal versioning system (git, svn, bazaar, gitlab, github...) so you can revert commits regarding the plugin change.