Skanpage: Failed to open selected device

I noticed that it’s not possible to scan anymore with skanpage on KDE.
The only error I got in skanpage was: Failed to open selected device.

So I used journalctl and found the following messages:

Mai 13 15:39:48 NYFB skanpage[5253]: kf.i18n: KLocalizedString: Using an empty domain, fix the code. msgid: "New document" msgid_plural: "" msgctxt: ""
Mai 13 15:39:49 NYFB skanpage[5253]: Cannot initialize model with data QJsonObject(). missing: QJsonValue(string, "urls")
Mai 13 15:39:49 NYFB skanpage[5253]: file:///usr/lib/qt/qml/org/kde/kirigami.2/AboutItem.qml:209: ReferenceError: page is not defined
Mai 13 15:39:49 NYFB skanpage[5253]: qrc:/qml/SettingsWindow.qml:28:5: QML FormLayout: Binding loop detected for property "implicitHeight"
Mai 13 15:39:49 NYFB skanpage[5253]: file:///usr/lib/qt/qml/org/kde/kirigami.2/AboutItem.qml:161:5: QML FormLayout: Binding loop detected for property "implicitHeight"
Mai 13 15:39:49 NYFB skanpage[5253]: file:///usr/lib/qt/qml/org/kde/kirigami.2/AboutItem.qml:209: ReferenceError: page is not defined
Mai 13 15:39:49 NYFB skanpage[5253]: file:///usr/lib/qt/qml/org/kde/kirigami.2/FormLayout.qml:101:5: QML GridLayout: Binding loop detected for property "knownItemsImplicitWidth"
Mai 13 15:39:49 NYFB skanpage[5253]: file:///usr/lib/qt/qml/org/kde/kirigami.2/UrlButton.qml:50:9: QML MenuItem: Binding loop detected for property "implicitWidth"
Mai 13 15:39:49 NYFB skanpage[5253]: file:///usr/lib/qt/qml/org/kde/kirigami.2/UrlButton.qml:50:9: QML MenuItem: Binding loop detected for property "implicitWidth"
Mai 13 15:39:49 NYFB skanpage[5253]: file:///usr/lib/qt/qml/org/kde/kirigami.2/UrlButton.qml:50:9: QML MenuItem: Binding loop detected for property "implicitWidth"
Mai 13 15:39:49 NYFB skanpage[5253]: file:///usr/lib/qt/qml/org/kde/kirigami.2/UrlButton.qml:50:9: QML MenuItem: Binding loop detected for property "implicitWidth"
Mai 13 15:39:49 NYFB skanpage[5253]: file:///usr/lib/qt/qml/org/kde/kirigami.2/AboutItem.qml:161:5: QML FormLayout: Binding loop detected for property "implicitHeight"
Mai 13 15:39:49 NYFB skanpage[5253]: file:///usr/lib/qt/qml/org/kde/kirigami.2/AboutItem.qml:209: ReferenceError: page is not defined
Mai 13 15:40:11 NYFB skanpage[5253]: common/utils.c 245: unable to load library libm.so: /usr/lib/libm.so: Ungültiger ELF-Header
Mai 13 15:40:11 NYFB skanpage[5253]: common/utils.c 173: validate_plugin_version() Plugin version[3.22.10] mismatch with HPLIP version[3.23.3]
Mai 13 15:40:11 NYFB skanpage[5253]: common/utils.c 206: Plugin version is not matching
Mai 13 15:40:11 NYFB skanpage[5253]: common/utils.c 277: Invalid Library hanlder pLibHandler = NULL.

It seems that the plugin version of HPLIB is outdated.

On the AUR page of hplip-plugin 3.23.3-1 I found the following information of a user:

For those running Manjaro:
Manjaro’s hplip is always delayed with respect to Arch, and this hplip-plugin follows the Arch version. It’s a bummer. However, the unstable branch of Manjaro usually have the updated hplip version there.
So, if you want to keep it synced, try using the downgrade tool to actually upgrade to the package in the unstable branch. This is not recommended in general, but hplip does not have deep dependencies, so it works fine. Here’s the command:
sudo downgrade hplip --ala-only
From the list of versions, select the one that matches the hplip-plugin version.

I assume this is something the Manjaro Devs have to update in order to keep it properly?

