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!

@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 .

@Toolybird @Lone_Wolf That's it. I am using default SRCDEST so I can download successfully. Would you mind adding ua.curlrc in sources and try again to check if this problem disappeared?

@ZhangHua, @Lone_Wolf, I found the root cause! It fails if I have configured SRCDEST inside ~/.config/pacman/makepkg.conf for example SRCDEST=/home/arch/sources. This is a fairly standard makepkg config option, so it really should be made to work in this scenario.