Arch Linux User Repository

Please ensure your working directory is in the repository, because we use a custom download agent to download sources, this download agent is a curl wrapper with UA set to firefox's. We call curl directly, using config file to provide User Agent with space.

As for why not set UA in command directly, please check https://wiki.archlinux.org/title/Nonfree_applications_package_guidelines#Custom_DLAGENTS for more info.

I tested paru and it seems can work without any change. But I am not sure if other AUR helpers also can work.

Edit: Found a problem, if you use custom $SRCDEST for makepkg, you need to copy ua.curlrc to $SRCDEST manually, or there will be a failure when downloading sources.

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.