The page gives you instructions on how to use downgrade to keep it working.

latest version of hplip was released to Arch repository 2023-05-07 (last friday)
Arch Linux - hplip 1:3.23.3-3 (x86_64)
and currently available in Manjaro unstable and testing repositories
packages.manjaro.org - hplip

I saw that but it is a hacky workaround and in my opinion there should be a proper one, for example update both packages at the same time instead of one.

That means that skanpage has been broken for a longer time since it’s not the first 3.23.3 update and the hplip-plugin is still on 3.22.10.
From where does this hplip-plugin come, I can’t find any info on the manjaro packages?

AUR page for hplip-plugin has link to upstream URL: https://developers.hp.com/hp-linux-imaging-and-printing/binary_plugin.html

Sorry I did not formulate my question right.
What I meant was, that skanpage thinks that the hplip-plugin 3.22.10 is installed on my system even if I never have installed that AUR package.
And there are no other traces from where the package might have come.

Ok, that is an entirely different issue. Where does skanpage indicate that it thinks hplip-plugin is installed? Even if you don’t remember installing it, are you sure that it is not present on your system?

@fasto

The logs from skanpage indicates this.
And I can’t find the source of this installed plugin version 3.22.10

Yes, I’m sure that hplip-plugin is not installed on my system
Running the command pamac install hplip-plugin will install it for me. The GUI Pamac indicates the same.

pamac install hplip-plugin                                                                                                                             100 ✘ 
Warnung: hplip-plugin ist nur vom AUR verfügbar
Vorbereitung...
Klone hplip-plugin Build-Dateien...
Generiere Informationen zu hplip-plugin  ...
Überprüfe hplip-plugin Abhängigkeiten...
Abhängigkeiten werden aufgelöst...
Interne Konflikte werden überprüft...

Zu erstellen (1):
  hplip-plugin  3.23.3-1    AUR


Build-Dateien bearbeiten : [e] 
Transaktion durchführen ? [e/j/N] 

My question now, if hplip is officially in the manjaro packages but both hplip and hplip-plugin are needed for skanpage, why is hplip-plugin only on AUR which is not supported by Manjaro?

Plugin HPLIP does not necessarily mean hplip-plugin. Do you have hplip installed, and what version?

pacman -Q --info hplip
Name                     : hplip
Version                  : 1:3.23.3-1
Beschreibung             : Drivers for HP DeskJet, OfficeJet, Photosmart, Business Inkjet and some LaserJet
Architektur              : x86_64
URL                      : https://hplipopensource.com
Lizenzen                 : GPL2  custom
Gruppen                  : Nichts
Stellt bereit            : Nichts
Hängt ab von             : python-dbus  python-distro  ghostscript  net-snmp  foomatic-db-engine  python-gobject  libxcrypt
Optionale Abhängigkeiten : cups: for printing support [Installiert]
                           sane: for scanner support [Installiert]
                           xsane: sane scanner frontend
                           python-pillow: for commandline scanning support [Installiert]
                           python-reportlab: for pdf output in hp-scan [Installiert]
                           rpcbind: for network support [Installiert]
                           python-pyqt5: for running GUI and hp-toolbox [Installiert]
                           libusb: for advanced usb support [Installiert]
                           wget: for network support [Installiert]
Benötigt von             : Nichts
Optional für             : manjaro-printer
In Konflikt mit          : Nichts
Ersetzt                  : Nichts
Installationsgröße       : 34.40 MiB
Packer                   : Andreas Radke <andyrtr@archlinux.org>
Erstellt am              : Di 04 Apr 2023 21:42:08
Installiert am           : Mi 12 Apr 2023 18:40:54
Installationsgrund       : Installiert als Abhängigkeit eines anderen Pakets
Installations-Skript     : Nein
Verifiziert durch        : Signatur

Moderator edit: In the future, please use proper formatting: [HowTo] Post command output and file content as formatted text

What happens if you downgrade hplip to 3.22.10?

That did work wonders, I can now select my printer in skanpage and scan a site without any faults.
So you don’t know either where the reference in skanpage of hplip-plugin v. 3.22.10 comes from?

Well I tried reading the source code but couldn’t find the exact location the code the error is attributed to, so this is only speculation:

