Hide Forgot
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
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
hplip-3.18.12-4.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-b489194d24
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
https://bodhi.fedoraproject.org/updates/FEDORA-2019-b489194d24#comment-892211 (I thought Bodhi should switch automatically?)
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.
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.
@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
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 :(
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 ...)
(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!
(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?
(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.
(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!
(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
(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
(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
(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.