Description of problem: hp-plugin fails because unable to load plugin.conf Version-Release number of selected component (if applicable): 3.22.6-1 How reproducible: Always Steps to Reproduce: 1. Install hplip 2. Attempt to run hp-plugin to detect and load appropriate driver Actual results: Installation fails with (slightly confusing error messages) error: Plugin download failed with error code = 8 error: file does not match its checksum. File may have been corrupted or altered When running "hp-plugin -l debug" the reason turns out to be that the file http://hplip.sourceforge.net/plugin.conf does not exist. Expected results: http://hplip.sourceforge.net/plugin.conf gets loaded and driver installation proceeds normally.
*** Bug 2130681 has been marked as a duplicate of this bug. ***
*** Bug 2132085 has been marked as a duplicate of this bug. ***
*** Bug 2132086 has been marked as a duplicate of this bug. ***
Hi all, thank you for reporting the issue! Unfortunately the file is missing on the remote server, where we don't have control - the issue is reported upstream several times (the first here - https://bugs.launchpad.net/bugs/1989508 ), but without any solution or response upstream. In the meantime people can download the respective plugin from https://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ and install it by: $ sh <plugin_file> I'll create a bash script which will be run under 'hp-plugin' command and it will do the same thing.
Indeed, I don't think anyone thinks you can fix the remote server issue. There are alternative solutions that you, RH, as the packager can apply though. Your proposed solution: > I'll create a bash script which will be run under 'hp-plugin' command and it will do the same thing. is one solution. Including the plugin from https://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ in hplip (or an hp-plugin subpackage) is another. And yet another is to host the http://hplip.sourceforge.net/plugin.conf on a RH controlled server and update the path during the package build. In any case, whichever solution you choose I am sure everyone will be grateful for your efforts!
(In reply to Brian J. Murrell from comment #5) > Indeed, I don't think anyone thinks you can fix the remote server issue. > There are alternative solutions that you, RH, as the packager can apply > though. Your proposed solution: > > > I'll create a bash script which will be run under 'hp-plugin' command and it will do the same thing. > > is one solution. Including the plugin from > https://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ in > hplip (or an hp-plugin subpackage) is another. Unfortunately the plugin has a license incompatible with open source licenses which can be in the official repos in Fedora, so I cannot ship it in a subpackage (that was the reason why hp-plugin script existed). IIRC Rathann (one hplip user from community) somehow packaged the plugin, but I'm not sure whether he shares it via RPMFusion or uses it locally... > And yet another is to host > the http://hplip.sourceforge.net/plugin.conf on a RH controlled server and > update the path during the package build. When I look into the previous contents of plugin.conf - https://web.archive.org/web/20220420014143/http://hplip.sourceforge.net/plugin.conf - IMHO I cannot guess all the entries there to fully replace this file :( > > In any case, whichever solution you choose I am sure everyone will be > grateful for your efforts! Either way, it would be great if everyone who hit this issue found out whether they really need a plugin for their printing/scanning operations - the plugin is needed only if your device is quite old (about more than 10 years old in case of network printing, about more than 7 years old in case of USB printing, about more than 5-7 years old in terms of scanning) and does not support a driverless methods or if driverless solutions don't match your criteria or don't work due some bugs. For example, I have HP LaserJet M1536dnf (purchased in 2011, made in 2010) at home, which is capable of driverless printing via network (wifi and ethernet), prints with classic driver via USB and plugin is needed only for scanning. More info about this you can find here ( for printing https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_find_out_whether_my_printer_is_capable_of_driverless_printing , for scanning https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to_find_out_my_multifunction_device_or_standalone_scanner_is_capable_of_driverless_scanning ) and in the following paragraphs. In case you encounter some problems/errors when setting the driverless scanning/printing up (if you find out the device should support it), it would be great if you filed a bugzilla to a respective component (in case you have problems with printing from a specific application - file a bug on it, in case the problem is generic - file a bug on CUPS). Regarding the fix, I'll be back in the office next week, so I will be working on the official solution since next week. In the meantime, manual download of plugin from the link https://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ and 'sh <plugin-file>' should work as a workaround.
Hi all, there are scratch builds with new hp-plugin scripts: F37 https://koji.fedoraproject.org/koji/taskinfo?taskID=92952568 F36 https://koji.fedoraproject.org/koji/taskinfo?taskID=92952571 F35 https://koji.fedoraproject.org/koji/taskinfo?taskID=92952573 It would be great if you tried the scratch builds and did tell me how it works for you. Thank you in advance!
I've now installed the following packages on my f35 machines hplip-3.22.6-1.fc35.test1.x86_64.rpm hplip-common-3.22.6-1.fc35.test1.x86_64.rpm hplip-gui-3.22.6-1.fc35.test1.x86_64.rpm hplip-libs-3.22.6-1.fc35.test1.x86_64.rpm libsane-hpaio-3.22.6-1.fc35.test1.x86_64.rpm and they seem to get the job done, I've installed the driver for my HP scanner and it worked.
https://hplip.sourceforge.net/plugin.conf is back online, so the fix is not urgent right now - but I will add the new script as 'hp-plugin-download' in case the original hp-plugin won't work due some reasons.
FEDORA-2022-a5cc963233 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-a5cc963233
FEDORA-2022-d54ebef99d has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-d54ebef99d
FEDORA-2022-027effed0e has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-027effed0e
FEDORA-2022-a5cc963233 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-a5cc963233` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-a5cc963233 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-027effed0e has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-027effed0e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-027effed0e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-d54ebef99d has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-d54ebef99d` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-d54ebef99d See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-d54ebef99d has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-027effed0e has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-a5cc963233 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days