When it refers to the “HPLIP Plugin” it means a plugin within Skanlite meant to handle HPLIP. Due to some sort of mixup, the version of Skanlite available on Stable expects HPLIP 3.22.10, while the latest HPLIP is 3.23.3. hplip-plugin has nothing to do with the issue, and just happens to have a name containing the words “HPLIP” and “Plugin”. If it did have to do with that package, it would have called it hplip-plugin instead of “HPLIP Plugin”

I found it.

I first went to check the source code of hplip/common/utils.c, which can be found on HPLIP: common/utils.c | Fossies.

There I found this specific code which validates the installed plugin version.

enum UTILS_PLUGIN_STATUS validate_plugin_version()
{
    char hplip_version[128];
    char plugin_version[128];
if (get_conf("[hplip]", "version", hplip_version, sizeof(hplip_version)) != UTILS_CONF_OK)
      return UTILS_PLUGIN_STATUS_NOT_INSTALLED;

    if (get_key_value(HPLIP_PLUGIN_STATE,"[plugin]" , "version", plugin_version, sizeof(plugin_version)) != UTILS_CONF_OK )
    {
        BUG("validate_plugin_version() Failed to get Plugin version from [%s]\n", "/var/lib/hp/hplip.state");
        return UTILS_PLUGIN_STATUS_NOT_INSTALLED;
    }


    if (strcmp(hplip_version, plugin_version) == 0)
    {
        return UTILS_PLUGIN_STATUS_OK;
    }
    else
    {
        BUG("validate_plugin_version() Plugin version[%s] mismatch with HPLIP version[%s]\n",plugin_version, hplip_version);
        return UTILS_PLUGIN_STATUS_MISMATCH;
    }
    return UTILS_PLUGIN_STATUS_NOT_INSTALLED;
}

You see that it calls the method get_key_value in which plugin_version is sent with as a parameter.

The above mentioned method looks like this:

/* Get value for specified section and key from hplip.conf. */
enum UTILS_CONF_RESULT get_conf(const char *section, const char *key, char *value, int value_size)
{
   return get_key_value(CONFDIR "/hplip.conf", section, key, value, value_size);
}

But now where is this hplip.conf file?
I tried looking in the hplip package folder, which I found with whereis but it was not there.
I stumbled upon the real path purely by coincidence while reading through cups.py which has the path hardcoded: “/etc/hp/hplip.conf”

In this file the hplip version is set.

# hplip.conf.  Generated from hplip.conf.in by configure.

[hplip]
version=3.23.3

[dirs]
home=/usr/share/hplip
run=/var/run
ppd=/usr/share/ppd/HP
ppdbase=/usr/share/ppd
doc=/usr/share/doc/hplip-3.23.3
html=/usr/share/doc/hplip-3.23.3
icon=/usr/share/applications
cupsbackend=/usr/lib/cups/backend
cupsfilter=/usr/lib/cups/filter
drv=/usr/share/cups/drv/hp
bin=/usr/bin
apparmor=/etc/apparmor.d
# Following values are determined at configure time and cannot be changed.
[configure]
network-build=yes
libusb01-build=no
pp-build=yes
gui-build=yes
scanner-build=yes
fax-build=yes
dbus-build=yes
cups11-build=no
doc-build=yes
shadow-build=no
hpijs-install=no
foomatic-drv-install=no
foomatic-ppd-install=no
foomatic-rip-hplip-install=no
hpcups-install=yes
cups-drv-install=yes
cups-ppd-install=no
internal-tag=3.23.3
restricted-build=no
ui-toolkit=qt5
qt3=no
qt4=no
qt5=yes
policy-kit=no
lite-build=no
udev_sysfs_rules=no
hpcups-only-build=no
hpijs-only-build=no
apparmor_build=no
class-driver=no

But this looks right, so let’s continue the search.
We saw the following path mentioned in this line of code:
BUG("validate_plugin_version() Failed to get Plugin version from [%s]\n", "/var/lib/hp/hplip.state");

This is the content of the file:

[plugin]
installed = 1
eula = 1
version = 3.22.10

So we can see, that the issue comes from the hplip.state file in the /var directory.

This is what I have found out until now, I will search further tomorrow :slight_smile:

1 Like