Bug 1671513 - after 'successful' plugin installation it is not installed
Summary: after 'successful' plugin installation it is not installed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: hplip
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Zdenek Dohnal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-01-31 19:04 UTC by Karel Volný
Modified: 2019-06-13 12:15 UTC (History)
6 users (show)

Fixed In Version: hplip-3.18.12-4.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-09 02:13:28 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Launchpad 1814574 None None None 2019-05-13 13:16:43 UTC

Description Karel Volný 2019-01-31 19:04:04 UTC
Description of problem:
I'd like to configure my MFP M477fdw via hp-setup. It discovers the printer on the wifi network, but when trying to to configure it, it says it needs the plugin for scanning. There are three options to choose from, however the third one to skip the installation (I don't need scanning now) cannot be chosen. Trying to install the plugin either way, from the web or local file, it pretends to pass, however instead of continuing to configure the printer, it says it needs the plugin to be installed ...

Trying to install the plugin via hp-plugin goes the same, but I'm getting coredump at the end (bug 1671509).

Version-Release number of selected component (if applicable):
hplip-3.18.12-1.fc29.x86_64

How reproducible:
always

Steps to Reproduce:
1. have M477fdw on your network
2. # dnf install hplip-gui
3. $ hp-setup
4. next, next, next ...

Actual results:
...
Downloading plug-in from: file:///home/kvolny/tmp/hplip/hplip-3.18.12-plugin.run
1100%Receiving digital keys: /usr/bin/gpg --homedir /home/kvolny/.hplip/.gnupg --no-permission-warning --keyserver pool.sks-keyservers.net --recv-keys 0x4ABA2F66DBD5A95894910E0673D770CDA59047B9
Creating directory plugin_tmp
Verifying archive integrity... All good.
Uncompressing HPLIP 3.18.12 Plugin Self Extracting Archive.........................................................

HP Linux Imaging and Printing System (ver. 3.18.12)
Plugin Installer ver. 3.0

Copyright (c) 2001-15 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Plug-in version: 3.18.12
Installed HPLIP version: 3.18.12
Number of files to install: 55

note: Using PyQt5
 
Done.
 Plug-in installation successful 

Done.
error:  The device you are trying to setup requires a binary plug-in. Some functionalities may not work as expected without plug-ins.  Please run 'hp-plugin' as normal user to install plug-ins.   Visit  http://hplipopensource.com  for more infomation.
Expected results:


Additional info:
no such error at the end, printer can be set up and used

Comment 1 Zdenek Dohnal 2019-02-04 18:26:45 UTC
Hi Karel,

thank you for reporting the issue! The problem is on HP site - they want to place binary blobs in dirs, which do not exist, like:

/usr/lib/i386-linux-gnu/libjpeg.so.9
/usr/lib/x86_64-linux-gnu/libjpeg.so.9
/usr/lib64/x86_64-linux-gnu/libjpeg.so.9
/usr/lib/i386-linux-gnu/sane/libsane-hp2000S1.so
/usr/lib/x86_64-linux-gnu/sane/libsane-hp2000S1.so
/usr/lib64/x86_64-linux-gnu/sane/libsane-hp2000S1.so

It seems like some new shared libraries...

HP scripts, downloaded by hp-plugin, ignores these links and that's why installation outcome is 'Done'. But '__readPluginStatus' method checks existence of these links and if they do not exist, set '__plugin_state' to 'corrupted'. And '__readPluginStatus' method is called in 'getStatus' method, which is used in gui setupdialog (it is not shown when hp-setup is called as 'interactive').

IMO you should be able to add the printer by 'hp-setup -i', because CLI variant does not end right after finding out the plugin is 'corrupted' (it just check return value of hp-plugin command, which is 0, and all old libraries are in correct places, removing .run file from ~/.hplip seems fine). 

It is really confusing and troubling issue, but not really in my powers to solve it - because all links and files are downloaded directly from HP, because they cannot be packaged in Fedora. HP upstream should fix it their .run file.

The abrupt workaround would be exclude these links from check in __readPluginStatus in installer/pluginhandler.py. 

Reported upstream https://bugs.launchpad.net/hplip/+bug/1814574

Comment 2 Fedora Update System 2019-02-05 13:42:08 UTC
hplip-3.18.12-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-b489194d24

