| Git Clone URL: | https://aur.archlinux.org/hplip-plugin.git (read-only, click to copy) |
|---|---|
| Package Base: | hplip-plugin |
| Description: | Binary plugin for HPs hplip printer driver library |
| Upstream URL: | https://developers.hp.com/hp-linux-imaging-and-printing/binary_plugin.html |
| Keywords: | fax hp printer scanner |
| Licenses: | LicenseRef-HPLIP-LICENSE |
| Submitter: | pyropeter |
| Maintainer: | ZhangHua |
| Last Packager: | ZhangHua |
| Votes: | 403 |
| Popularity: | 0.64 |
| First Submitted: | 2010-12-21 00:32 (UTC) |
| Last Updated: | 2025-04-05 00:57 (UTC) |
sudo hp-setup -i hangs for me at start, it says "UPDATING PLUGIN", but it never goes through this.
I tried the GUI version, and it recognizes my laserjet printer, but clicking on the "Next" button seems to freeze and doesn't do anything. My system is up to date.
@khvalera maybe I found the solution for you and other people. I also had problems from my laptop regarding scanning so I used the command "hp-setup 192.168.XXX.XX" (the IP adress of your printer) and told it to install the printer, even if I had set it up via CUPS. Now scanimage -L, hp-scan, skanpage (if you're a KDE user) are recognizing the printer.
@MystikReasons I have about a dozen printers that only start scanning if I manually install hplip-3.25.2-plugin.run under the user, it also doesn't work under root
@khvalera, I have a HP LaserJet Pro MFP M277dw and I connected it today via socket/HP JetDirect and it worked out of the box. I did not try IPP.
After updating hplip-plugin to 3.25.2, some scanners stopped being detected, and some stopped scanning, such as the HP LaserJet Pro MFP 4103dw. Has anyone encountered this problem?
@Toolybird Wow, that's like a magic. Anyway, your solution seems to be the perfect way, I will update PKGBUILD to use yours.
@Lone_Wolf Would you mind to test if updated PKGBUILD also fixed for your custom $SRCDEST? I tried SRCDEST=/tmp/test makepkg and it seems fine now.
If it is also good on you, I will unpin that message because there actually need nothing to be noticed now.
@Lone_Wolf No, I don't believe this is a pacman issue. Here is a better solution which doesn't involve a separate config file. Just use these 2 lines instead:
_useragent="User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
DLAGENTS=("https::/usr/bin/curl -H ${_useragent// /\\ } -qgb '' -fLC - --retry 3 --retry-delay 3 -o %o %u")
I think this needs to be an upstream pacman bug report. I do have the feeling toolybird has a better standing with pacman devs then I do.
@Toolybird : could you please open a bug report for this ?
@Lone_Wolf Yeah, if I set SRCDEST to a custom path and run makepkg, the problem appears. The workaround I found is that copying ua.curlrc to $SRCDEST manually before running makepkg. I think you may create an issue at pacman's repository about this? I will also pin a message about this for others.
adding ua.curlrc to in sources array doesn't make a difference .
Commenting the SRCDEST line in /etc/makepkg.conf does . I checked and makepkg itself has the same issue .
SRCDEST="" makepkg does work.
Looks like we may have found a bug in download agents handling .
Pinned Comments
carsme commented on 2024-01-15 16:53 (UTC) (edited on 2024-02-04 14:15 (UTC) by carsme)
Hey, I've adopted this package and applied some of the suggestions:
libusb-compatandsane(cred @ZhandHua).Depend on exact version ofhplip(cred @jsn42).In addition, the PGP-signature of the artifact is now checked, which means you need to fetch upstream's key:
Unfortunately, I have no HP printer at home so my testing ability is limited to running
hp-diagnose_plugin. If someone has better opportunity to test and is interested in maintaining, let me know and I'll handover the package or add you as a co-maintainer. Cheers!