Hplip is buggy in manjaro (hp-setup fails with backtrace)

[callegar]

Hi, the hp-setup tool from hplip is unusable in manjaro since it fails producing a backtrace.

Specifically, it fails in line 958 of file /usr/share/hplip/base/utils.py where the function str.translate is
incorrectly invoked with two arguments when it take a single one.

This may in fact not be an upstream bug, but the consequence of the fact that the upstream code is meant to be run on a python version different than the one provided by manjaro, in which case I guess the python code should better be patched downstream. I am almost sure that for some time I saw something similar on ubuntu as well.

I realize that there are other ways to install printers, including doing it directly from CUPS or the KDE system settings. However the hp-setup tool is handy for simultaneously installing printers and faxes on multifunction hardware.

I wonder if this issue is inherited from arch.
Is there a bug tracker for problems like this?

[mithrial]

I remember that I didn’t actually need to use this god-awful setup program and installing the drivers was enough to be able to use my scanner-printer combo.

The beauty of Python is that you could “simply” modify yourself but you’ll end in a devilish circle where everytime you fix something, it’ll explode somewhere else.

You could use pyenv to install a supported version but the str.translate function only takes two parameters in Python 2, so I’d rather not go down that hole.

[maycne.sonahoz]

@callegar

This may in fact not be an upstream bug, but the consequence of the fact that the upstream code is meant to be run on a python version different than the one provided by manjaro, in which case I guess the python code should better be patched downstream.

@mithrial

Python 2

Hum, if the upstream code is purposed for Python2, then it’s definitely an upstream issue: Python2 has been deprecated for more than a year.

[freggel.doe]

@callegar

I wonder if this issue is inherited from arch.

There is no overlay of the hplip package - it’s directly taken/inherited from arch:

$ pacman -Si hplip | grep -i packager
Packager        : Andreas Radke <andyrtr@archlinux.org>

@maycne.sonahoz

Hum, if the upstream code is purposed for Python2, then it’s definitely an upstream issue: Python2 has been deprecated for more than a year.

This

@callegar

Is there a bug tracker for problems like this?

The hplip about page has a link to Contact Us: Report a Bug: https://launchpad.net/hplip/+filebug

[banjo]

Your profils says you are running ARM64 device ?
I do not have experience with ARM, but my
/usr/share/hplip/base/utils.py line 958 shows

955
956 def printable(s):
957     if s:
958         return s.translate(identity, unprintable)
959     else:
960        return ""
961

…is there a typo in your file ?
My hplip version is 3.21.10-1 and no python2 on my system. Printing/scanning is fine here on 3 different devices.
But again, I don’t have ARM64 and I don’t waste my time with KDE.

[mithrial]

The s.translate function can only work with Python 2. Since 3, it only takes 1 parameter which results in the OP’s error message.

I don’t know the coverage but I guess that only the setup utility and not the driver itself uses this function so that printing and scanning still works. (I also do have an HP where it does work.)

[callegar]

@banjo I need to update my profile. Now using manjaro also on a regular PC (X86-64)

[callegar]

@freggel.doe

The hplip about page has a link to Contact Us: Report a Bug: OpenID transaction in progress

Unfortunately, my experience with that tracker is 100% negative: total silence and no results from reporting issues.

[callegar]

@maycne.sonahoz

if the upstream code is purposed for Python2, then it’s definitely an upstream issue: Python2 has been deprecated for more than a year

and

@mithrial

The s.translate function can only work with Python 2. Since 3, it only takes 1 parameter which results in the OP’s error message.

The fact that hplip is a python2 app is certainly an upstream issue, because python2 is deprecated. But it is also a downstream issue if downstream gets the dependencies wrong or pretends to use it as a python3 application without patching it to this aim. As is hplip declares python (i.e., python 3) as its requirement.

IMHO one should either:

• sustitute python2 for python in the hashbangs and make hplip depend on python2;
• do some minimal downstream patching of hplip to make it run with python3.

I am not sufficiently experienced with Manjaro to know if the arch bug tracker takes issue reports from Manjaro users when packages taken as-they-are from arch are concerned, does it?

[maycne.sonahoz]

@callegar

do some minimal downstream patching of hplip to make it run with python3

There is actually such patch: svntogit-packages/python3.diff at packages/hplip · archlinux/svntogit-packages · GitHub

---

@callegar

I am not sufficiently experienced with Manjaro to know if the arch bug tracker takes issue reports from Manjaro users when packages taken as-they-are from arch are concerned, does it?

Yes it does. Though it is good practice to ascertain here the package is indeed used as-is beforehand.

[callegar]

@maycne.sonahoz

Yes it does. Though it is good practice to ascertain here the package is indeed used as-is beforehand.

What is the standard way to do so? Is looking at the packager name having an arch linux email address or matching the version number enough?

[maycne.sonahoz]

That’s a way. Asking here as you did is another.