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!

I am getting the following error while installing from pamac:

Validating source files with md5sums... hplip-3.20.9-plugin.run ... Passed ==> Removing existing $srcdir/ directory... ==> Extracting sources... ==> Starting prepare()... ==> Entering fakeroot environment... ==> Starting package()... /var/tmp/pamac-build-shaurya/hplip-plugin/PKGBUILD: line 23: cd: /var/tmp/pamac-build-shaurya/hplip-plugin/src/hplip-3.20.9-plugin: No such file or directory ==> ERROR: A failure occurred in package(). Aborting...

I only get this error on pamac and not any other aur helper. Not a big deal, but I would prefer graphical aur helper. Tried editing it but could not get it to work. Using arch, not manjaro.

On parabola I get this error:

$ hp-firmware -n Traceback (most recent call last): File "/usr/bin/hp-firmware", line 39, in <module> from base import device, status, utils, tui, module File "/usr/share/hplip/base/device.py", line 42, in <module> from . import status File "/usr/share/hplip/base/status.py", line 33, in <module> import cupsext ImportError: libnetsnmp.so.35: cannot open shared object file: No such file or directory

Printing does not work.

Investigating the issue I found: $ ls /usr/lib/|grep netsnmp.so libnetsnmp.so libnetsnmp.so.40 libnetsnmp.so.40.0.0

So hplip-plugin seems to use an old so-file for some reason.

@andmars I agree with @argymeg My proposal (fixed version) was a bad idea. Thanks for all the time you spend for keeping this package up to date.

@andmars: Personally I'm happy with the status quo (pre- this latest change) and your update times :)

There's really no perfect solution here, not one that can be achieved by changes to the PKGBUILD anyway. Do you generally do your updating manually? It should be fairly trivial to write a script that polls the Arch repo RSS feed and automatically updates this package when a new HPLIP is released, but I'm not sure what the general attitude is towards updating packages without proper oversight.

@Serial: https://wiki.archlinux.org/index.php/Code_of_conduct#Arch_Linux_distribution_support_ONLY

Building hplip-plugin ... ==> Creating the package: hplip-plugin 3.20.9-2 (Wed 28 Oct 2020 17:51:12) ==> Checking runtime dependencies ... ==> Checking build time dependencies ... ==> Getting fonts ... -> Found hplip-3.20.9-plugin.run ==> Validating source files with md5sums ... hplip-3.20.9-plugin.run ... Passed ==> Removing existing $ srcdir / directory ... ==> Extracting sources ... ==> Starting prepare () ... xterm: cannot load font "-misc-fixed-medium-r-semicondensed - 13-120-75-75-c-60-iso10646-1" ==> Removing existing $ pkgdir / directory ... ==> Entering the fakeroot environment ... ==> Starting package () ... / var / tmp / pamac-build-edson / hplip-plugin / PKGBUILD: line 23: cd: /var/tmp/pamac-build-edson/hplip-plugin/src/hplip-3.20.9-plugin: File or directory nonexistent ==> ERROR: Package () failed. Aborting ...

Interesting discussion. I'm undecided what the best approach here is. To be honest, when I took over this package about 5 years ago it was orphaned. So what I'm doing since then is updating version-number and md5sums most of the time. I'm not that much of a programmer. But I'm very quick at updating (except for last time). So if any of you want to get on board as co-maintainer to make some reasonable changes to the PKGBUILD, just let me know.

@pieplu for better or for worse, your assumption is not correct - pacman always upgrades packages to their latest version, regardless of how they were installed. Partial upgrades are explicitly unsupported in Arch and packages in the official repos always assume all other packages are at the latest version, and mutually dependent packages like this would always be upgraded together - unfortunately with the AUR things aren't that simple.

In these cases manually downgrading hplip is probably the easiest way to go about it, although there's always a risk, however small, that the simultaneous upgrade of some other package will no longer allow the older hplip to work. Another perhaps more "correct" option, since the new hplip-plugin will have been released upstream at the same time as the new hplip, is to manually update the hplip-plugin PKGBUILD and install the latest version.

@argymeg Interesting that puts it in context, I wonder if the way hplip/hplip-plugin is installed will have an impact on dependency resolution. If we don't install hplip directly, but only hplip-plugin (which will solve the hplip dependency). I would have thought that with this procedure, even if hplip has a new version, since it is not directly in the system, but only because of hplip-plugin, which wants a specific version, pacman will not propose an update of it. Conversely, if you have installed hplip and then hplip-plugin, when a new version of hplip comes out, pacman will want to update it, and I guess it's normal that the update of hplip crashes since it breaks the dependency of hplip-plugin. Is my assumption correct? If so, maybe you should document this (don't install hplip directly). If not, it is annoying if it blocks the update of the whole system. And I guess the correct procedure would unfortunately be to manually downgrade hplip until hplip-plugin is updated.

The version dependency used to be expressed more restrictively, similarly to this, and was changed several years ago (commit 98602ca43311). The issue then, which unless I'm much mistaken has now been reintroduced, was that any time hplip is upgraded in the repos, the system upgrade will fail. The user will then need to uninstall hplip-plugin, perform the upgrade, and reinstall hplip-plugin (provided the new version is available). I believe relaxing that requirement, so hplip can be upgraded at the risk of temporarily breaking printing was chosen as the lesser evil, and hasn't been a problem since given the usually prompt updates of this package. IMHO I preferred that behaviour, but it's up to the maintainer.