Arch Linux User Repository

Hey, I've adopted this package and applied some of the suggestions:

• Add missing dependencies, notably libusb-compat and sane (cred @ZhandHua).
• Depend on exact version of hplip (cred @jsn42).

In addition, the PGP-signature of the artifact is now checked, which means you need to fetch upstream's key:

gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 4ABA2F66DBD5A95894910E0673D770CDA59047B9

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!

@spcmd try it without -i, it didn't work for me too. This didn't work: hp-setup -i 192.168.XXX.XX This did work: hp-setup 192.168.XXX.XX

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.