Comment 3 Fedora Update System 2019-02-06 04:35:15 UTC
hplip-3.18.12-4.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-b489194d24

Comment 4 Karel Volný 2019-02-08 14:25:09 UTC
https://bodhi.fedoraproject.org/updates/FEDORA-2019-b489194d24#comment-892211

(I thought Bodhi should switch automatically?)

Comment 5 Fedora Update System 2019-02-09 02:13:28 UTC
hplip-3.18.12-4.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Comment 6 Dominik 'Rathann' Mierzejewski 2019-02-11 10:08:57 UTC
Can you try building an RPM package of the plugin using my spec file? https://gitlab.com/greysector/hplip-plugin

I noticed the new libs in the new version and tried to put them in the right place, but I don't have a printer that uses them so I couldn't test. It looks like you have one, so I'd appreciate it if you could test the latest version.

I'm not providing binary RPMs publicly because HP doesn't allow redistribution. I tried asking them for permission but the answer was: no.

Comment 7 Karel Volný 2019-02-12 15:54:22 UTC
@zdohnal: pls could you take a look and prepare what's needed to test?

@Dominik: if it doesn't move, ping me after RHEL8 is out - preferably in person, I tend to ignore mails from bugzilla, there's simply too many of them

Comment 8 Zdenek Dohnal 2019-02-12 16:22:23 UTC
Hi Dominik,

if you have correct info in your spec file, then the new shared libraries are for HP ScanJet Pro 2000, which Karel does not have. I only tested it by faking my HP officejet Pro 8500 wants plugin and check if older files are installed correctly and ignore the new ones for the time HP fixes its plugin.
Karel does have a type of HP color laserjet, which needed the plugin for scanning. And external scripts does not recognize if device actually needs only some of shared libraries and just install them all...

To sum it up, I nor Karel are able to check if it works :(

Comment 9 Karel Volný 2019-02-14 13:27:38 UTC
well, I could at least test the packaging, as the plugin installation is required for my device

to have a clean system, not influenced by our previous experiments, I've run KDE spin live dvd in qemu

I've built the packages from the spec referenced in comment #6 and installed them all

this pulled the hplip packages, however, to run hp-setup, I had to add hplip-gui manually (tested with 3.18.12-4.fc29)

to detect the device in hp-setup, I had to use manual setup, putting in the IP, as qemu creates own network by default and the broadcasts don't cross the network boundaries ... it worked without any problem, the device got detected

trying to configure it further, I got the request to install the plugin, same as what was the original point of this bugreport

so, bad luck, the plugin rpms obviously don't work for me, it doesn't get detected as already installed plugin


a few notes:

- I was building with rpmbuild under root, not mock, so I may have missed some misbehaviour

- it complained about macros in comments

- the gpg2 command to get Source2 is missing output file specification (I don't work with gpg so I was a bit surprised by getting binary mess printed in console ...)

Comment 10 Dominik 'Rathann' Mierzejewski 2019-02-15 10:36:23 UTC
(In reply to Karel Volný from comment #9)
> well, I could at least test the packaging, as the plugin installation is
> required for my device
> 
> to have a clean system, not influenced by our previous experiments, I've run
> KDE spin live dvd in qemu
> 
> I've built the packages from the spec referenced in comment #6 and installed
> them all
> 
> this pulled the hplip packages, however, to run hp-setup, I had to add
> hplip-gui manually (tested with 3.18.12-4.fc29)

It looks like hplip should have Recommends: hplip-gui. hp-setup supports
running in text mode, which might explain why there's no hard dependency.

> to detect the device in hp-setup, I had to use manual setup, putting in the
> IP, as qemu creates own network by default and the broadcasts don't cross
> the network boundaries ... it worked without any problem, the device got
> detected
>
> trying to configure it further, I got the request to install the plugin,
> same as what was the original point of this bugreport

Can you try without GUI, using the following command with correct IP?
hp-setup -g --auto 66.35.250.209

> so, bad luck, the plugin rpms obviously don't work for me, it doesn't get
> detected as already installed plugin

It would be useful to know what part of detection fails.

> a few notes:
> 
> - I was building with rpmbuild under root, not mock, so I may have missed
> some misbehaviour

I build it myself with rpmbuild under an unprivileged user or in mock. Both
work for me without any issues.

> - it complained about macros in comments

Well, that shouldn't be an issue. I have alternate download URL commented
out in case HP messes up uploads again.

> - the gpg2 command to get Source2 is missing output file specification (I
> don't work with gpg so I was a bit surprised by getting binary mess printed
> in console ...)

I don't understand what you mean here.

Thanks for trying!

Comment 11 Zdenek Dohnal 2019-02-15 12:15:14 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #10)
> (In reply to Karel Volný from comment #9)
> > well, I could at least test the packaging, as the plugin installation is
> > required for my device
> > 
> > to have a clean system, not influenced by our previous experiments, I've run
> > KDE spin live dvd in qemu
> > 
> > I've built the packages from the spec referenced in comment #6 and installed
> > them all
> > 
> > this pulled the hplip packages, however, to run hp-setup, I had to add
> > hplip-gui manually (tested with 3.18.12-4.fc29)
> 
> It looks like hplip should have Recommends: hplip-gui. hp-setup supports
> running in text mode, which might explain why there's no hard dependency.
> 

IMHO The problem with recommending is the recommended package is installed everytime with 'main' package when the recommended package is available in the repos and dnf transaction of main package does not fail when the recommended package is missing. So it is no good for use case (when we want to separate scripts, which can run in CLI and those which can use only GUI).



(In reply to Dominik 'Rathann' Mierzejewski from comment #10)
> > so, bad luck, the plugin rpms obviously don't work for me, it doesn't get
> > detected as already installed plugin
> 
> It would be useful to know what part of detection fails.
> 

IMO the check mentioned in comment#1 did not pass - __readPluginStatus() method checks for files from plugin - hp script knows which files they are by plugin.spec, which scripts from downloaded 'plugin' put in /usr/share/hplip. Did you updated plugin.spec too?

Comment 12 Dominik 'Rathann' Mierzejewski 2019-02-15 12:22:14 UTC
(In reply to Zdenek Dohnal from comment #11)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #10)
> > (In reply to Karel Volný from comment #9)
> > > well, I could at least test the packaging, as the plugin installation is
> > > required for my device
> > > 
> > > to have a clean system, not influenced by our previous experiments, I've run
> > > KDE spin live dvd in qemu
> > > 
> > > I've built the packages from the spec referenced in comment #6 and installed
> > > them all
> > > 
> > > this pulled the hplip packages, however, to run hp-setup, I had to add
> > > hplip-gui manually (tested with 3.18.12-4.fc29)
> > 
> > It looks like hplip should have Recommends: hplip-gui. hp-setup supports
> > running in text mode, which might explain why there's no hard dependency.
> > 
> 
> IMHO The problem with recommending is the recommended package is installed
> everytime with 'main' package when the recommended package is available in
> the repos and dnf transaction of main package does not fail when the
> recommended package is missing. So it is no good for use case (when we want
> to separate scripts, which can run in CLI and those which can use only GUI).

It won't be installed if soft dep installation is disabled or the package
is excluded. hp-setup supports both CLI and GUI modes, so I think it makes
sense to have a soft dep on hplip-gui, but of course it's your call.

> (In reply to Dominik 'Rathann' Mierzejewski from comment #10)
> > > so, bad luck, the plugin rpms obviously don't work for me, it doesn't get
> > > detected as already installed plugin
> > 
> > It would be useful to know what part of detection fails.
> > 
> 
> IMO the check mentioned in comment#1 did not pass - __readPluginStatus()
> method checks for files from plugin - hp script knows which files they are
> by plugin.spec, which scripts from downloaded 'plugin' put in
> /usr/share/hplip. Did you updated plugin.spec too?

That could be it, thanks for the clue. I'll patch plugin.spec.

Comment 13 Zdenek Dohnal 2019-02-15 13:40:54 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #12)
> (In reply to Zdenek Dohnal from comment #11)
> > IMHO The problem with recommending is the recommended package is installed
> > everytime with 'main' package when the recommended package is available in
> > the repos and dnf transaction of main package does not fail when the
> > recommended package is missing. So it is no good for use case (when we want
> > to separate scripts, which can run in CLI and those which can use only GUI).
> 
> It won't be installed if soft dep installation is disabled or the package
> is excluded. hp-setup supports both CLI and GUI modes, so I think it makes
> sense to have a soft dep on hplip-gui, but of course it's your call.
> 

Soft dep installation is enabled by default, is it? If it is, there are really very few people who install the sw with other option than just 'dnf install'...
And do you have any link for more info for excluding? 

Thanks!

Comment 14 Dominik 'Rathann' Mierzejewski 2019-02-15 14:25:37 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #12)
> (In reply to Zdenek Dohnal from comment #11)
> > (In reply to Dominik 'Rathann' Mierzejewski from comment #10)
[...]
> > > It would be useful to know what part of detection fails.
> > 
> > IMO the check mentioned in comment#1 did not pass - __readPluginStatus()
> > method checks for files from plugin - hp script knows which files they are
> > by plugin.spec, which scripts from downloaded 'plugin' put in
> > /usr/share/hplip. Did you updated plugin.spec too?
> 
> That could be it, thanks for the clue. I'll patch plugin.spec.

OK, I've just pushed a new release to my spec (3.18.12-2) file to gitlab,
please test with:

hp-setup -g -i 192.168.0.1

Substitute your printer's IP, of course.

On my machine, it seems to work fine:

hp-setup[29476]: debug: /usr/lib64/libjpeg.so.9 library file present.
hp-setup[29476]: debug: /usr/lib64/libjpeg.so.9 library status: 1
hp-setup[29476]: debug: /usr/lib64/sane/libsane-hp2000S1.so library file present.
hp-setup[29476]: debug: /usr/lib64/sane/libsane-hp2000S1.so library status: 1
hp-setup[29476]: debug: /usr/lib64/sane/libsane-hp2000S1.so.1 library file present.
hp-setup[29476]: debug: /usr/lib64/sane/libsane-hp2000S1.so.1 library status: 1

Comment 15 Dominik 'Rathann' Mierzejewski 2019-02-15 14:44:19 UTC
(In reply to Zdenek Dohnal from comment #13)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #12)
> > (In reply to Zdenek Dohnal from comment #11)
> > > IMHO The problem with recommending is the recommended package is installed
> > > everytime with 'main' package when the recommended package is available in
> > > the repos and dnf transaction of main package does not fail when the
> > > recommended package is missing. So it is no good for use case (when we want
> > > to separate scripts, which can run in CLI and those which can use only GUI).
> > 
> > It won't be installed if soft dep installation is disabled or the package
> > is excluded. hp-setup supports both CLI and GUI modes, so I think it makes
> > sense to have a soft dep on hplip-gui, but of course it's your call.
> 
> Soft dep installation is enabled by default, is it?

Correct.

> If it is, there are
> really very few people who install the sw with other option than just 'dnf
> install'...

I don't know about that.

> And do you have any link for more info for excluding? 

I use:

dnf update -x recommended_package_I_don't_want_to_install

or I just disable soft deps using
/etc/dnf/dnf.conf
[main]
...
install_weak_deps = false

Comment 16 kxra 2019-06-12 21:44:04 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #6)
> Can you try building an RPM package of the plugin using my spec file?
> https://gitlab.com/greysector/hplip-plugin
> 
> I noticed the new libs in the new version and tried to put them in the right
> place, but I don't have a printer that uses them so I couldn't test. It
> looks like you have one, so I'd appreciate it if you could test the latest
> version.
> 
> I'm not providing binary RPMs publicly because HP doesn't allow
> redistribution. I tried asking them for permission but the answer was: no.

Is this where redistribution permission was denied? It doesn't look like a no so much as their failure to follow up: https://bugs.launchpad.net/hplip/+bug/1214318

Comment 17 Dominik 'Rathann' Mierzejewski 2019-06-13 12:15:20 UTC
(In reply to kxra from comment #16)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #6)
[...]
> > I'm not providing binary RPMs publicly because HP doesn't allow
> > redistribution. I tried asking them for permission but the answer was: no.
> 
> Is this where redistribution permission was denied? It doesn't look like a
> no so much as their failure to follow up:
> https://bugs.launchpad.net/hplip/+bug/1214318

Their first answer (https://bugs.launchpad.net/hplip/+bug/1214318/comments/1) was no. I have no contacts at HP to follow up with, but I added a new comment to that bug.


Note You need to log in before you can comment on or make changes to this bug.